Anotace
Bakalářská práce se soustředí na oblast zákaznické podpory a interních systémů. Práce zahrnuje návod, jak správně a efektivně telefonicky komunikovat se zákazníky a poté se věnuje všem možným komunikačním kanálům, které má podnik k dispozici pro komunikaci se zákazníky. Následně práce uvádí již samotnou implementaci aplikace Helpdesk a dalších interních systémů, které se výrazně podílí na zákaznické podpoře. Dále se práce zaměřuje na další možná zlepšení, která by měla vést ke zrychlení a zefektivnění komunikace se zákazníky. V závěru práce je analýza nově implementovaného systému pro zjednodušení komunikace mezi odděleními, které zpracovávají požadavky zákazníků.
Klíčová slova
Helpdesk, implementace, interní komunikace, zákaznická podpora
Annotation
Implementation of support communication with customer
The bachelor thesis focuses on the field of customer support and internal systems. The content includes firstly instruction how communicate with customer correctly and effectively, secondary all communication channels, that are available for the company to communicate with customers. Subsequently the thesis introduces whole implementation of Helpdesk application and other internal systems that significantly contribute to customer support. Furthermore, the paper focuses on other possible improvements that should lead to make communication with customers quicken and more effective. In conclusion of thesis is analysis of the newly implemented system for simplification of communication between the departments, which are solving the customer requests.
Key Words
Customer support, helpdesk, implementation, internal communication
Poděkování
V úvodu bych chtěl poděkovat všem, kteří se podíleli na vzniku této bakalářské práce.
Především Ing. Davidu Kubátovi, Ph.D., ING.PAED.IGIP za odborné vedení, pomoc a rady při zpracování této práce. Dále bych chtěl poděkovat celému oddělení Podpora v podniku INISOFT s.r.o., a to zejména Mgr. Tomáši Čejchanovi a Bc. Vojtěchu Starému za odborné rady, poskytnutí podkladů, trpělivost a ochotu.
Obsah
Seznam zkratek ... 11
Seznam obrázků ... 12
Úvod ... 13
1. Jak efektivně komunikovat se zákazníkem ... 14
1.1 Aktivní poslech ... 14
1.2 Vyhnutí se negativním otázkám ... 14
1.3 Citlivost na rozdíly v technických znalostech ... 15
1.3.1 Využívání analogie pro vysvětlení technických konceptů ... 15
1.4 Pozitivní přístup ... 15
1.5 Předvídání námitek a dotazů zákazníků ... 15
2. Aktuální stav v oblasti zákaznické podpory ... 16
2.1 Komunikační kanály ... 16
2.1.1 Tištěné brožury a návody... 16
2.1.2 Telefonická podpora ... 16
2.1.3 E-mail a Helpdesk ... 17
2.1.4 Sociální sítě... 18
2.1.5 Zabudovaný chat na webových stránkách ... 18
2.1.6 Databáze znalostí ... 18
3. Implementace systému Helpdesk a její fáze ... 20
3.1 Plánování workflow a procesů ... 20
3.1.1 Určení procesů ... 21
3.1.2 Vytvoření workflow pro řízení procesů ... 21
3.2 Instalace a základní konfigurace ... 21
3.2.1 Instalace Helpdesku ... 21
3.2.2 Import kontaktů ... 22
3.2.3 Přidání pracovníků ... 22
3.2.4 Nastavení politik ... 23
3.2.5 Definice kategorií ... 23
3.2.11 Definujte zásady oznámení na serveru oznámení ... 27
3.2.12 Definice šablony e-mailů ... 27
3.2.13 Definice schránky elektronické pošty a filtrů doručené pošty ... 27
3.3 Pokročilá konfigurace ...28
3.3.1 Definice inteligentních úkolů ... 28
3.3.2 Definice rychlých ticketů ... 29
3.3.3 Definice běžných dotazů ... 29
3.3.4 Integrace řešení Helpdesku s jinými systémy pomocí webových služeb ... 29
3.3.5 Import dokumentace do databáze znalostí Helpdesk... 30
3.3.6 Definice nových přehledů ... 30
3.4 Popis zákaznické podpory u jiných podniků ...30
3.4.1 Podnik 1 ... 31
3.4.2 Podnik 2 ... 31
3.5 Současný stav zákaznické podpory v podniku ...31
3.5.1 Telefonická komunikace ... 32
3.5.2 E-mailová komunikace ... 32
4. Implementace nového prostředí ... 33
4.1 Výběr systému ...33
4.2 Úvodní nastavení ...34
4.3 Uživatelské účty ...35
4.4 Skupiny operátorů...36
4.5 Zákazníci ...36
4.6 Katalog služeb ...37
4.7 Tvorba workflow ...37
4.8 Uživatelské formuláře ...38
4.9 Správa e-mailů ...39
4.10 Konečné nastavení ...39
5. Další interní systémy ... 40
5.1 Confluence ...40
5.1.1 Co je vlastně Confluence ... 41
5.1.2 Centrum informací ... 41
5.2 Jira ...42
5.3 Návrhy na další možná vylepšení ...43
5.3.1 Analýza produktového oddělení ... 43
5.3.2 Analýza oddělení vývoje ... 45
5.3.3 Analýza oddělení Podpora ... 47
5.4 Shrnutí ... 48 Závěr ... 49 Seznam použité literatury ... 50
Seznam zkratek
ITIL Information Technology Infrastructure Library FAQ Často kladené dotazy (Frequently Asked Questions) ASAP Co nejdříve, jak je to jen možné (As soon as possible)
Seznam obrázků
Obrázek 1 Příklad užitého workflow v aplikaci ... 38 Obrázek 2 Centrum informací ... 42
Úvod
Zákaznická podpora je služba poskytovaná zákazníkům daného podniku. Pro podnik s velkým množstvím zákazníků je v současné době zákaznická podpora velice důležitá, neboť ne každý zákazník má dobré technické znalosti. Účelem zákaznické podpory je tedy poskytovat poradenství technické či poradenství odborné ke specifické problematice, kterou se podnik zabývá. Zákazník, který zadává požadavek, se prostřednictvím Helpdesku spojí s týmem specialistů, kteří mají schopnosti a znalosti potřebné k vyřešení problému.
Cílem této bakalářské práce je popsání procesu vlastní implementace Helpdesku a jiných interních systémů, které se zákaznické podpory nebo komunikace se zákazníkem týkají.
1. Jak efektivně komunikovat se zákazníkem
Jelikož jsem byl členem oddělení Podpory, kromě znalostí byla naší nejsilnější zbraní schopnost efektivní komunikace. Proto bych zpočátku chtěl zmínit několik bodů, jak efektivně komunikovat.
1.1 Aktivní poslech
Každý se již určitě setkal s pocitem, že při rozhovoru s nějakou osobou mluví spíše se zdí než s lidskou bytostí, která by skutečně naslouchala. Je to nepříjemné nejen na schůzce, ale i při telefonování. Při komunikaci se zákazníky je stejně důležité to, aby si uvědomovali, že operátor poslouchá jako to, že je doopravdy poslouchá. Právě proto je z operátorovy strany vyžadováno, aby se zapojil do rozhovoru a reagoval na to, co říká druhá osoba. Může se jednat o slova, jako je „ano“ nebo různá citoslovce, která vyjadřují přitakávání. Zákazník má pak dojem, že ho opravdu operátor poslouchá a navíc se sám přinutí k větší soustředěnosti.
1.2 Vyhnutí se negativním otázkám
Tento bod je nejlepší ukázat rovnou na příkladu. Řekněme, že se operátor zeptá zákazníka:
„Nemáte nainstalovaný program TeamViewer?“ a zákazník odpoví: „Ano“. Co tím myslí?
Ano, má operátor pravdu a TeamViewer nainstalovaný nemá? Nebo ano znamená, že program TeamViewer nainstalovaný má?
Negativní otázky způsobují pouze zmatek. Pro jasnější odpověď je mnohem lepší se ptát pozitivně (např. „Máte nainstalovaný program TeamViewer?“), nebo se zeptat otázkou otevřenou („Jaké programy pro vzdálený přístup máte nainstalované?“). V případě nutnosti negativní otázky by měl operátor přidat dodatek, který specifikuje případnou odpověď (např.
„Program TeamViewer nainstalovaný nemáte, je to tak?“).
1.3 Citlivost na rozdíly v technických znalostech
V mnoha případech má operátor v daném oboru mnohem lepší znalosti než zákazník. Je velice důležité umět zhodnotit zákazníkovy znalosti již v průběhu popisování problému.
V případě, že operátor používá nějaké zkratky či odborné výrazy, měl by se ujistit, že jim zákazník rozumí.
1.3.1 Využívání analogie pro vysvětlení technických konceptů
Nejlepším způsobem jak vysvětlit technickou problematiku zákazníkům je právě využití analogie neboli připodobnění neznámé myšlenky k něčemu známému. Jedním z nejlepších analogů je přirovnání firewallu k bankovnímu úředníku. Když jde zákazník do banky, nevstoupí rovnou do trezoru a nevezme si svoje peníze. Místo toho jde k přepážce, kde úředník ověří jeho identitu a zjistí, jestli má dost peněz. Následně jde úředník do trezoru a přinese zákazníkovi jeho peníze.
1.4 Pozitivní přístup
Pro zákazníky je lepší slyšet operátorovy schopnosti než jeho limity. Jinými slovy mají zájem spíše o to, co může operátor udělat, než o to, co nemůže udělat. I v případě nutnosti negativní odpovědi je dobré, aby operátor poskytl aspoň částečně pozitivní odpověď, jako jsou: „Tento problém bohužel nejsme schopni v IT oddělení vyřešit, ale mohu Vás přepojit na kolegyni z obchodního oddělení.“ nebo „Toto bohužel náš program v tuto chvíli neumožňuje, ale mohu to navrhnout jako možné vylepšení programu, aby byl Váš požadavek zapracován.“
1.5 Předvídání námitek a dotazů zákazníků
V knize Umění války řekl starý čínský autor a stratég Sun Tzu: „Pokud znáte nepřítele a znáte sebe, nemusíte se bát výsledku stovek bitev.“ Zanalyzování možných námitek a dotazů a jejich následné zpracování do FAQ nebo jiných informačních prostředků může ušetřit mnoho času jak zákazníkům, tak i operátorům.
2. Aktuální stav v oblasti zákaznické podpory
V druhém bodu své teoretické části bych se chtěl zaměřit na popsání aktuálního stavu v oblasti zákaznické podpory.
2.1 Komunikační kanály
Komunikačních kanálů, které může podnik použít pro zákaznickou podporu, je hned několik. Je důležité umět zanalyzovat a zhodnotit, z jaké sféry obyvatelstva zákazníci jsou.
Jedním z největších ukazatelů v dnešní době je věk. Starší lidé se drží spíše telefonické podpory a bojí se sami udělat něco, s čím se ještě nesetkali. Naopak mladí lidé se drží spíše sociálních sítí, jsou stydlivější, co se telefonátů týče a vědí o možnostech internetu.
2.1.1 Tištěné brožury a návody
Jedním z prvních komunikačních kanálů pro pomoc s řešením problémů byly právě tištěné brožury a návody, kde jsou popsány nejčastější problémy a jejich řešení. Nejčastěji byly přikládány rovnou k produktům. Výhodou byla trvanlivost. Zákazník mohl návod schovat a v případě problémů se do něj podívat, řešení měl tedy fyzicky v ruce. Nevýhodou však byla neaktuálnost a možná nepřesnost. Tyto návody jsou často tvořeny podniky ještě před vydáním produktu na trh. Proto je zde možné pochybení či opomenutí některých problémů.
Další nevýhodou je nemožnost zahrnout všechny možné dotazy. Přestože se mnoho problémů může opakovat, vždy se najdou specifičtější problémy, které v návodu zahrnuty být nemohou.
2.1.2 Telefonická podpora
Pravděpodobně nejvyužívanější a nejrozšířenější komunikační kanál pro zákaznickou
jedná a že se mu v té chvíli někdo věnuje a snaží se mu s jeho problémem pomoci.
Nevýhodou však je, že při častých dotazech musí operátor stále dokola opakovat stejnou odpověď a to je z podnikového hlediska neefektivní. Dalo by se tedy říci, že telefonická podpora je ideální pro řešení specifických individuálních problémů, ale neefektivní pro řešení častých a opakujících se dotazů.
2.1.3 E-mail a Helpdesk
Tyto dva způsoby také spadají k těm nejrozšířenějším. Jsou si velmi podobné, a přesto je v nich rozdíl. Velice záleží na přístupu podniku k možnosti e-mailové komunikace jako ke komunikačnímu kanálu se zákazníky.
První možností je komunikace daného operátora s definovanou skupinou zákazníků napřímo, kdy se zákazník s problémem obrací přímo na daného operátora. Tento způsob je z hlediska personalistiky dobrý, protože zákazník přímo ví, s kým jedná a často zde může vzniknout důvěryhodný vztah. Nicméně zde chybí zastupitelnost a ve chvíli, kdy operátor onemocní, nebo je na služební cestě, obsloužení zákazníka a vyřešení jeho problému může trvat velmi dlouho.
Druhým způsobem je jeden univerzální e-mail, ke kterému mají přístup všichni zaměstnanci oddělení. Zde je pozitivem zastupitelnost a většinou rychlá odezva. Nevýhodou je však neosobnost a nekontrolovatelnost.
Třetí možností co se týče samotných e-mailů, je zavedení jednoho univerzálního e-mailu, ke kterému má přístup jeden nebo dva zaměstnanci, kteří zhodnocují, čeho se daný e-mail týká, kdo je schopen jej vyřešit a následně jej přepošlou. Tato možnost je pro zákazníka nejvýhodnější. Může mít určitý vztah s operátorem, ale i v případě, že nebude schopný problém řešit, je zde možná zastupitelnost. Nevýhodou však je, že tento princip nelze praktikovat ve velkých podnicích a potřeba jednoho či více zaměstnanců, kteří nebudou moct dělat cokoliv jiného.
Proto se ve velkých podnicích v posledních letech zavádí systém zvaný Helpdesk. Jedná se o systém, který může přijímat hned několik způsobů dotazů. Může se jednat o e-maily, formuláře na webových stránkách či dokonce formuláře přímo zabudované v programu.
Tento systém je již přizpůsoben pro řešení velkého množství požadavků. Nabízí přehledné rozhraní a velkou možnost kastomizace (customizace). Lze zde navolit práva pro jednotlivé uživatele či přímé přiřazování jednotlivým pracovníkům či skupinám pracovníků na základě zadavatele či typu požadavku. Jeho jedinými nevýhodami je cena. U helpdeskové aplikace se většinou jedná o out-sourcing.
2.1.4 Sociální sítě
Poslední dobou se stává trendem, a to zejména u společností, které se zaměřují na mladé zákazníky, zakládání svých stránek na sociálních sítích, jako je facebook, nejen za účelem reklamy, ale také kvůli poskytování zákaznické podpory. Průzkumy ukazují, že průměrný uživatel internetu stráví na sociálních sítích denně dvě a půl hodiny. Proto jim společnosti vycházejí vstříc a vstupují na půdu, kde jejich zákazníci tráví tolik času. Je to velmi dobrý prostředek pro komunikaci s mladou generací, nicméně horší cesta pro komunikaci s generací starší.
2.1.5 Zabudovaný chat na webových stránkách
Poslední dobou se čím dál více rozmáhá zabudovaný chat přímo na webových stránkách podniku, kdy zákazník může přímo komunikovat s operátorem prostřednictvím chatu.
Velkou výhodou je osobní přístup, kdy se operátor mile představí a snaží se pomoct vyřešit zákazníkův požadavek. Mezi mnoho dalších výhod patří dostupnost a rychlost odezvy.
Přesto tento komunikační kanál není využíván tolik jako výše zmíněné. Nevýhodu je nezbytnost dalších několika zaměstnanců, kteří budou vždy schopni odpovědět zákazníkům.
2.1.6 Databáze znalostí
Posledním komunikačním kanálem, který již trochu vybočuje z řady, je databáze znalostí.
Operátor tedy nemusí opětovně vysvětlovat složité řešení pořád dokola, ale může odkázat na již existující článek v databázi znalostí podniku. Jedinou nevýhodou je náročnost naučit své zákazníky vyhledávat právě v této databázi, přičemž mívá největší problém starší generace.
3. Implementace systému Helpdesk a její fáze
Helpdesk může být nakonfigurován tak, aby zachycoval hlášené problémy elektronicky prostřednictvím e-mailu, nebo prostřednictvím speciálních webových formulářů určených pro koncové uživatele, kteří nahlásili incident. Ti budou následně informováni o řešení nahlášeného problému. Incident může být upřednostňován a směrován lidem, kteří mohou tento problém nejlépe vyřešit a informovat zadávajícího uživatele.
Helpdesk má mnoho automatizovaných možností, které mohou zjednodušit nápravu problémů. V ostatních případech kdy je třeba do procesu zapojit více lidí, jako je nákup, instalace a poskytování nových serverů, může Helpdesk poskytnout koordinaci mezi všemi stranami, eliminovat zpoždění a zlepšit úroveň služeb. Helpdesk se poté může stát ústředním centrem komunikace v IT oddělení a v mnoha případech se může rozšířit i nad rámec IT tak, aby poskytoval služby i pro ostatní oddělení.
Proces implementace Helpdesku se rozděluje do tří fází. Po dokončení fází implementace přichází na řadu jeho přizpůsobení.
3.1 Plánování workflow a procesů
V této počáteční fázi je zapotřebí zvážit procesy, které chce podnik sledovat pomocí Helpdesku, a následně vytvořit příslušné pracovní postupy neboli workflow1 pro řízení a automatizaci těchto procesů.
Proces IT je předdefinovaná sada kroků, která je opakovaně prováděna tak, aby bylo dosaženo stejného výsledku při každém spuštění procesu. Ve chvíli kdy podnik provede tuto sadu kroků při řešení problémů mimo společnost, kde se každý problém řeší efektivně a opakovaně, náklady klesají a spokojenost koncových uživatelů stoupá.
Workflow je implementace IT procesu v Helpdesku pomocí jeho funkcí a možností. Pro implementaci Helpdesku je nejprve nutné zjistit, které procesy chce v systému sledovat.
Následně se může určit, jaké funkce Helpdesku by měly být použity ke správě různých kroků procesů a jak je dát dohromady, aby vytvořily workflow.
3.1.1 Určení procesů
Podnik by se měl zamyslet nad organizací řešení ticketů, například kdo se o nich dozví první nebo co se děje dále. Následně by měl zvážit, zdali bude proces jiný v případě, že jedná o problém s hardwarem či softwarem anebo o službu či produkt.
3.1.2 Vytvoření workflow pro řízení procesů
Jakmile podnik definuje procesy, měl by být připraven převést tyto procesy do workflow.
3.2 Instalace a základní konfigurace
V této fázi podnik dokončí proces instalace systému Helpdesk a nakonfiguruje prvky, které musí mít k dispozici alespoň pro funkční implementaci.
3.2.1 Instalace Helpdesku
Nyní je zapotřebí nainstalovat Helpdesk a všechny nezbytné komponenty, které bývají obsaženy v instalačním balíčku.
Konfigurace databáze
Do helpdeskové databáze se ukládají tickety a jejich řešení. Databáze bývá vytvořena při instalaci celého systému Helpdesk.
Vytvoření administrátora Helpdesku
Pro správné fungování je zapotřebí založit uživatele administrátor, který má plná práva k provádění všech úloh nabízených systémem Helpdesk.
3.2.2 Import kontaktů
Pokud se jedná o již fungující podnik, bývá pro něj podmínkou možnost naimportovat svou databázi kontaktů. Toto nabízí většina poskytovatelů, často se však liší v typu databáze.
3.2.3 Přidání pracovníků
Pracovníci jsou zaměstnanci, kteří jsou odpovědní za řízení a řešení incidentů. Když je Helpdesk v provozu, incidenty mohou být přiděleny přímo pracovníkovi, nebo mohou být přiděleny do fronty, ze které pracovník může převzít ticket a následně na něm začít pracovat.
Vice v kapitole o definování fronty.
Každý takový pracovník by měl mít své vlastní přihlašovací údaje a možnost si je sám změnit.
Licence
Pro podniky často bývá jednou z největších otázek počet licencí, které potřebuje a problémy s nimi spojené. Podnik implementující systém Helpdesk by měl znát smluvní podmínky a vědět, jací uživatelé musí být licencováni. Nejčastěji je zapotřebí licence pro každého
3.2.4 Nastavení politik
Jakmile jsou pracovníci do databáze přidáni, je zde možnost nastavit jim také jejich práva a omezení. Podnik samozřejmě nechce, aby právě přijatý zaměstnanec viděl údaje, které by neměl.
3.2.5 Definice kategorií
Systém dobrých kategorií je klíčem k vybudování hladce fungujícího helpdeskového systému. Kategorie přidělená incidentu zpravidla spouští workflow nastavením, jak může být ticket upřednostňován, do jaké fronty nebo ke kterému pracovníkovi je poslán, popřípadě zda je situace dostatečně závažná, aby vyžadovala automatické zaslání e-mailu vedoucím oddělení. Některé užitečné přehledy jsou také řazeny podle kategorií, které podniku pomohou zjistit, jaké typy problémů jsou nejběžnější a jaké trendy se vyskytují v jejich prostředí.
Helpdesk bývá nejčastěji dodáván se seznamem doporučených kategorií. Seznam však samozřejmě může podnik změnit. Je také možné použít vnořené kategorie až do hloubky několika úrovní. Podnik by však měl mít na paměti, že čím složitější systém kategorií je, tím těžší pro pracovníky bývá tickety správně kategorizovat. Pokud pracovníci nekategorizují tickety správně, může být v procesu mnoho dalších kroků přeskočeno nebo se provedou špatné kroky, což způsobí, že přehledy budou nesprávné. Je tedy jen na podniku, aby našel tu tenkou hranici mezi užitečnými kategoriemi a zbytečnou nepřehledností.
3.2.6 Definice priority, naléhavosti a důsledku
Možnosti nastavení priorit, naléhavosti či důsledku může podniku pomoci dodržovat koncepce správy služeb podle ITIL2.
2 Information Technology Infrastructure Library je souhrn osvědčených praktik v oblasti řizení služeb.
Poskytuje rámec pro zvládnutí IT v organizaci, pojednává komplexně o službách a zaměřuje se na neustálé měření a zlepšování kvality dodávaných služeb IT. (itSMF Ltd, 2007)
Políčka Priority a Naléhavosti označují, jak rychle by měla být záležitost vyřešena. Pole Důsledek označuje, jak je problém velký. Dopad může být nízký, pokud je postižena pouze jedna osoba, nebo naopak může být vysoký, pokud by byla ovlivněna celá organizace.
Poskytovatelé systémů Helpdesk často dodávají produkt s již navrženými hodnotami pro tato pole. Hodnoty může podnik samozřejmě měnit. Většina podniku implementující Helpdesk provádí pouze drobné změny, nicméně tytomožnosti lze pozměnit nebo je použít k spuštění dalších procesů. Podnik může například definovat pravidla workflow, která se zabývají možnostmi Naléhavost a Dopad ticketů, a poté automaticky nastavit hodnotu pro Prioritu. Proces pracovního postupu by pak mohl dělat některé speciální procesy s prioritou automaticky nastavenou na ASAP, například poslat pracovníkovi a jeho kolegům e-mail nebo přímo i stránku, aby hned věděli, že se děje něco vážného.
3.2.7 Defininování typů ticketů
Typy ticketů přiřazují incidenty podle příslušných oblastí. Typy ticketů lze použít společně s kategoriemi pro řízení workflow a organizování podobných incidentů či pro účely hlášení a přiřazení. Typ ticketu hraje při implementaci procesů ITIL v Helpdesku pomocnou úlohu, protože umožňuje správci definovat organizaci na vysoké úrovni pro incidenty, problémy a změny. Většina poskytovatelů systémů Helpdesk poskytuje předdefinované typy ticketů.
Mezi nejčastěji využívané typy ticketů patří incident, problém, změna nebo vydání. Méně časté jsou chyba, školení, odeslání a příjem.
3.2.8 Defininování stavů
Stav lze považovat za podmnožinu typu ticketu. Stav udává, kde je incident ve vztahu k celému pracovnímu postupu založenému na typu ticketu.
Zde jsou předdefinované hodnoty stavu a to, co naznačují:
Plánováno: Označuje stav pro incidenty, které vyžadují již naplánovanou práci na konkrétní termín.
Vyřešeno: Tento stav označuje, že daný pracovník považuje ticket za vyřešený pomocí opravy problémů či nápravných kroků.
Uzavřeno: Po potvrzení vyřešených událostí daným zaměstnancem je stav nastaven na Uzavřeno. V některých organizacích se incident neuzavře až do potvrzení a v dalších případech se automaticky zavede období 24-72 hodin. Pokud zákazník, který nahlásil daný problém, na e-mail neodpoví v uvedeném časovém období, předpokládá se, že problém byl opraven a stav ticketu se změní z Vyřešeno na Uzavřeno.
Podrženo: Práce na incidentu se na určitou dobu zastavila. Operátoři mohou například podržet požadavek, dokud nedostanou nové potřebné vybavení, zatímco žádost projde schvalovacím procesem.
Podnik může samozřejmě vytvořit další stavy, jako jsou například schválené, odmítnuté, přenesené a přijaté.
Tyto stavy mohou vyžadovat kroky workflow, které potřebují souhlas správce.
3.2.9 Definice fronty
Fronty jsou alternativním způsobem přiřazování událostí. Namísto přiřazování ticketů přímo pracovníkům můžou být tickety zařazeny do fronty. Pracovníci jsou přiděleni do fronty nebo front a přijímají další incidenty v pořadí. Fronty mohou třídit a upřednostňovat tickety jakýmkoli způsobem vhodným pro danou organizaci. To znamená, že po vyřešení ticketu mu bude automaticky přidělen momentálně nejdůležitější ticket, který se v jeho frontě nachází.
Pro nové podniky je lepší začít s jen pár frontami, než jich nastavit příliš mnoho. Mít příliš mnoho front často vede k chybám při přiřazování a může vést až ke "ztraceným" ticketům, což zpomaluje celý proces workflow a vytváří nespokojenost u koncových uživatelů.
3.2.10 Definice obchodních pravidel pro automatizaci pracovních postupů
Pro každý workflow je třeba definovat obchodní pravidla pro přesun incidentů skrze workflow. Obchodní pravidla vyhodnocují údaje obsažené v ticketu a testují je na určité podmínky. Pokud existují podmínky, provede se akce uvedená v pravidle. Pokud podmínky neexistují, žádné akce neproběhnou.
5 typů obchodních pravidel:
Ověřovací pravidlo: Zajišťuje platnost dat zadaných do incidentu. Pokud data nejsou platná, je uživatel požádán o opravu dat předtím, než může být událost uložena v databázi ticketů.
Pravidlo o incidentech: Zajišťuje správnost vztahů mezi datovými políčky. Pokud je například zadán nový incident, stav by neměl být obvykle Schváleno, ale spíše by měl být Otevřeno, nebo Podrženo.
Pravidlo směrování: Odesílá ticket správné osobě nebo zařazuje do fronty pro další zpracování.
Pravidlo oznámení: Generuje automatický e-mail nebo stránku. Například když je událost uzavřena, osoba, která ohlásila incident, je automaticky upozorněna, že ticket byl uzavřen.
Pravidlo automatizace: Má mocnou schopnost automatizovat akce a odstranit potřebu lidské interakce k vyřešení kroku. Podnik může například definovat pravidlo automatizace, které spouští automatickou aktualizaci softwarových záplat v klientských počítačích nebo automatické zálohování počítače, který vykazuje známky nevyřešené chyby.
Obchodní pravidla se provádějí, když je ticket uložen do databáze, v pořadí, ve kterém jsou uvedeny výše. Když pracovník systému Helpdesk klikne na tlačítko Uložit, všechna pravidla se vyhodnotí proti aktuálním hodnotám incidentu a pokud pravidlo nalezne kritéria v
3.2.11 Definujte zásady oznámení na serveru oznámení
Administrátoři často zjistí, že potřebují automatické upozornění správce, když incident nebo workflow zaostávají za plánem. Podnik tedy může definovat oznamovací politiku na serveru, který může identifikovat opožděné tickety a automaticky provádět výstrahu způsobem, který podnik určí. Zásady upozornění mohou změnit stav ticketu na vyšší úroveň a mohou odeslat e-maily před plánovaným datem nebo mohou znovu přiřadit incident jinému pracovníkovi.
Oznamovací zásady jsou flexibilní, snadno definovatelné a mohou vyhodnocovat informace o událostech jako hodnotící kritéria, aby zjistily, zda je potřeba poslat oznámení, nebo automaticky podnikly kroky ve workflow.
Politika oznámení může provádět několik typů automatizovaných akcí:
Automatizovaná akce elektronické pošty. Odesílá e-mail.
Nový automatizovaný ticket. Vytvoří nový ticket.
Nahlášení automatizované akce. Odesílá zprávu.
3.2.12 Definice šablony e-mailů
E-mail je skvělý způsob, jak koncové uživatele informovat o změnách a stavu ticketů.
Pravidla oznámení umožňují širokou kontrolu nad frekvencí a typy situací, které mohou odeslat e-maily. Vzhledem k tomu, že si podnik nastavuje pravidla oznámení, měl by vytvořit různé typy e-mailů tak, aby vždy vystihovaly správnou situaci. Systém většinou umožňuje neomezený počet šablon e-mailů, které lze vytvořit a formátovat pro konkrétní účely.
3.2.13 Definice schránky elektronické pošty a filtrů doručené pošty
Helpdesk může přijímat nové incidenty nebo aktualizovat aktuální události prostřednictvím příchozího e-mailu. Tato metoda umožňuje komukoli odeslat ticket pomocí standardního e-mailu. Systém identifikuje uživatele. Pokud uživatel není uveden jako kontakt, může být automaticky přidán a ticket je vytvořen na základě informací obsažených v e-mailu. Předmět e-mailu se stane názvem ticketu a jsou přiřazeny výchozí hodnoty, například fronta, stav,
naléhavost a podobně. Pravidlo o ticketu je možné použít k analýze textu zprávy, která vyhledává konkrétní slova nebo fráze, například "Windows", "Word", "Excel" nebo
"Tiskárna". Pokud jsou určena konkrétní slova nebo fráze, lze v rámci incidentu nastavit konkrétní typy vstupních ticketů nebo hodnoty polí.
Pravidlo oznamování můžet být použito také k automatickému vytvoření e-mailu, pokud jsou potřeba další informace od správce nebo koncového uživatele. Po přijetí a otevření e-mailu může příjemce odpovědět s požadovanými informacemi. E-mailová schránka Helpdesku detekuje odpověď a zkopíruje ji do původního ticketu. Stav, přidělené fronty a další parametry lze upravit tak, aby nové informace byly směrovány správnému pracovníkovi pro rychlé rozlišení.
3.3 Pokročilá konfigurace
Možnosti konfigurace v této fázi jsou rozhodující pro dosažení efektivnosti implementace řešení Helpdesk.
3.3.1 Definice inteligentních úkolů
Inteligentní úkoly neboli Smart Task jsou procesy, funkce nebo programy třetích stran, které pracovníci mohou používat pro diagnostiku nebo odstranění problémů. Když pracovník zvolí některou z inteligentních úloh, spustí se Smart Task a provede jeden nebo více automatizovaných procesů.
Zde jsou některé příklady způsobů použití Smart Task:
Přiřadit ticket k danému pracovníkovi.
Rychle uzavřít ticket.
Zobrazit parametry počítače.
3.3.2 Definice rychlých ticketů
Další chytrou funkcí Helpdesku jsou takzvané Quick Incidents, neboli rychlé tickety, které urychlují zpracování ticketů. Rychlé tickety mají předem definované standardní hodnoty pro běžné problémy. Například reset hesel se často požaduje ve většině organizacích a v těchto událostech existuje mnoho hodnot, které jsou pokaždé nastaveny stejným způsobem. Místo toho, aby pracovník nastavil všechny tyto hodnoty ručně při každém obnovení hesla, může vybrat možnost Rychlé tickety pro obnovení hesla a všechna pole ticketu budou nastavena na správné hodnoty.
3.3.3 Definice běžných dotazů
Systém Helpdesk je navržen tak, aby mohl být použit v reálném čase, takže všechny informace uložené v databázi jsou nejaktuálnější a nejpřesnější dostupná data. Pracovníci často potřebují přístup k nejrůznějším informacím, od zkoumání konkrétních otázek se zařízením k prozkoumání obecných trendů pro konkrétní službu nebo skupinu uživatelů.
Vzhledem k rozmanitým informačním potřebám systém pracovníkům umožňuje nalézt případy založené na širokém spektru kritérií. Můžou být definovány běžné dotazy tak, aby pracovník potřeboval pouze vybrat dotaz a spustit jej. Pracovníci samozřejmě mohou pomocí SQL vytvářet své vlastní dotazy a popřípadě je uložit na pozdější opětovné použití.
Zde je několik příkladů běžných dotazů, které bývají nejčastěji vytvořené:
Zobrazit všechny moje přiřazené tickety
Zobrazit všechny moje tickety s vysokou prioritou
Zobrazit všechny tickety s vysokou prioritou, které jsou stále otevřené
Zobrazit všechny tickety spojené s konkrétním majetkem
Zobrazit všechny tickety, které otevřel konkrétní kontakt
3.3.4 Integrace řešení Helpdesku s jinými systémy pomocí webových služeb
Existuje mnoho návrhových výhod, které mohou být využívány na základě 100% webového charakteru architektury produktu. Hlavní výhodou je, že všechna data jsou na serveru
uložena velmi bezpečným způsobem. Kromě toho je přístup na server prostřednictvím webového prohlížeče, což znamená, že k němu může mít přístup okamžitě každý, kdo má příslušné oprávnění. To také znamená, že pokud administrátor změní některou z konfiguračních nebo přizpůsobovacích informací, nové funkce budou okamžitě dostupné všem uživatelům, protože změny nemusí být nainstalovány v každém klientském počítači.
3.3.5 Import dokumentace do databáze znalostí Helpdesk
Znalostní databáze Helpdesku je mocný nástroj pro vytváření a vyhledávání řešení problémů, které se v minulosti vyskytly. Tento nástroj umožňuje pracovníkům a koncovým uživatelům vyhledávat ve znalostní databázi Helpdesku a najít publikované články o příznacích, stejně jako osvědčené postupy pro opravu jakéhokoli známého problému.
Databáze znalostí lze naplnit řešeními, které jste již byly vytvořeny pomocí jiných nástrojů.
Databáze znalostí také často obsahuje proces workflow, který lze použít k návrhu, přezkoumání a schválení článků předtím, než budou zpřístupněny všem koncovým uživatelům.
3.3.6 Definice nových přehledů
Správce Helpdesku má přístup k více než 60 předem definovaným přehledům, které obsahují užitečné informace. Správce však může tyto přehledy upravit nebo vytvořit zcela nové sestavy pomocí vestavěného průvodce sestavami nebo úpravou či vyvíjením vlastních příkazů SQL pro generování informací. Většina podniků začíná se základními přehledy, do kterých zabudují své vlastní konkrétní náměty.
3.4 Popis zákaznické podpory u jiných podniků
Pro následné popsání aktuálního stavu v oboru podpory zákazníků jsem se rozhodl vybrat
3.4.1 Podnik 1
Podnik 1 jsem vybral z důvodu stejného postavení na trhu, jako je právě náš podnik. Jedná se o největšího poskytovatele SW pro určitou skupinu podniků či oddělení velkých podniků.
Využívá dva typy komunikačních kanálů se zákazníkem. Prvním, podnikem preferovaným, je telefonická podpora, která poskytuje pomoc na bezplatné zákaznické lince každý pracovní den od 8:00 do 17:00. Před začátkem hovoru stroj vyžaduje zadání identifikačního čísla zákazníka a má stanovený limit hovoru na 10 minut.
V případě, že se zákazník nedovolá, nabízí podnik alternativní internetovou zákaznickou podporu fungující na principu Helpdesku, díky které se zákazník pomocí svého identifikačního čísla přihlásí přímo na webových stránkách a do formuláře může vyplnit svůj dotaz.
3.4.2 Podnik 2
Podnik 2 jsem vybral z důvodu stejné velikosti podniku a podobného postavení na trhu.
Jelikož vyrábí výrobky na zakázku, většina jejich komunikace se zákazníky byla telefonická s otázkami na stav objednávky. Proto se tato společnost rozhodla komunikaci se zákazníky změnit. Telefonní hot linka byla zrušena a nahrazena FAQ a kontaktním formulářem, který směřuje do Helpdesku, kde je vyhrazený čas na odpovědi od pondělí do pátku od 8:00 do 18:00. Další možné dotazy se snaží předejít formou videonávodů.
3.5 Současný stav zákaznické podpory v podniku
V posledním bodě teoretické části se pokusím zaměřit na popsání stavu zákaznické podpory přímo v podniku INISOFT s. r. o., kde jsem vykonával svou roční praxi.
Ve společnosti je oddělení Podpora, jejíž hlavní náplní je zákaznická podpora a dále testování SW. V současné době podnik využívá dva komunikační kanály.
3.5.1 Telefonická komunikace
Z počátku byla asi nejvyužívanější komunikační kanál. Již při zavádění byla interně namluvena hlasová samoobsluha. Tím se docílilo toho, že pokud se zákazník „prokliká“
správně, mluví přímo s odborníkem na svůj problém nebo požadavek.
3.5.2 E-mailová komunikace
Při mém nástupu bylo e-mailové fungování podniku následující. Každý zaměstnanec měl svůj vlastní firemní e-mail. Mimo to byly i centralizované e-maily, zejména pro oddělení obchodu a podpory. Tento centralizovaný e-mail spravoval zpravidla vedoucí oddělení. Ten je následně zpracovával či předával svým podřízeným, kteří následně odpovídali ze svého vlastního firemního e-mailu.
Z mého pohledu měl tento systém více nevýhod než výhod. První nevýhodou je nezastupitelnost. V případě, že vedoucí pracovník náhle onemocněl, nebyl nikdo, kdo by jej na daném e-mailu zastoupil. Jedinou možností bylo zpřístupnění centralizovaného e-mailu dalšímu pracovníku, či dočasně nastavit přeposílání veškerých e-mailů jinému zaměstnanci, který přijaté e-maily od zákazníků přeposílal dále či na ně sám odpovídal. Další nevýhodou je, že dané požadavky jsou přeposílány pouze jednomu zaměstnanci, který při větší vytíženosti nemusí mít na odpovídání zákazníkům čas. Často se tedy komunikace velice natahovala a mohla se protáhnout až na několik dní. Neposlední nevýhodou je, že zákazníci postupem času začali přímo psát danému pracovníkovi, který jim minule odpověděl namísto požadavku na centralizovaný e-mail. To mělo opět za následek zpomalení komunikace a v případě dovolené či služebních cest v období sezóny prodloužení doby odpovědi až na týden či více. Posední důvod, proč je tento způsob hoden mé kritiky, je velké zaneprázdnění vedoucího pracovníka, obzvlášť při větším počtu e-mailů. Nelze však opomenout na výhody, jako je jednoduchost systému, kdy není potřeba out-sourcing nebo to, že požadavky lze směřovat přímo na zaměstnance, kteří se na danou problematiku specializují.
4. Implementace nového prostředí
Po již dlouhém zvažování bylo ve firmě rozhodnuto zavedení systému Helpdesk. Proto bylo také na mně porovnání a následné zanalyzování systémů od různých společností.
4.1 Výběr systému
Po další analýze byl vybrán systém od společnosti Requestor hned z několika důvodů.
Prvním z nich je licencování. Pro práci s Helpdeskem od společnosti Requestor je zapotřebí mít licencované pouze vedoucí pracovníky a zástupce vedoucího. Super operátoři a operátoři tedy nejsou omezení. To je velká výhoda, neboť licenci potřebuje pouze vedoucí oddělení Podpora a správce celého Helpdesku.
Dalším důvodem pro vybrání platformy od společnosti Requestor bylo rozdělování katalogu produktu či služeb. Zákazník může již při zadávání ticketu (požadavku) zvolit, jakého produktu či služby se to týká a zdali se jedná o chybu, návrh na vylepšení a podobně.
Jelikož si společnost Inisoft ráda sama spravuje své vlastní servery, byl další výhodou přístup. Celá platforma tedy běží na serverech společnosti Inisoft, nikoli na serverech poskytovatele.
V neposlední řadě je výhodou možnost konfigurace zadávacího formuláře, tento formulář lze tedy zapracovat například do programu či na webové stránky. Dále je možné nakonfigurovat odeslání informací o počítači, jako je například typ a verze operačního sytému, verze programu, všechny zakoupené moduly programu, přihlášený uživatel, licenční číslo či umístění hlavní databáze. Kvůli ochraně osobních údajů má však zákazník možnost tyto informace neposkytnout.
4.2 Úvodní nastavení
V úvodním nastavení aplikace Requestor musíme nejprve zadat a nastavit parametry poskytovaných služeb a založit uživatelské účty.
1. Základní nastavení
Nejprve definujeme časové pásmo a výchozí jazyk.
2. Vytvoření katalogu služeb
Katalog služeb definuje jednotlivé poskytované služby, upřesňuje zákazníky, kterým jsou služby dostupné, a přiřazuje operátory jednotlivým službám. Pro každou službu může být definován vlastní okruh zadavatelů a zákazníků i okruhy řešitelů jednotlivých typů požadavku.
3. Vytvoření skupin operátorů
Skupiny operátorů mohou být vytvořeny pro usnadnění přidělování jednotlivých služeb či požadavků příslušným operátorům, požadavek je tedy přesměrován všem členům skupiny, nikoli jedinci.
4. Vytvoření interních skupin
Interní skupiny tvoří zadavatelé požadavků, například zaměstnanci uvnitř organizace.
Skupiny lze jednoduše přiřazovat ke službám.
5. Vložení zákazníků
Vložením zákazníků dalším způsobem rozlišujeme zpracování požadavků a rozdělení účtů koncových uživatelů. Například SLA (Service Level Agreement – dohody o úrovni služeb) lze pro jednotlivé zákazníky definovat rozdílně.
6. Vytvoření uživatelských účtů
Dále musíme vytvořit účty pro všechny uživatele aplikace Requestor. V uživatelských účtech můžeme vytvořit všechny typy přístupů – administrátor, operátor i koncový uživatel.
7. Definování SLA
Díky definování parametrů dohody či více dohod o úrovni poskytovaných služeb lze jednotlivým službám a zákazníkům přiřadit prioritu zpracování a zadat další podrobnosti o úrovni poskytovaných služeb.
8. Přizpůsobení formulářů
V aplikaci Requestor lze rozšířit výchozí formulář pro zadávání požadavků o vlastní pole pro zadání dodatečných informací.
9. Další nastavení
Posledním krokem je další nastavení aplikace, ve kterém lze například přizpůsobit e-mailové notifikace, definovat pracovní dobu v závislosti na dni v týdnu či aktivovat a upravit vzhled uživatelského portálu.
4.3 Uživatelské účty
Aplikace Requestor poskytuje pět typů uživatelských účtů. Jednotlivé typy se od sebe liší přiděleným oprávněním a použitím.
Jedná se o tyto typy:
Administrátor: Hlavní správce aplikace, který může měnit veškerá nastavení v administrační části aplikace.
Operátor: Uživatel, který řeší požadavky v rámci přidělených skupin a zákazníků, spravuje (například přiřazuje, mění, potvrzuje) požadavky zákazníků, skupin či operátorů.
Super operátor: Od operátora se liší tím, že může vyřizovat všechny požadavky.
Koncový uživatel: Zadavatel požadavku, který má možnost sledovat průběh zpracování svého požadavku.
Pokročilý uživatel: Rozšiřuje roli koncového uživatele, může volit službu pro vložení požadavku.
Operátor, Pokročilý uživatel a Koncový uživatel mohou pouze upravovat svůj uživatelský profil a měnit jazykové nastavení, nikoli měnit nastavení aplikace.
Operátorské účty lze v rámci aplikace shromažďovat do skupiny operátorů pro snazší přiřazování ke službám. Účty koncových uživatelů lze shromažďovat v rámci definovaných zákazníků a interních skupin.
Prakticky se jednalo o to, že byl vytvořen administrátorský účet, který je spravován vedoucím oddělení. Ten má tedy neomezené možnosti na správu všech ostatních uživatelských účtů. Dále byli vytvořeni Super operátoři, což jsou zaměstnanci, kteří jsou zástupci vedoucího oddělení, pracují v podniku již delší dobu a mají mnoho zkušeností.
Klasický uživatelský účet Operátor byl založen všem členům oddělení podpory, kteří vyřizují zákaznické tickety. Koncový uživatel je jakýkoli náš zákazník, který má s námi podepsanou servisní smlouvu. Má možnost zadávat tickety, ale nemá přihlašovací údaje, aby se mohl podívat na stav svého požadavku. Poslední typ je Pokročilý uživatel, který byl přidělen speciálním zákazníkům, jako jsou pracovníci Ministerstva životního prostředí. Tito uživatelé mají své vlastní přihlašovací údaje a mohou tedy přímo sledovat stav svého požadavku.
4.4 Skupiny operátorů
Pro hromadné přiřazování operátorů k příslušným službám můžeme vytvořit neomezený počet skupin operátorů, a proto lze následně požadavek přiřadit celé skupině, nikoli pouze jednomu operátorovi. Jeden operátor však může být členem více skupin.
4.5 Zákazníci
Hlavní příčinou pořízení systému Helpdesk jsou zákazníci. Pro podnik je však také důležité, aby měl přehled, který zákazník daný požadavek zadal. Proto lze v aplikaci Requestor vytvořit databáze zákazníků. Jak již bylo zmíněno, v podniku rozlišujeme zákazníky na dva typy – koncový uživatel a pokročilý uživatel. Mezi koncové uživatele jsme zařadili veškeré
pokročilý uživatel, který má přístup do aplikace, vyžaduje přihlašovací údaje. Jak již bylo výše napsáno, pokročilí uživatelé bývají často státní orgány, jako je například Ministerstvo životního prostředí nebo CENIA3. I běžný operátor může vytvořit účty pokročilých uživatelů a následně daným zákazníkům sdělit přihlašovací údaje.
4.6 Katalog služeb
Služby jsou základním prvkem pro rozdělení žádostí koncových uživatelů (zadavatelů) operátorům. Cílem katalogů je centrálně oddělit a nadefinovat služby, které organizace poskytuje (HW/SW Support, User Support Traning a další). Každá služba může mít úplně jiné nastavení, postupy řešení neboli workflow, operátory, koncové uživatele, zákazníky, manažery a tak dále.
Jednotlivé služby lze pro koncové uživatele v zadávání požadavků omezit. Stejně tak můžeme definovat operátory nebo skupiny operátorů, které mají zpracování požadavku (řešení požadavku) v rámci těchto služeb na starost. U všech služeb je v rámci správy ticketů možné navíc definovat dvě úrovně operátorů – standardní operátory a specialisty. Díky tomu je možné obdržené tickety filtrovat a specialisty využívat pouze v náročnějších případech.
4.7 Tvorba workflow
Tvorba workflow je nezbytná část implementace, kdy se pro jednotlivé služby definuje proces řešení. Jelikož má podnik Inisoft zákazníky jak z firemní, tak ze státní sféry, bylo nezbytné ke každé sféře vytvořit jiný workflow. Aplikace Requestor poskytuje vytváření workflow pomocí zaškrtávání polí s jednotlivými kroky, například jestli je před uzavřením ticketu zapotřebí schválení.
3 CENIA je česká informační agentura životního prostředí.
Obrázek 1 Příklad užitého workflow v aplikaci Zdroj: Helpdesk INISOFT (2018)
4.8 Uživatelské formuláře
V další fázi jsme vytvářeli uživatelské formuláře a jejich přiřazení k vybraným službám.
Využili jsme i možnost rozšíření přidáním vlastních polí pro další informace, jako je zákazníkův operační systém, verze programu či zakoupené moduly. Tyto formuláře se následně zobrazí při vkládání ticketu do příslušné služby a poté přímo v detailu ticketu.
4.9 Správa e-mailů
Předposledním krokem implementace bylo nastavení a správa e-mailů, neboť obsahují veškerá nastavení pro přijímání i odesílání zpráv aplikace Reqestor. Tato nastavení mají přímý vliv na zasílání notifikací operátorům i koncovým uživatelům, ale také na příjem e-mailů s požadavky.
V této části jsme tedy nastavovali notifikační zprávy – zákazníkům, že byl jejich požadavek přijat a operátorům, že přišel nový požadavek k řešení. Dále jsme pro jednotlivé operátory nastavili automatické podpisy a nakonfigurovali veškeré e-mailové schránky, které měly přijímat e-maily jako tickety do systému Helpdesk.
4.10 Konečné nastavení
Poslední částí implementace bylo pouze doladění detailů, jako jsou různé přehledy, vzhled aplikace a otestování funkčnosti nastavené aplikace.
5. Další interní systémy
Jako podporu zákazníků nelze vnímat pouze Helpdesk. Jak jsem již uváděl výše, mnohokrát tcelý proces nekončí jen u zodpovězeného dotazu. Velmi často přichází tickety s žádostí o vylepšení, změnu či opravu programu. Bylo tedy potřeba zřídit systém, který by umožňoval lepší komunikaci a spolupráci mezi oddělením Podpory, Vývoje a Produktovým oddělením.
Podnikem však nebylo vyžadováno pouze toto. Vzhledem k rostoucímu počtu zaměstnanců hledal podnik prostor jak pro své zaměstnance, tak i zákazníky. Takto širokou škálu možností nabízel jen poskytovatel ATLASSIAN. Tento podnik nabízí přesně takové systémy, které náš podnik potřeboval. Po delší analýze tedy naše společnost INISOFT s.r.o.
zakoupila dvě aplikace, a to Confluence a Jira.
5.1 Confluence
Confluence je jeden ze základních produktů firmy ATLASSIAN, ona sama tento produkt ve své činnosti používá, stejně jako mnoho dalších podniků v současné době, které pomocí ní tvoří svou databázi znalostí nebo své interní či externí webové stránky. Nejlepší způsob pro dosažení kvalitního informačního systému je jeho užívání tím, kdo jej vyvíjí.
Confluence je nástroj vyvinutý zejména pro týmovou spolupráci. Jedná se o výkonný nástroj, který se užívá při vytváření, publikování, tím pádem i sdílení informací a diskutování o nich v rámci malých či velkých týmů. Confluence spojuje spolupracovníky a týmy s obsahem, který potřebují pro urychlení svojí práce.
5.1.1 Co je vlastně Confluence
Pod pojmem Confluence si lze pro zjednodušení představit webové stránky, které jsou plně WYSIWYG4, a tím je jejich editace velmi intuitivní a nedělá potíže žádnému trochu internetu znalému uživateli.
Při hlubším rozboru však člověk zjistí, že se jedná o mnohem více než webové stránky. Jde totiž o celé prostředí, které umožňuje velmi bohatě a důsledně spravovat oprávnění pro přístup do něj, pro jeho administraci, pro čtení nebo pro zápis v jeho obsahu.
5.1.2 Centrum informací
Centrum informací je znalostní databáze a slouží jako hlavní středisko informací pro zákazníky o našich SW. Obsahuje popis jednotlivých částí, detailní návody, kompletní uživatelskou příručku, seznam změn pro jednotlivé verze programů, znalostní databázi atd.
Obsahuje i odkaz na legislativní informace z oblasti životního prostředí a novinky ze společnosti INISOFT s.r.o.
4 WYSIWYG je zkratka z anglického What you see is what you get – co vidíš, to dostaneš. Jako WYSIWYG se zpravidla označují editory, v nichž uživatel přímo upravuje webovou stránku tak, jak bude vypadat v běžném internetovém prohlížeči.
5.2 Jira
JIRA je interní informační systém propojený se systémem Confluence. Slouží k evidenci a komunikaci požadavků na vývoj SW produktů, tedy požadavků, které podnik doposud vkládal, evidoval a komunikoval prostřednictvím interního programu Info.exe5.
Výhody JIRA jsou zejména v přehlednosti a také v propojení s Confluence a podobném ovládání. Cílem je tedy výrazně zjednodušit tolik potřebnou přehlednost, komunikaci a sdílení v rámci hlavní činnosti naší firmy – tvorbě SW produktů.
V podstatě se jedná o systém, který zpřehledňuje systém zadávání a plnění úkolů. Jakmile jakýkoli z operátorů Helpdesku obdrží ticket se žádostí o změnu, opravu či vylepšení Obrázek 2 Centrum informací
Zdroj: Centrum informací INISOFT (2018).
programu, zadá tento požadavek do aplikace JIRA. Následně se pokračuje dle již sestaveného workflow.
5.3 Návrhy na další možná vylepšení
První návrh na vylepšení je častější aktualizace centra informací. Znalostní databáze není využívána na 100 %, pokud v ní nejsou informace aktuální. Často se tedy stávalo, že problém zasáhl mnoho zákazníků, kteří o něm v centru informací nenašli žádný článek, a proto zvolili telefonickou podporu. Pokud by byl článek v centru informací, operátor by na něj v případě telefonátu mohl jednoduše odkázat.
Druhý návrh na zlepšení je zvýraznění centra informací přímo v programu. Mnoho zákazníků teprve zjišťuje, že centrum informací vůbec existuje. I přesto, že by našli odpověď v centru informací, volají telefonicky, kde je operátor buď odkáže na příslušný článek, nebo řešení zákazníkovi vysvětlí sám.
Mým posledním návrhem na vylepšení jsou univerzální odpovědi Helpdesku. Často se stávalo, že se dotazy v Helpdesku opakovaly. Operátor má v tuto chvíli dvě možnosti, buď zkopírovat předešlé odpovědi, nebo napsat odpověď novou. I přesto, že lze v Helpdesku využít fulltextového vyhledávače, může chvíli trvat, než operátor správnou odpověď najde.
Psaní nové odpovědí je také časově náročnější, proto si myslím, že by bylo vhodné využít možnosti, které Helpdesk nabízí, a to jsou předdefinované odpovědi. Pokud by se návrh ujal a odpovědi byly pravidelně aktualizovány, domnívám se, že by to operátorům mohlo ušetřit mnoho času, který by mohli využít na řešení složitějších incidentů.
5.3.1 Analýza produktového oddělení
Produktové oddělení bylo první oddělení, které s aplikací JIRA začalo pracovat.
Výhody JIRA
Systém je speciálně vyvinutý pro řízení vývoje aplikací, jsou v něm zahrnuty dlouholeté zkušenosti jiných podniků.
Aplikace nabízí přesný popis životního cyklu požadavku na vývoj (úkol, oprava, zlepšení apod.) ticketu, od zadání, analýzy, vývoje, testování až po uzavření.
Velmi snadno se lze v systému orientovat a sledovat ticket. Úkol má stále přiřazený stav a odpovědného řešitele, je tedy možné jednoznačně určit stav řešení.
Informační e-maily o úkolu, který je právě daným operátorem řešen, zadán nebo sledován, jsou velmi přehledné.
Snadné je též řízení sprintů přípravy verzí. Stavy připravované verze (grafy apod.) i stavy jednotlivých úkolů jsou přehledné.
Aplikace nabízí možnost vlastní konfigurace systému, tedy snadné vytvoření vlastních filtrů či nástěnek a umístění údajů, které operátora aktuálně zajímají.
Na projekt nebo připravovanou verzi se lze podívat z mnoha různých pohledů – podle nastavené řídící veličiny v grafu, filtru nebo přehledu (status, řešitel,…).
Do úkolu může zasáhnout několik lidí ve stejnou chvíli, kteří mohou snadně doplnit informace.
Lze využívat „mention“, tzn. správně informovat o potřebě spojené s úkolem, například o doplnění zadání.
Aplikace slouží jako průvodce procesem vývoje.
Přehledy, grafy, filtry a prostředí jsou uživatelsky přívětivé.
Systém je rychlý a stále dostupný.
Nevýhody JIRA
Pokud se nepoužívají nebo nesprávně používají filtry, není jasné, na čem má vývoj pracovat. Pracovník může řešit úkoly z budoucího sprintu, nikoli z aktuálního.
Orientace i zaučení v systému jsou zpočátku složitější.
Je nutné konfigurovat nástěnky a další pohledy, aby byla zajištěna základní přehlednost.
Výchozí přehledy nejsou moc přívětivé.
Nelze upravovat aplikaci zcela na klíč.
Info.exe nenabízí žádné on-line možnosti, jak sledovat stav vývoje připravované verze a nemá žádné použitelné výstupy a přehledy, které by byly okamžitě k dispozici.
Úkoly se mohou v info.exe ztrácet.
Info.exe se naopak jeví jako ideální nástroj na zadávání „neprodukčních“ úkolů, plánování, práci s kalendářem, rezervaci aut apod. Lze ho efektivně využívat k tvorbě vlastních poznámek a plánování času.
Info.exe není dostupné mimo podnik, ale pouze přes VPN, a to velmi pomalu. Není vůbec dostupné přes web či mobil.
Doporučení na využití aplikace JIRA
Produktové oddělení vnímá aplikaci JIRA jako velice efektivní nástroj. Po kratším prvotním zaučení ho lze využívat velice jednoduše a efektivně.
Postupem času, po lepší orientaci v systému, se začínají používat i jeho další funkce, které usnadňují práci. Pro klasické použití však stačí základní sada znalostí a postupů.
Produktové oddělení chce zachovat Info.exe pro nevývojové aktivity, nechat jen obecný úkol, do kterého by se zapisoval čas strávený v JIŘE
Je však potřeba proškolit ostatní pracovníky pro správné používání, tak aby byly řešeny aktuální úkoly.
5.3.2 Analýza oddělení vývoje
Oddělení vývoje je jednou ze tří nezbytných stran pro plně funkční systém JIRA. Proto zde byla provedena analýza a zapsány byly všechny poznatky a poznámky.
Výhody JIRA
Aplikace JIRA je k dispozici kdekoliv, nejen na vnitřní síti.
Vše potřebné je přehledně na jednom místě (dodatečné upřesnění, historie změn či podklady, tzn. obrázky i jiné soubory).
Díky webovému prostředí je zde možnost současného zobrazení více stránek.
Aplikace umožňuje propojení s Confluence (zobrazuje stav úkolu), diskuzi pod úkolem, WYSIWYG editor, jednoduché a přehledné vkládaní a používání příloh, obrázků či odkazů.
Je zde možnost upozornit uživatele na téma, vtáhnout je do diskuze.
Aplikace JIRA nabízí velkou škálu možností přizpůsobení osobního uživatelského rozhraní a různých workflow. Lze snadno dohledat plánování do sprintu či na čem se aktuálně pracuje (v rámci aktuálního sprintu).
Lze se odkazovat odkazem, např. ve Skypu.
Pokud jsou úkoly zadávány správně, lze sledovat, které části aplikace jsou problémové a následně vhodně zareagovat.
Nevýhody JIRA
JIRA však neumožňuje evidování času stráveného na úkolech po daný interval (den, měsíc,…).
Oproti Info.exe se musí vždy vybírat, komu má být úkol přeřazen, neexistuje automatické vyplňování při přechodu mezi stavy. Automatika je zde možná, úkol by se mohl vracet na component lead. Ten by měl mít o své oblasti přehled, předávat úkoly k výrobě/otestování, a zároveň mít dostatečný přehled o tom, co je ve kterém stádiu řešení.
V aplikaci chybí rezervační systém (auta, zasedací místnosti, pomůcky) a kalendář.
Porovnání JIRA a INFO
V tuto chvíli nelze obě aplikace zcela porovnávat, neboť JIRU používáme teprve pár měsíců a Info.exe, které je interně vyvinuté pro naše potřeby, využíváme již několik let.
JIRA řeší konkrétní problém, Info.exe je univerzální.
JIRA je nástroj pro řízení vývoje SW, Info.exe nikoli.
Na rozdíl od Infa.exe lze v JIŘE zakoupit rozšíření.
Pro práci s externistou (např. grafické studio) je Info.exe zcela nevhodné, není možné
Doporučení na využití aplikace JIRA
Vývojové oddělení zhodnocuje aplikaci JIRA jako skvělý systém pro vedení SW projektu.
Úkoly, které přímo nesouvisí s vývojem SW, bude však lepší vést i nadále v Info.exe.
Evidenci odpracovaných hodin bude nejlepší sledovat i nadále v deníku Info.exe.
Návrhujeme udělat webovou aplikaci Mé úkoly, kde každý uživatel uvidí souhrn otevřených úkolů z JIRA a úkolů z Info.exe, setříděno podle data. Proklik na úkol otevře buď JIRA nebo Info.exe na konkrétním úkolu.
Aplikaci JIRA by časem mohlo používat i oddělení Obchod, neboť také pracuje nad nějakým úkolem, který může být i v JIRA pro daný produkt. Úkol může být třeba i delšího časového úseku (např. telefonická kampaň na celý měsíc).
V neposlední řadě lze evidovat, kolik času se strávilo na zadání, analýze, vývoji, propagaci či podpoře, a to s možností detailu na aplikaci, modul, formulář apod. Nabízí tedy možnost poučit se, následně včas zareagovat a tím ušetřit čas i peníze.
5.3.3 Analýza oddělení Podpora
Jelikož oddělení Podpora zadává do aplikace JIRA nejvíce návrhů, bylo nezbytné provést analýzu i v tomto oddělení.
Výhody JIRA
Velkou výhodou je výrazně lepší správa projektů a navazujících úkolů. Jsou zde možnosti odkazovat, spojovat nebo vytvářet pod-úkoly.
Propojení s Confluence – rychlé vytváření úkolů z Confluence do JIRA
Další výhodou je možnost rychlé tvorby odkazů a vkládání dokumentů.
Nevýhody JIRA
Z pohledu podpory je největší nevýhodou cena, která se váže na počet zakoupených licencí.
Porovnání JIRA a INFO
Interní program Info.exe dominuje především ve sledování docházky či kalendářích nejen zaměstnanců, ale také aut, zasedacích místností či jiných komponent.
Aplikace JIRA je lepším řešením pro propojování úkolů, odkazování na úkoly, přidávání odkazů (na web, na Confluence atd.) a sdílení informací s dalšími uživateli.
JIRA také na rozdíl od Info.exe umožňuje lepší přehledy a výstupy z používání.
Doporučení na využití aplikace JIRA
Oddělení vývoje souhlasí s využíváním aplikace JIRA na sledování projektů a dalších úkolů.
Nicméně Info.exe bude ponechat na sledování docházky, rezervaci aut, zasedacích místností, kalendář naplánovaných služebních cest apod.
5.4 Shrnutí
Využití systému JIRA je každým oddělením doporučeno pro interní komunikaci mezi odděleními Vývoje, Podpory a Produktu. Do aplikace se budou zadávat návrhy na změny, opravy či vylepšení programu. Budou se zde evidovat i hodiny strávené nad daným úkolem.
Databáte však bude propojena s interním programem Info.exe, kam se budou importovat již zmíněné hodiny. Proto bude i nadále hlavním nástrojem pro evidování docházky program Info.exe.
Závěr
Cílem mé bakalářské práce bylo popsat proces implementace podpory komunikace se zákazníkem, provést návrhy na zlepšení včetně implementace samotné a následně provést analýzu napříč odděleními, kterých se týká.
Budeme-li tedy vycházet z provedené analýzy na implementaci a funkčnost systému, považuji své cíle za splněné, neboť implementace systémů značně zefektivnila proces komunikace operátorů se zákazníky. Zákazníci nyní mají možnost využít znalostní databáze podniku nebo systému Helpdesk, díky němuž dostanou odpověď na své žádosti zpravidla ještě daný den. Implementován byl i systém JIRA, který zjednodušuje a zpřehledňuje komunikaci mezi odděleními, které mají na starosti zpracování zákaznických požadavků na vylepšení nebo opravu poskytovaného programu. Díky tomu může operátor efektivněji komunikovat se zákazníkem a informovat ho o stavu jeho požadavku v co nejkratším možném čase.
