Odbor/ oddělení Service Desk PROVOZNÍ DOKUMENTACE IT SZR Přílohy 0 Počet 66 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: 12. 12. 2016 Platí do: xxx Strana 1 / 69
Obsah HISTORIE DOKUMENTU... 4 1. ÚVOD... 5 2. OBECNÝ POPIS FUNKCE SERVICE DESK... 6 Základní povinnosti:... 6 Organizační schéma SD... 6 Popis rolí SD:... 6 3. CA SERVICE DESK MANAGER V SZR... 8 Dostupné role pro řešitele... 8 4. ZÁKLADY OVLÁDÁNÍ SYSTÉMU... 9 Přístup do aplikace Service Desk Manager... 9 4.1.1 Přístup do produkčního SDM:... 9 Založení požadavku... 13 4.2.1 V roli uživatele... 13 4.2.2 V roli operátora/řešitele... 15 Analýza a řešení požadavku... 16 4.3.1 Převzetí požadavku do řešení... 17 4.3.2 Vyžádání součinnosti... 19 4.3.3 Eskalace požadavku... 19 Vyřešení požadavku... 20 Vypořádání tiketů... 21 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 Emailová komunikace... 24 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 Editace údajů... 31 4.9.1 Standardní editační formulář... 31 4.9.2 Další možnosti změn údajů pomocí předdefinovaných funkcí... 32 4.9.3 Editace přímo v seznamu... 34 Vytváření vazeb... 34 4.10.1 Přiřazení konfigurační položky k záznamu... 34 4.10.2 Vazby mezi Požadavky, Incidenty, Požadavky na změnu... 36 Vykázání odpracované doby... 38 Strana 2 / 69
Využití konfigurační a znalostní databáze... 38 Zastupitelnost a dostupnost... 38 Přehled vybraných Aktivit a Přehled rychlých informací o tiketu... 40 Záložka 1. Další informace, sekce Diskuze:... 41 5. PRÁCE SE ZNALOSTNÍ DATABÁZÍ... 43 Vyhledávání informací ve znalostní databázi... 43 5.1.1 Vyhledávání přímo z prostředí Znalostní databáze... 43 5.1.2 Vyhledávání v kontextu konkrétního tiketu... 44 Vložení řešení požadavku do znalostní databáze... 46 6. ZOBRAZENÍ OBLASTI OZNÁMENÍ... 49 7. TISKOVÉ VÝSTUPY... 50 8. POSTUP ŘEŠENÍ POŽADAVKU... 51 Požadavek zadaný neověřeným uživatelem - Guest... 51 Požadavek zadaný ověřeným uživatelem/řešitelem... 51 Sledování doby odezvy... 57 Stavy požadavku v průběhu řešení... 57 Požadavky vyžadující spolupráci od uživatele nebo jiné řešitelské skupiny... 58 Odmítnutí požadavku ve stavu V řešení... 58 9. POSTUP ŘEŠENÍ INCIDENTU... 59 Nastavení Service Type STIMSZR... 61 Stavy incidentu v průběhu řešení... 62 10. SCOREBOARD... 64 Oblíbené... 64 Definice Scoreboardu pro Operátor L1... 65 Definice Scoreboardu pro OperátorL2... 66 Definice Scoreboardu pro Řešitel... 67 11. PODSTATNÉ ZMĚNY... 68 Vypořádání tiketu... 68 Definice nových funkcionalit... 69 Strana 3 / 69
Historie dokumentu Verze Datum Autor Popis 1.0 15. 11. 2012 1.1 20. 11. 2012 1.2 23. 11. 2012 Petr Poplstein 1.3 4. 3. 2013 Petr Poplstein, Marek Švejda Vytvoření draftu dokumentu Petr Poplstein Zapracování připomínek z 19. 11. 2012 Petr Poplstein Zapracované připomínky z 23. 11. 2012 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 1.9 24.11.2016 Milan Horák Zastupitelnost. 4.14, lokalizované snímky obrazovky, popisy 1.9.1 8.12.2016 Milan Horák Podstatné změny ve verzi 14.1.03 1.9.2 12.12.2016 Jirka Havel Aktualizace print screenů a komentářů Strana 4 / 69
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 Požadavek Incident SZR Uživatel Provozní doba Mimoprovozní doba (MPD) KIVS JIP/KAAS Problém Požadavek na změnu 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 Požadavek na Změnu. Strana 5 / 69
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. 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ů. Organizační schéma SD Service Desk Manager Operátoři Řešitelé 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 / 69
Operátoři Úloha operátora spočívá v analýze požadavku a jeho vyřešení v souladu s existujícími smlouvami. Pokud nebylo možné požadavek vyřešit, v případné eskalaci, respektive přidělení požadavku skupině řešitelů nebo dodavateli, který bude provádět další analýzu a řešení požadavku. Operátoři se dělí dle odbornosti a prováděných aktivit na: Řešitelé Operátoři L1: zajišťují zpracování požadavků zadaných pomocí webového rozhraní, prvotní analýzu a řešení přidělených požadavků v případě, že se jedná o předem známý, opakovaný postup řešení, nebo je možno použít existující znalostní dokument u všech zadaných požadavků provádí kontrolu přiřazení kategorie, naléhavosti, úplnost poskytnutých informací eskalace na Operátora L2, pokud nejsou schopni požadavek vyřešit Operátoři L2: u přidělených požadavků provádí kontrolu přiřazení kategorie, priority, úplnost poskytnutých informací analýzu a řešení požadavku, který spadá do jejich kompetence zakládání podřízených požadavků, incidentů a souvisejících incidentů, problémů a požadavků na změnu eskalace na Řešitele dodavatele vytváření záznamů do znalostní databáze Ú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 / 69
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. 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 pomocí aktivity Převzít tiket v Menu Aktivity 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 Eskalovat menu Aktivity. 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 Oblasti Požadavku operátorem. Strana 8 / 69
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í. 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: 4.1.1 Přístup do produkčního SDM: 1. Uživatelé s účtem v AD - používá se primárně pro řešitele SZR: a. Z internetu: https://loginsd.szrcr.cz/ b. Interně: https://sd.szrcr.cz/sso/pdmweb.exe Strana 9 / 69
Následně: 2. Uživatelé s účtem v JIP: Z internetu: https://loginsd.szrcr.cz 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: Strana 10 / 69
nebo přihlášení pomocí OTP: Strana 11 / 69
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 11 Microsoft Edge on Windows 10 Mozilla Firefox ESR 24.0 Mozilla Firefox 31.0 Google Chrome 34.0 Apple Safari 7.1 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 12 / 69
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. Strana 13 / 69
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. Aktualizaci kontaktních informají je též možno změnit v roli uživatel pod volbou Upravit kontaktní informace nebo v ostatních rolích při odmáčknutí ikony panáčka který je umístěn na základní obrazovce vpravo nahoře. 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 neomezuje funkčnost systému, zařízení je poškozené, běžný požadavek. 4 - uživatel má evidovaný požadavek, není vyžadováno okamžité řešení, problém je možno odstranit v průběhu běžné pracovní doby. Lze nahradit provizorním řešením. 5 - uživatel má evidovaný požadavek. Termín jeho vyřešení není z jeho pohledu významný a řešení nechává na možnostech poskytovatele služeb. Pole, jejichž vyplnění je povinné jsou označena textem (povinné) 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: Strana 14 / 69
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 Nový požadavek: V zobrazeném formuláři pro založení požadavku je nutno vyplnit všechna pole, která jsou povinná - označena hvězdičkou. Dotčený uživatel uživatel, který požadavek hlásí Oblast požadavku 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í Název krátký popis požadavku Popis podrobný popis požadavku Na záložce 1. Další informace sekce Vlastnosti mohou být u některých Oblastí požadavku 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 Uložit. Po uložení požadavku systém odešle notifikace o založení požadavku na skupiny přiřazených řešitelů: Strana 15 / 69
a uživatele, který je uveden v poli Dotčený uživatel: 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í, konfigurační databázi Strana 16 / 69
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 Aktivity 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 Hledat Požadavky: Detail požadavku otevře v novém okně kliknutím na číslo požadavku: Strana 17 / 69
V případě, že operátor/řešitel bude požadavek řešit, pomocí aktivity Převzít tiket z Menu Aktivity: vybere do pole Nový Řešitel svůj kontakt: Může doplnit k aktivitě: popis pole Uživatelský popis Odpracovaná doba - čas, který spotřeboval na provedení aktivity (je nutno dodržet vyžadovaný formát) záznam uloží pomocí tlačítka Uložit. 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í. Strana 18 / 69
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: Přidat komentář komunikace probíhá 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 Akutalizovat stav řešitelem 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á aktualizace stavu Ř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 Oblast Požadavku/Incidentu. 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. Strana 19 / 69
Komunikační schéma pro založení, řešení a vyřešení požadavku/incidentu Uživatel Telefon Email SDM Email telefon SDM Operátor L1 Email Telefon SDM Operátor L2 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. Vyřešení požadavku Pokud řešitel požadavek vyřešil, musí vyplnit popis řešení požadavku, pomocí tlačítka Vyřešit tiket. Následně změní stav požadavku na Vyřešený Strana 20 / 69
Po změně stavu požadavku na Vyřešený odejde notifikace o vyřešení požadavku na kontakt uvedený v poli Dotčený uživatel : 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 / 69
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í Strana 22 / 69
o o Manuální Notifikace z menu Aktivity 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. Přidat komentář z menu Aktivity nebo tlačítkemrychlé volby 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 Host pole Dotčený Uživatel 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 Host, řešitel vyplní do pole Dotčený Uživatel 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 Uživatelský popis 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 / 69
4.6.2 Průzkum spokojenosti uživatelů/zákazníků s řešením požadavků/incidentů Uživatelé/zákazníci jsou prostřednictvím funkce řízené průzkumy 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í. 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 dotčeného uživatele, ř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 dotčený uživatel a řešitel, jsou zapsány v Aktivitách a diskuzi, 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 / 69
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 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 / 69
2) Položky začínající Moje/Mé 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 Mé požadavky) se v pravé části okna zobrazí seznam všech vyhovujících záznamů (v našem případě seznam všech požadavků, 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 Incidenty, který obsahuje podkontejnery Přiřazené 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. Strana 26 / 69
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é. Strana 27 / 69
4.8.3 Použití filtrů 1) Řešitel má možnost aplikovat na zobrazený seznam uživatelský filtr stisknutím tlačítka Zobrazit Filtr. 2) 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. Strana 28 / 69
3) 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 například pole Aktivní 2, Strom hodnot hierarchie například pole Oblast Řešení 3, Seznam položek seznam kontaktů, který je možno také filtrovat pro snadné nalezení odpovídající hodnoty, například pole Řešitel 4) Další obrázek ukazuje příklad číselníku řešitelů, který se zobrazil po kliknutí na záhlaví pole Řešitel v definici filtru a stisknutí tlačítka Hledat. 5) Kliknutím na požadovaný řádek se zvolená hodnota automaticky zapíše do aktuálně nastavovaného pole filtru. 6) 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 Zobrazit filtr, zadejte do vybraných polí náležité hodnoty a tlačítkem Hledat 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 29 / 69
Pozn.: Systém automaticky doplňuje zástupný znak za vyhledávaný řetězec, před řetězec ne. Proto obvykle stačí použít znak % pouze před hledaným výrazem. Detailní popis všech možností vyhledávání a syntaxe použitelná v poli Další argumenty vyhledávání je uvedena v originální dokumentaci k produktu, která je dostupná z Menu Nápověda. Strana 30 / 69
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 Změnit jak je ukázáno na následujících obrázcích. 2) Po ukončení editace je nutno změny uložit volbou tlačítka Uložit. 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 Aktivity (Možnosti řešitele a operátora se v dostupných aktivitách liší). Strana 31 / 69
4.9.2 Další možnosti změn údajů pomocí předdefinovaných funkcí 1) Nejčastěji používané Aktivity jsou umístěny ve formě tlačítek ve stejné úrovni jako tlačítko Změnit. Další aktivity je možné nalézt v menu Aktivity 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: Aktualizovat stav - 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 Oblastí řešení a stav V řešení po vyplnění pole Řešitel převzetím požadavku řešitele pomocí aktivity Převzít tiket Přidat komentář - Umožňuje přidat obecnou položku do 2.Logy/2.Aktivity využívá se pro vkládání komentářů od uživatelů a řešitelů, případně informací ze zpracovaných emailů Vyřešit tiket využívá se k popisu řešení požadavku a změnu stavu na Vyřešený. Uživatelský popis je uložen do záložky Diskuze a Aktivity. Převzít tiket - 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 Aktualizovat stav a výběrem odpovídajícího stavu (případně přes rychlou volbu). Požadovat Součinnost Zpětná vazba řešitele uživateli, například při nutnosti doplňujících informací. Tiket bude převeden do stavu Čeká na součinnost. Připojená SLA se nezastaví, ale doba součinnosti se bude zohledňovat při závěrečném vypořádání požadavku. Vytořit Incident Vytvoření Incidentu na základě konkrétního požadavku. Tato možnost je dostupná pouze pro Operátory. Zrušit Tiket Tiket bude uzavřen bez vyřešení, typicky v případech, kdy uživatel nemá na takový požadavek nárok nebo uživatel požádal o zrušení tiketu. Možnost dostupná pouze pro Operátory. Odmítnout Stejné jako předchozí případ, pokud je tiket ve stavu Zadaný. Strana 32 / 69
Přidat k Oblíbeným Tiket bude přidán do Scoreboardu přihlášeného řešitele do položky Oblíbené. Manuální Notifikace - Umožňuje vytvořit manuální emailovou notifikaci V případě, že chcete odeslat notifikaci pomocí SMS, je nutno upravit pole Urgence na hodnotu Emergency a pole Preferovaná Metoda na hodnotu Notifikace. 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 Interní? 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 Uživatelský popis. Pro některé aktivity je vyplnění pole Popis povinné Strana 33 / 69
4.9.3 Editace přímo v seznamu 1) Klíčové údaje záznamu lze Upravit v seznamu, který je zobrazen na obrázku níže. 2) Po kliknutí na tlačítko Upravit v seznamu má operátor možnost změnit následující položky vybraného servisního případu (v ukázce jde o požadavek číslo 11851): Stav Nadřízený Požadavek Řešitel 3) Aktuální servisní případ pro editaci se zvolí kliknutím na příslušný řádek seznamu. Stisknutím tlačítka Změnit vše 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ů. Pozn.: Tato metoda je nevratná, proto není doporučeno upravovat přes seznam velké množství tiketů a je třeba dbát zvýšené pozornosti. 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 34 / 69
Obrazovky definice relace pro: Požadavek (Request) - pole Konfigurační položka v sekci Detail: Incident a Problém pole Konfigurační položka a pole Dotčená služba výběr služby, na které je incident / problém řešen. Strana 35 / 69
Požadavek na změnu Konfigurační Management Konfigurační položky 4.10.2 Vazby mezi Požadavky, Incidenty, Požadavky na změnu Řešitel může u požadavku na záložce 4. Vztahy definovat vztahy mezi nadřízeným/podřízeným záznamem. 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 Nadřízený/Podřízený Požadavek definice souvisejících požadavků Strana 36 / 69
Sekce 3. Nadřízený/Podřízený Incident definice souvisejících Incidentů Sekce 2. Nadřízené/Podřízené Oprávnění administrátor a operátoři mají možnost rozšířit právo přistoupit k požadavku i pro jiné skupiny, než jsou aktální řešitelé požadavku. Využívá se při řešení podřízených požadavků, kdy jsou detaily a historie evidovány u nadřízeného požadavku. Relace mezi požadavkem a Incidentem Z detailu požadavku pomocí tlačítka Vytvořit Incident může Operátor 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 Popis je doplněn text (Vytvořeno z Požadavku xxx) a na záložce 4. Relationships část 1. Požadavek Nadřízený/Podřízený jsou zaevidovány vazby mezi Požadavky v systému. Relace mezi Incidentem a Problémem Strana 37 / 69
Z detailu Incidentu může Operátor založit pomocí tlačítka Vytvořit Problém problém, 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 incidentu a není je nutno opět zadávat. Vykázání odpracované doby Operátoři a řešitelé vykazují dobu odpracovanou při řešení požadavků do pole Odpracovaná doba v aktivitě, kterou k záznamu evidují. Je nutné dodržet předepsaný formát hh:mm:ss. Využití konfigurační a znalostní databáze Řešitelé využívají konfigurační databázi pro získání informací usnadňujících analýzu a identifikaci řešení (historie řešených požadavků, incidentů a změn u dotčené položky a uživatele, přehled souvisejících konfiguračních položek a jejich vliv na řešený požadavek atd.). Vytváření vazeb na konfigurační databázi je popsáno v kapitole 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. Zastupitelnost a dostupnost Řešitelé mají možnost informovat o své dostuponosti/zastupitelnosti. K tomu slouží symbol panáčka vedle uživatelského jména. Červený znamená nedostupného uživatele. Zelený dostupný Po kliknutí na symbol panáčka je otevřeno nové okno nastavení s možností vykazovat dostupnost/nedostupnost, možnost nastavit jiného uživatele jako zástup v případě nedostupnosti a možnost odbírat nová oznámení do e- mailu uživatele. Strana 38 / 69
Kliknutím na tlačítko Uložit budou tyto údaje potvrzeny. Zastupitelnost a dostupnost platí od momentu uložení tohoto nastavení. Pozn.: Přihlášený uživatel neuvidí barevnou změnu symbolu panáčka po uložení změny dostupnosti, dokud neprovede nové přihlášení do systému. Jedná se pouze o grafický efekt. Po uložení bude zobrazena karta přihlášeného uživatele, kde může řešitel upravit své kontaktní údaje tlačítkem Editovat. Přehled požadavků který má zastupující řešitel se zástupu zobrazí vlevo nahoře ve scoreboardu: Strana 39 / 69
Přehled vybraných Aktivit a Přehled rychlých informací o tiketu Pro přehlednější práci s tikety přibyla v seznamu tiketů funkce Přehled vybraných aktivit a v detailu požadavku Přehled rychlých informací o tiketu. Přehled vybraných aktivit se nachází v levém sloupci v seznamu tiketů. Po rozkliknutí přehledu bude zobrazen přehled důležitých aktivit, které na dotčeném tiketu proběhly, v novém okně. Tlačítkem tisknout je možné tento přehled vytisknout, tlačítkem obnovit je možné obnovit stránku, načíst a zobrazi nové aktivity, které se na tiketu odehrály od otevření okna. Strana 40 / 69
Přehled rychlých informací o tiketu je zobrazen zeleným písmem pod číslem tiketu v levém horním rohu. Možné informace k zobrazení: Informace o nedostupnosti řešitele, kontakt a telefon zástupu Zda tiket obsahuje přílohu a číselný počet příloh. Zda je tiket vytvořen z kopie tiketu. Záložka 1. Další informace, sekce Diskuze: Seznam diskuzních aktivit 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. Strana 41 / 69
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 Diskuze i manuálně (např. v případě funkcí Požadovat součinnost nebo Přidat komentář). 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. Z komunikace budou v diskuzi uloženy Komentáře a uživatelské popisy ze všech aktivit. Strana 42 / 69
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. 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 je možné podle klíčových slov. Další parametry vyhledávání lze zvolit prostřednictvím odkazu Zobrazit Filtr Znalostní Báze. Strana 43 / 69
5.1.2 Vyhledávání v kontextu konkrétního tiketu 1) Ve formuláři requestu klikneme na záložku Management Znalostí část Znalosti. Přímo z formuláře Požadavku 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 Popis. 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 44 / 69
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 Akceptovat jako Řešení svázat dokument s požadavkem a následně změnit stav požadavku na vyřešený. Položky dostupné v Možnostech stránky 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 Řešitele. Položka Akceptovat jako Řešení je dostupná pouze, pokud je dokument zobrazen v kontextu řešeného požadavku/incidentu/problému/změnového požadavku. Strana 45 / 69
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 tlačítko Vyřešit tiket a v okně Změna stavu požadavku XX doplníte do pole Uživatelský popis popis řešení a zmáčknete Předložit znalosti. 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 Řešení je možné formátovat pomocí html formátovacích znaků. Strana 46 / 69
Jednoduchý editor pro formátování zobrazíte zmáčknutím tlačítka Změnit Řešení. Příklad vidíte na následujícím obrázku: Strana 47 / 69
Zmáčknutím tlačítka OK uložíte takto formátovaný text do pole Řešení. Pro uložení záznamu do znalostní databáze zmáčkněte tlačítko Uložit, nebo Uložit a Zavřít 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 48 / 69
6. Zobrazení oblasti Oznámení Oprávnění publikovat oznámení pro ostatní uživatele má pouze správce systému. Publikovaná oznámení v rozhraní řešitele lze zobrazit na záložce Service Desk menu Zobrazit položka Oznámení. Oznámení jsou také výchozím zobrazením po přihlášení do systému. Strana 49 / 69
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 Reporty položka Detail: 2. Z obrazovek seznamů požadavků, incidentů, problémů a změn Menu Reporty položka Shrnutí: Tiskové sestavy obsahují základní údaje o vybraných záznamech. Z obrazovek seznamů je možno údaje pomocí tlačítka Exportovat vyexportovat do souboru XLS a dále zpracovávat např. v Excelu. Vybrané role (Reporter) 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 50 / 69
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. 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. 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) Strana 51 / 69
2 - funkčnost systému nebo dostupnost pro uživatele je omezena, zařízení je poškozené, spěšný požadavek. 3 - na systému se vyskytuje problém, který zásadním způsobem neomezuje funkčnost systému, zařízení je poškozené, běžný požadavek. 4 - uživatel má evidovaný požadavek, není vyžadováno okamžité řešení, problém je možno odstranit v průběhu běžné pracovní doby. Lze nahradit provizorním řešením. 5 - uživatel má evidovaný požadavek. Termín jeho vyřešení není z jeho pohledu významný a řešení nechává na možnostech poskytovatele služeb. 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. Strana 52 / 69
Čí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. Strana 53 / 69
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 využít: Vkládání komentářů pomocí Vložit Komentář a Příloh s následnou notifikací o vložení komentáře/přílohy Odesílání Manuální notifikace pomocí Manuální Notifikace (řešitel) Strana 54 / 69
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 probíhá napřímo standardní cestou požadavku. Řešitelská skupina je vybrána automaticky, dle uživatelem vybrané Kategorie požadavku Strana 55 / 69
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ší Oblasti Požadavku změny stavů pomocí aktivity Update Status při Reklamaci a Poskytování součinnosti využít Manuálních notifikací Požadavky, které vyžadují před zahájením řešení schválení (Oblast požadavku z části J) Schvalovací skupiny APP ), 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 Vložením komentáře ke schválení pomocí aktivity Přidat komentář Strana 56 / 69
Odmítnutí standardní postup řešitele při Odmítnutí požadavku Řešení standardní postup řešení přiděleného požadavku 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í Oblast požadavku - kontakt Operátor L2 60 minutách od přiřazení Oblast požadavku manager řešitelské skupiny, skupina MNG_SD 90 minutách od přiřazení Oblast požadavku - skupina MNG_IT Po vypršení 90 minut je nastaven k požadavku příznak nesplnění doby odezvy. Stavy požadavku v průběhu řešení Stav Zadaný V řešení Vyřešený Čeká na součinnost Součinnost poskytnuta Uzavřený Odmítnutý Zrušený Vypořádaný Popis Požadavek zadaný do SDM, před kontrolou kategorie, priority a přidělením řešitele Požadavek, který má přiděleného řešitele. V případě, že uživatel obdržel notifikaci o vyžádané součinnosti, bude řešitel pokračovat v řešení, až po obdržení této součinnosti. Požadavek, u kterého řešitel popsal řešení a běží u něj čas pro reklamaci. Uživatel je o změně stavu informován mailem. Řešitel čeká na součinnost, aby mohl pokračovat v řešení Řešitel dostal potřebné informace a bude pokračovat v řešení Požadavek, který je neaktivní a u kterého nebylo řešení rozporováno. Požadavek, který nespadá svým charakterem do oblasti, kterou poskytovatel služeb podporuje, nebo nebyl vznesen oprávněným uživatelem Požadavek, který již nebude dále řešen Požadavek, který byl zpracován v rámci vypořádání uplynulého období. Není ho možno dále upravovat. Strana 57 / 69
Ke schválení Reklamace Požadavek, jehož řešení musí být nejprve schváleno Požadavek, u něhož byla vznesena oprávněná reklamace řešení 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 Přidat komentář vložením komentáře a přes tlačítko Aktualizovat stav změní stav na čeká na součinnost. Po obdržení odpovědi od uživatele přes tlačítko Aktualizovat stav změní stav na Součinnost poskytnuta a dále pokrač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.Vztahy a Aktualizovat Podřízené a dále přes tlačítko Hledat vyhledá a vloží.. U původního požadavku přes tlačítko Aktualizovat stav změní stav na čeká na součinnost a přes tlačítko Přidat komentář 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 Aktualizovat stav 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 Dotčený Uživatel 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 Přidat komentář 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ý. 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 Dotčený Uživatel 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 Přidat komentář 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 58 / 69
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 Vytvořit Incident u Požadavku: V tom případě jsou přenesena pole Oblast Incidentu, Nahlásil, Urgence, Shrnutí a Popis Operátor doplní všechna zbývající povinná (označena hvězdičkou) pole, zkontroluje správnost přiřazení Oblast řešení incidentu a Priorita. Tyto dva atributy určují jaké SLA bude na incidentu platné. Incident uloží pomocí tlačítka Uložit. Následující řešení incidentu řešitelem zachovává pricipy zpracování popisované v předchozích kapitolách. (převzetí do řešení pomocí Převzít tiket, Manuální Notifkace, změny stavů pomocí Aktualizovat stav, Přidat komentář, 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 Převzít tiket a stav V řešení ) změní stav pomocí aktivity Aktualizovat stav 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 Oblasti řešení Incidentu nastaví skupina řešitelů, properties a Service Type SLA pro sledování Response Time a Fix Time. Splnění Doby odezvy je dosaženo změnou stavu požadavku ze stavu Zadaný (i odmítnutí je považováno za splnění Doby odezvy). Splnění Doby vyřešení 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. Další informace část 3 Typ služby. Strana 59 / 69
Schéma zobrazuje obecný postup při zpracování incidentu, který vzniká na základě požadavku zadaného uživatelem. Strana 60 / 69
Nastavení Service Type STIMSZR Aktivita Událost Čas od startu Service Type SZR P2-15 minut response SZR P2 15 minut response 15 min SZR P1-15 minut response SZR P1 15 minut reponse 15 min SZR P1-20 minut response SZR P1 20 minut response 20 min SZR P1-23 minut response SZR P1 23 minut reponse 23 min SZR P2-30 minut response SZR P2 30 minut response 30 min SZR P1-30 minut response SZR P1 30 minut reponse 30 min SZR P2-45 minut reponse SZR P2 45 minut reponse 45 min SZR P3 60 minut response SZR P3 60 minut response 1 hod SZR P2-60 minut reponse SZR P2 60 minut reponse 1 hod SZR P1-50% SLA SZR P1 50% SLA 2 hod Strana 61 / 69
SZR P3-120 minut reponse SZR P3 120 minut reponse 2 hod SZR P3-180 minut reponse SZR P3 180 minut reponse 3 hod SZR P1-75% SLA SZR P1 75% SLA 3 hod SZR P2-50% SLA SZR P2 50% SLA 3 hod SZR P1 - SLA Violated SZR P1 SLA Violated 4 hod SZR P3-4 hodin reponse SZR P3 4 hodin reponse 4 hod SZR P2-75% SLA SZR P2 75% SLA 3:40 hod SZR P4 5 hodin response SZR P4 6 hodin response 5 hod SZR P2 - SLA Violated SZR P2 SLA Violated 6 hod SZR P4 12 hodin reponse SZR P4 12 hodin reponse 12 hod SZR P3 50% SLA SZR P3 50% SLA 12 hod SZR P4 18 hodin reponse SZR P4 18 hodin reponse 18 hod SZR P3 75% SLA SZR P3 75% SLA 18 hod SZR P4 NBD response SZR P4 NBD minut reponse 24 hod SZR P3 SLA Violated SZR P3 SLA Violated 24 hod SZR P4 50% SLA SZR P4 50% SLA 84 hod SZR P4 75% SLA SZR P4 75% SLA 114 hod SZR P4 SLA Violated SZR P4 SLA Violated 168 hod Stavy incidentu v průběhu řešení Stav Zadaný V řešení Vyřešený Čeká na součinnost Součinnost poskytnuta Uzavřený Odmítnutý Zrušený Popis Incident zadaný do SDM, před kontrolou kategorie, priority a přidělením řešitele 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. 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. Řešitel čeká na součinnost, aby mohl pokračovat v řešení Řešitel dostal potřebné informace a bude pokračovat v řešení Incident, který je neaktivní a u kterého nebylo řešení rozporováno. Incident, který nespadá svým charakterem do oblasti, kterou poskytovatel služeb podporuje, nebo nebyl vznesen oprávněným uživatelem Incident, který již nebude dále řešen Strana 62 / 69
Vypořádaný Reklamace Incident, který byl zpracován v rámci vypořádání uplynulého období. Není ho možno dále upravovat. Incident, u něhož byla vznesena oprávněná reklamace řešení Strana 63 / 69
10. Scoreboard Oblíbené Scoreboard obsahuje položku Oblíbené do které může řešitel ukládat tikety, označené jako oblíbené (Více v kapitole 4.9.2). Rozkliknutí této položky zobrazí seznam všech oblíbených tiketů. Spravovat oblíbené položky je možné kliknutím na Upravit v pravém sloupci upravit oblíbené. Pozn.: Pokud na tiketu dojde ke změně řešitelské skupiny a řešiteli ztratí práva viditelnosti tiketu, bude v seznamu prázdná položka s informací, že tiket nelze dohledat. Možnost upravit tuto položku však zůstane je tedy možné takové tikety z oblíbených odstranit. Strana 64 / 69
Definice Scoreboardu pro Operátor L1 Strana 65 / 69
Definice Scoreboardu pro OperátorL2 Strana 66 / 69
Definice Scoreboardu pro Řešitel Strana 67 / 69
11. Podstatné změny Pro přehled uvádíme kapitolu podstatné změny, kde na příkladu uvedeme změny tlačítek a aktivit při vypořádávání tiketu a stručně vyjmenujeme nové vlasntosti. Vypořádání tiketu Starý stav: Staré menu s přehledem Activities a třemi tlačítky v hlavičce bylo nahrazeno, jak je patrné z následujícího obrázku: Menu Activities bylo lokalizováno na Aktivity Update Status => Aktualizovat stav Callback => Aktivita přesunuta na tlačítko Požadovat Součinnost Research Odstraněno Log Coment => Aktivita přesunuta na tlačítko Přidat komentář Solution => Aktivita přesunuta na tlačítko Vyřešit tiket Transfer => Převzít tiket Escalate => Escalace (Pouze Operátor) Manual Notify => Manuální Notifikace Strana 68 / 69