Toto je objekt systému MBI.

MBI (Management Byznys Informatiky) je portál obsahující zobecněná řešení v řízení provozu a rozvoje IT, resp. podnikové informatiky.

Pokud máte zájem získat více informací o tomto objektu (vazby na další objekty, přílohy, apod.), ale i získat mnoho dalších užitečných materiálů, můžete tak učinit ZDE / (registrace je bezplatná).

Úloha : Řízení interního service-desku
Řízení interního service-desku
Kód úlohy

Standardní kód úlohy v MBI.

:
U734B
Autor návrhu úlohy

Jméno a příjmení autora úlohy

:
Labant, P., Votruba, T. (KIT, VŠE)
Datum poslední úpravy

Datum poslední úpravy úlohy ve tvaru rrrr.mm.dd.

:
2015-01-19
Předpokládaná pravděpodobnost užití v praxi

Předpokládaná pravděpodobnost užití úlohy v praxi, hodnoty 0 - 1. Např. 0,7 - úlohu lze využít v 7 z 10 podniků. Hodnoty jsou průběžně testovány a upřesňovány na základě anket a průzkumů.

:
0.8
Charakteristiky úlohy

Charakteristiky úlohy

1. “Řízení interního service-desku“ – cíl, účel
  • Cílem úlohy je zřízení a zajištění fungování interního Service-desku organizace .
  • Service-desk je funkční jednotka tvořená skupinou pracovníků zodpovědných za řešení různých servisních událostí. Je to primární kontakt pro uživatele ve chvíli, kdy dojde k narušení dodávané služby, pro požadavky na služby, nebo pro některé druhy požadavků na změnu.
  • Service-desk poskytuje komunikační kanál pro uživatele a bod koordinace pro několik IT skupin a procesů.
  • Hlavní cíl Service-desku je obnovení „normálního chodu služby“ pro uživatele, jak nejrychleji je to možné. Toto je myšleno v nejširším slova smyslu a může zahrnout opravení chyby, nebo zodpovězení dotazu , zkrátka vše, co je zapotřebí k tomu, aby mohl uživatel službu využívat v plném rozsahu.
  • Zatímco dobrý Service-desk dokáže nahradit nedostatky podnikové informatiky, špatný Service-desk snadno přenese velmi špatný dojem na celou i když dobře fungující podnikovou informatiku.
2. Obsah úlohy
  • Interní Service-desk poskytuje servisní služby pro interní zaměstnance organizace , nikoliv pro externí zákazníky. Úloha řeší :
    • jakou organizační strukturu zvolit pro interní Service-desk na základě velikosti a především geografickém rozložení organizace,
    • jak rozdělit potřebné činnosti mezi personál a zařídit tak efektivní fungování Service-desku i při velkém vytížení,
    • jakým způsobem vyhodnocovat fungování Service desku a jaké metriky při tom zvolit.
  • Z hlediska řešení problémů, uživatelských požadavků a incidentů se tato úloha zabývá pouze jejich evidencí v informačním systému . Postupy podle kterých jsou jednotlivé hlášení řešeny, zpracovávají úlohy (U731A ) Řízení incidentů, (U732A ) Řízení problémů, (U733A ) Řízení uživatelských požadavků, které navazují na zaevidování hlášení do systému.
3. Vstupy úlohy:
  • Katalog požadavků na IT (D042A ),
  • Katalog IT služeb (D111A ),
  • Evidence incidentů a problémů a jejich řešení (D721A ),
  • RFC, požadavek na změnu (D725A ),
  • Návrh na změnu kontraktu a SLA (D726A ).
4. Výstupy úlohy:
  • Dokumentace provozu service-desku (D723A ),
  • Katalog požadavků na IT (D042A ), aktualizovaný,
  • Protokol změnového řízení (D724A ),
  • Katalog IT služeb (D111A ), aktualizovaný.
5. Podmínky úspěšnosti úlohy
  • Service-desk by měl za všech okolností působit jednotně, to znamená, že nezávisle na jeho organizační struktuře by mělo být zřízeno jedno telefonní číslo (jedna emailová adresa), pomocí kterého mohou uživatelé service-desk kontaktovat. Doporučované komunikační kanály jsou telefon a email. Email by měl být využíván pro méně akutní situace.
  • Doporučované komunikační kanály jsou service desková aplikace (aplikace pro správu a řízení požadavků), telefon a email .
  • Vhodnost jednotlivých komunikačních kanálů vždy závisí na typu firmy, jejich pracovních procesů a typu požadavku . Pokud se jedná o urgentní požadavek vyžadující okamžitý zásah, je nejlepší volbou telefon .
  • V ostatních případech je vhodnější použít service deskovou aplikaci a to především kvůli výhodám, které přináší oproti emailům (požadavek je evidován do systému již samotným zadavatelem, což činí celý proces jednodušší:*
  • není nutné zahlcovat poštovní schránky zbytečnými emaily ohledně specifikace požadavku,
    • vše je možné uvést v dané aplikace, kde by u každého požadavku tyto informace
    • stejně měly být. jednodušší řízení a řešení požadavku, kdy řešení daného požadavku zajišťuje více řešitelů, atd.
6. Doporučené praktiky
  • Pracovníci service-desku musí zaregistrovat každý kontakt s uživateli do systému,
  • Vzhledem k tomu, že service desk je interně rozdělený na specializovaná oddělení, ale pro komunikaci s vnějškem používá jednotné komunikační kanály, je potřeba zařídit rozdělení uživatelských požadavků ještě před kontaktem s pracovníky primární podpory .
  • V případě využití service deskové aplikace je požadavek pouze zaevidován do systému a proces přiřazení požadavku je v režii pracovníků service desku , kteří vychází z interní dokumentace, kde je definováno, jaké oddělení řeší jaký typ požadavku.
  • V případě telefonního hovoru na univerzální číslo service deskové podpory bude daný požadavek řešit pracovník service desku na lince, pokud však tento typ požadavku nebude spadat do jeho kompetencí (viz interní dokumentace), přepojí zadavatele požadavku na odpovědného pracovníka (oddělení).
  • V pravidelném období (měsíc nebo kvartál) je vhodné vypracovávat protokol o provozu service-desku, který slouží jako podklad pro analýzy požadavků a je jedním ze vstupů pro řízení dalšího rozvoje služeb,
  • Pokud jde o metriky úlohy, pak jde o celý systém metrik , který je definován v části MBI - Metriky.
7. “Řízení interního service-desku“ - klíčové aktivity

7.1. Zřízení Service-desku
  • Jedná se o komplexní úlohu , která zahrnuje vybudování organizační struktury a určení činnosti pracovníků.
  • Organizační struktura - organizační strukturu ovlivňuje především geografická organizace podniku :
    • Střední až velký podnik s jedním místem působení - je vhodné použít centralizovanou organizační strukturu, aby mohli pracovníci service-desku efektivně spolupracovat.
    • Střední až velký podnik s více pobočkami v jedné zemi - je nutné zajistit pracovníky, kteří by mohli v případě vzniku incidentů a problémů tyto události včas řešit. Není však nutné, aby byli přímou součástí service-desku, může se jednat o pracovníky třetí podpory. Je ale vhodné zařídit centrální Service-desk na jedné pobočce organizace, alespoň pro jedno organizační oddělení (zde závisí organizační struktura service desku na velikosti jednotlivých poboček v dané zemi a jejich významu z pohledu businessu. Pokud jsou všechny pobočky stejně velké a významné, je vhodné zvolit spíše decentralizační organizační strukturu Service-desku, aby byla zajištěna okamžitá lokální technická podpora (především v případě hardwarových problémů, které se nedají řešit pomocí nástrojů pro vzdálenou správu).
    • Velký nadnárodní podnik s pobočkami ve více zemích - je vhodné zařídit service-deskové centrum pro každou zemi.
  • Personál - rozdělení rolí mezi pracovníky záleží na velikosti specializovaného oddělení service-desku a kvalifikaci pracovníků:
    • Primární podpora - hlavní činností je styk se zákazníkem. Jedná-li se o velmi jednoduchý problém, který lze vyřešit během prvního telefonátu, může spolu se zákazníkem problém vyřešit. V opačném případě předá pracovník primární podpory problém pracovníkovi sekundární podpory k vyřešení.
  • Sekundární podpora - hlavní činností je řešení hlášení zákazníků a evidence řešení do znalostní databáze pro případné znovupoužití. Na tuto roli jsou vyšší nároky z hlediska technické odbornosti a všeobecného přehledu o infrastruktuře a aplikacích používaných v podnikové informatice, požadavek na komunikační dovednosti zůstává,
  • Supervizor - má za úkol koordinaci ostatních pracovníků service-desku a rozdělení jejich rolí na základě okamžitých potřeb a vytížení service-desku.
7.2. Registrace uživatelských požadavků
  • Registrace uživatelského požadavku musí minimálně obsahovat:
    • ID požadavku,
    • Datum zadání,
    • Délka hovoru hlášení (v případě využití service deskové aplikace není tato položka nutná),
    • Rozřazení na incidenty, problémy a požadavky na změnu,
    • Oblast, které se problém týká spolu s co nejpodrobnějším popisem problému zákazníkem,
    • Popis současného stavu problému,
    • Jméno/a řešitele/ů (požívá se pro interní potřeby service-desku, z hlediska okolí je za řešení problému vždy zodpovědný service-desk jako takový),
    • Doba strávená řešením hlášení,
    • Datum uzavření,
    • Popis řešení.
7.3. Eskalace problému
  • Pokud service-desk není schopen řešit problém sám, je nutné z ajistit předání problému k řešení kompetentním specialistům . Je nutné připravit pravidla , podle kterých budou pracovníci service-desku eskalovat problémy a připravit vazby na třetí linii podpory , tedy místo, kam budou problémy eskalovány.
  • Třetí linie podpory může být jak vnitropodniková nebo externí (service-desk dodavatele). Třetí linie podpory by měla obsahovat role:
    • Správce aplikací a IT služeb,
    • Správce serverů,
    • Správce počítačové sítě,
    • Správce webu,
    • Specialista v oblasti IT bezpečnosti.
  • Tito pracovníci samozřejmě musí vědět, že jsou součástí třetí linie podpory , a že na ně budou směřovány problémy, které se jich týkají. Tato vazba by měla být součástí klasické struktury organizace.
  • V individuálních případech malé IT organizace mohou tito pracovníci být přímo součástí Service-desku .
  • V případě vazeb na externí dodavatele je nutné tyto vazby zajistit servisní smlouvou (SLA) a stanovit podmínky , za kterých je možné předat problém dodavateli. Tato smlouva je běžnou součástí v případě dodání informačního systému externím dodavatelem a ve většině případů ji navrhuje dodavatel.
  • Zároveň je nutné zajistit, aby vlastníkem eskalovaného problému zůstal Service-desk . Ten zodpovídá za jeho vyřešení a spravuje zákazníka o postupu.
  • Podstatná je také podrobná interní dokumentace procesu Eskalace problému, aby jednotliví pracovníci service desku přesně věděli, jak mají v takovýchto případech postupovat a jak jsou jednotlivé činnosti a aktivity definovány.
7.4. Uzavření problému
  • Při vyřešení problému je zapotřebí zajistit, aby pracovník, který měl problém na starost, informoval zákazníka (zadavatele problému) o jeho vyřešení a zdokumentoval postup řešení problému.
  • Doporučuje se pracovníky proškolit jak evidovat a uzavírat problémy a jak zapisovat řešení do informačního systému. Tento postup se bude lišit v závislosti použitých programech pro service-desk.
  • Dobře vedená databáze znalostí řešených problémů umožňuje jednoduché a efektivní řešení příštích problémů.
7.5. Reporting
  • Obsahem je získávání a vyhodnocování informací dle metrik . Všechny metriky je možné sledovat v informačním systému, za předpokladu, že pracovníci budou správně zadávat hlášení do systému.
  • Pro sledování metrik je zapotřebí vytvořit dotazník, který se bude týkat spokojeností uživatelů se službami service-desku. V systému je možné sledovat uživatele, kteří zadali požadavek na service-desk v určitém periodickém období (např. měsíc). Ty je posléze vhodné zpětně oslovit (např. emailem) a požádat o vyplnění dotazníku ohledně služeb service-desku.
  • Takový dotazník je vhodné umístit na intranet a v žádosti o vyplnění dotazníku přiložit odkaz, pro snadné nalezení umístěného dotazníku.
  • Tato metoda poskytuje dostatečnou volnost pro pracovníky , že mohou napsat svou zpětnou vazbu v době, kdy na to mají čas, dále odpovídá každý sám za sebe, odpadá tedy riziko, kdy dominantní pracovník přenese svůj názor na ostatní a zároveň je možné touto metodou vybrat pouze ty pracovníky, kteří se service-deskem v poslední době komunikovali.
  • Metriky je možné v informačním systému obvykle sledovat s využitím přehledného operačního dashboardu .