Helpdesk: Klíč ke kvalitnímu IT

Menší i větší společnost jednou dospěje do stadia, kdy zjistí, že je třeba konsolidovat správu incidentů tak, aby nic nebránilo dalšímu rozvoji a zefektivňování jednotlivých činností.

Helpdesk: Klíč ke kvalitnímu IT


Podíváme-li se na to konkrétně, například pouze v IT jde především o řešení dvou oblastí. V prvé řadě o řešení incidentů vznikajících nahodile v rámci nepředpokládaných událostí, jako jsou například nefunkční tiskárny, poškození PC a podobně. Druhá skupina zahrnuje činnosti, které jsou buď pravidelné, nebo předvídatelné, jako je údržba, činnosti související se správou uživatelských účtů atd. Jak pro nahodilé události, tak pro pravidelné či předvídatelné incidenty je s úspěchem využíván systém s obecným pojmenováním HelpDesk.

Osobně jsem se zúčastnil mnoha výběrových řízení právě na helpdeskový systém a musím potvrdit, že požadavky na tyto systémy jsou velmi různé. Na druhou stranu jsou si v základních rysech velmi podobné. Tento protimluv mohu jednoduše vysvětlit. Účel vybíraného systému je vždy stejný, proto i primární požadavky jsou téměř shodné. Rozdíly nastávají až v jednotlivých speciálních požadavcích podle konkrétní oblasti nebo konkrétního způsobu použití. Abych své tvrzení doložil, pokusím se uvést příklad imaginárního výběrového řízení. Ukážeme, jaké požadavky mohou klienti mít a jaké možnosti jim naopak helpdeskové systémy nabízejí. Zároveň se pokusíme ukázat důležitost implementační fáze tohoto systému.

Motivace pro HelpDesk

Prapočátkem rozhodnutí o nákupu helpdeskového systému je zjištění, že něc­o nebo někdo nefunguje správně a/ /nebo by mohlo fungovat lépe. Abychom byli schopni toto fungování zlepšit, potřebujeme především spolehlivou evidenci požadavků a mít vždy aktuální přehled o stavu jejich řešení. To jsou téměř vždy první a základní požadavky na systém, se kterými se setkáváme. Následují požadavky na možnost statistického vyhodnocování, možnost modelace procesů zpracování požadavku, sofistikovaný systém oprávnění, možnost modifikace doplňkových polí a v neposlední řadě provázanost – propojitelnost na jiné systémy využívané v dané společnosti.

Opravdu ale chcete, aby si zodpovědní pracovníci „hráli“, ladili jednotlivé nuance, vymýšleli nová a ještě složitější workflow a strávili svůj pracovní čas v rámci administrace HelpDesku? Nebo aby se systém zprovoznil tak, aby splňoval naše potřeby a zaměstnanci se mohli věnovat své práci?

Tím rozhodně nechci tvrdit, že možnosti nastavení jednotlivých vlastností jsou nežádoucí, ale vždy je třeba stanovit míru rozsahu modifikací. Tak, aby se tyto možnosti nestaly kontraproduktivní. Neboť vždy se najde požadavek, který nebude možno splnit prostým nastavením tlačítka nebo pole.

Požadavky na HelpDesk

Podívejme se tedy na jednotlivé požadavky trochu podrobněji. Jako první je vždy uváděna přehlednost a prokazatelnost. To splňuje naprostá většina nabízených produktů. Každý má o trochu jiné možnosti, ale pokud byste chtěli hodnotit podle tohoto kritéria, vyhověla by naprostá většina. Taktéž, většina systémů poskytuje následné možnosti statistického vyhodnocení nasbíraných dat. Ale již jsou zde mnohem větší rozdíly v možnostech a způsobu zpracování než v předchozím požadavku. Otázka modifikace workflow, modifikace políček formuláře nebo možnosti provázání s jiným systémem již jednotlivé systémy prověří důkladněji. Jsou však tyto požadavky tak důležité, abychom se podle nich rozhodovali?

V naprosté většině implementací, které jsme realizovali, došlo k nastavení workflow, polí, oprávnění atd. v rámci nasazení produktu. A následně již docházelo k málo změnám. A tyto spíše souvisely se změnami v procesech společnosti nebo s novými produkty než s potřebou něco měnit nebo modifikovat. Pokud jde o provázání různých systémů, i zde je situace trochu jiná, než by se mohlo na první pohled zdát. Různé systémy podporují různá rozhraní (webové služby, XML, strukturovaný e-mail, atd.) A i když se náhodou shodnou na stejném rozhraní, je třeba řešit kompatibilitu dat, jejich strukturu atd. Jak tedy najít optimální hranici mezi univerzálností a možností úprav? Na tuto otázku si musí každý odpovědět sám. Je třeba zhodnotit předpokládané množství následných změn.

Pro lepší představu uvedu několik základních požadavků, které se často opakují. Sami si pak můžete zhodnotit, zda i vy uvažujete podobně, nebo máte úplně jiné potřeby a představy.

  • Evidence zadaných incidentů s historií změn
  • Příjem požadavku e-mailem
  • Modifikace a různá workflow pro jednotlivé oblasti (kategorie) incidentů
  • Modifikace polí ve formuláři
  • Externí formulář s možností přijetí požadavku
  • Statistiky řešených i vyřešených incidentů
  • Upozornění – eskalace v souvislosti s požadavky na termín řešení
  • Možnost nastavit oprávnění pro jednotlivé skupiny incidentů
  • E-mailová notifikace při vzniku nebo změně požadavků
  • A mnoho dalších

Zatím zde však nezazněl požadavek, se kterým se setkáváme v mnohem menší míře, ale který má dle mého názoru mnohem větší vliv na úspěšné používání helpdeskového systému. A to je požadavek na maximálně jednoduché zadání požadavku. A teď nemyslím prosté zaslání požadavku e-mailem na definovanou adresu. Zpracování e-mailu má v sobě velká většina nabízených systémů. A je jen otázkou implementace, do jaké míry bude takto přijatý požadavek „inteligentně“ zpracován. Mám na mysli optimalizaci zadání požadavku v rámci helpdeskového rozhraní jako takového. Jde o to, najít míru přenesení zodpovědnosti a fundovanosti posouzení požadavku na samotného autora (uživatele).

Například, pokud se uživateli zobrazí formulář, na první pohled nepřehledný s množstvím políček, s množstvím sice logických, ale přitom pro uživatele těžko pochopitelných kontrolních vazeb, je téměř jisté, že uživatel raději vezme telefon a zavolá příslušné osobě, než aby vždy absolvoval strastiplnou cestu vyplnění formuláře.

Přínosy helpdeskového řešení

V souvislosti s vývojem helpdeskového řešení jsme provedli praktický test na vzorku dvaceti průměrných uživatelů. Připravili jsme několik obecně užívaných systémů a požádali uživatele, aby zadali tři cvičné požadavky. Každý požadavek z  jiné oblasti problémů. Musím přiznat, že výsledky nás překvapily. Průměrný čas se pohyboval od 10 sekund po necelé dvě minuty. A zvláště systémová upozornění o nutnosti vyplnění některých polí (např. síťová nebo lokální tiskárna?), byl pro uživatele opravdu oříšek. Jediná rada z tohoto pohledu je – každý systém si vyzkoušejte osobně. Nespokojte se pouze s předvedením. Za hodinu nebo dvě, kdy prezentující kliká a ukazuje systém, se většinou vše zdá být ideální a jednouché. Ale až v okamžiku, kdy si k systému sednete osobně, zjistíte, že byste mnoho věcí řešili jinak a lépe.

Velmi důležitou částí celého procesu zavádění každého helpdeskového systému je fáze provedení uživatelských úprav a následná implementace s uvedením do provozu. Možnosti i ochota tvůrců systému jsou v těchto fázích velmi důležité. Nezřídka se setkáváme s neochotou cokoli měnit pouze pro jednoho klienta. Ať je důvod jakýkoliv, např. snaha o udržení jednoho krabicového řešení nebo nemožnost měnit systém třetí strany, jde vždy o vážný problém. Jak jsem již říkal, každá společnost je v důsledku unikátní a zaslouží si, ale většinou i vyžaduje unikátní řešení.

Projdeme-li všemi úskalími od výběru přes provedení uživatelských změn až po úspěšné nasazení, můžeme se těšit na zpřehlednění celé agendy, zprůhlednění prováděných činností a tím zvýšení efektivity práce. V důsledku toho zkrácení času potřebného pro řešení a tím snížení nákladů. Na spokojené uživatele, klienty i zaměstnance. A to by měl být náš cíl, ke kterému společně s helpdeskovým systémem chceme dojít.





Komentáře