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

Transkript

Odbor/ oddělení
Service Desk
PROVOZNÍ DOKUMENTACE IT SZR
Přílohy 0
Počet 81
PROVOZNÍ DOKUMENTACE
Příručka řešitele
Vedoucí oddělení / Manager procesu:
Ing. Igor Jeřábek
Zpracoval:
Ing. Igor Jeřábek
Verze: nepovinné
X.X
Platí od:
Platí do:
1. 5. 2013
31. 12. 2015
Strana 1 / 81
Provozní dokumentace 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
4.10.1
Přiřazení konfigurační položky k záznamu........................................................................... 39
Strana 2 / 81
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
Strana 3 / 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
1.7
17.10.2013
Igor Jeřábek
Vložení kap. 8.5 a 8.6
1.8
18. 7. 2014
Igor Jeřábek
Aktualizace kap. 4.1.1
Strana 4 / 81
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.
Strana 5 / 81
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
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
Strana 7 / 81
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
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
Strana 9 / 81
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í komerční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šší
Strana 10 / 81

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:
Strana 11 / 81
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.)
Strana 12 / 81

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.
Strana 13 / 81
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

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
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:
Strana 16 / 81
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
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ů
Strana 18 / 81
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
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“
Strana 20 / 81
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
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.
Strana 22 / 81



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.
Strana 23 / 81
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
Strana 24 / 81
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.
Strana 25 / 81
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
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
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.
Strana 28 / 81
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
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
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
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.
Strana 32 / 81
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í.
Strana 33 / 81
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.
Strana 34 / 81
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
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
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
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
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.
Strana 39 / 81
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
Požadavek na změnu Change Order záložka Configuration Management
Strana 41 / 81
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
Strana 42 / 81
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
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
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ží.
Strana 45 / 81
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
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.
Strana 47 / 81
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.
Strana 48 / 81
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
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
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
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
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
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
Zmáčknutím tlačítka OK uložíte takto formátovaný text do pole Resolution.
Strana 55 / 81
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
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
Strana 58 / 81
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
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
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.
Strana 61 / 81
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.
Strana 62 / 81
.
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
Strana 63 / 81
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



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í“)

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í
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
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
Strana 65 / 81

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,
Strana 66 / 81
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.
Strana 67 / 81
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
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

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
Ř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


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.
Strana 72 / 81
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ý“.
Strana 73 / 81
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
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
9.1 Nastavení Service Type STIMSZR
Aktivita
SZR P2 - 15 minut response
SZR P1- 23 minut response
SZR P2 - 45 minut reponse
SZR P3 60 minut response
SZR P1 - 50% SLA
Událost
SZR P1 15 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
Strana 76 / 81
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 P3 75% SLA
SZR P4 NBD response
SZR P3 SLA Violated
SZR P4 50% SLA
SZR P4 75% SLA
SZR P4 SLA Violated
SZR P1 75% SLA
SZR P2 50% SLA
SZR P1 SLA Violated
SZR P2 75% SLA
SZR P4 6 hodin response
SZR P2 SLA Violated
SZR P3 50% SLA
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
Strana 77 / 81
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í
Strana 78 / 81
10. Scoreboard
10.1 Definice Scoreboardu pro Operátor L1
Strana 79 / 81
10.2 Definice Scoreboardu pro OperátorL2
Strana 80 / 81
10.3 Definice Scoreboardu pro Řešitel
Strana 81 / 81

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

Transkript

Podobné dokumenty

Smlouva na dobu určitou

Česká hudba napříč staletími zazní v Teplicích

anarion [pošta]

obětovali

73 praxe – inspirace – konfrontace

API for mobilem.cz

Bojujeme s RESTem