Analýza komunikace v call centru outsourcingové softwarové firmy

Transkript

1 Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Vyšší odborná škola informa ních služeb v Praze Natallia Nitievskaya Analýza komunikace v call centru outsourcingové softwarové firmy Bakalá ská práce 2012

2 Prohlášení Prohlašuji, že jsem bakalá skou práci na téma Analýza komunikace v call centru outsourcingové softwarové firmy vypracovala samostatn a všechny citace a parafráze ádn vyzna ila v textu. Veškerou použitou literaturu a podkladové materiály uvádím v p iloženém seznamu literatury. V Praze dne Podpis

3 Pod kování Na tomto míst bych ráda pod kovala vedoucí své bakalá ské práce PhDr. Helen Ku erové za odborné vedení, cenné rady, p ipomínky a v neposlední ad za velkou trp livost.

4 Abstrakt Cílem této bakalá ské práce je zpracování analýzy komunika ních proces realizovaných v call centru spole nosti CSC. Podklady pro práci erpám z vlastních zkušeností ve spole nosti CSC. Informace, komunikace a firemní kultura budou sloužit jako podklad pro analýzy komunika ních proces. Sb r dat bude probíhat prost ednictvím zaznamenávání dat do systému, vytvo ení reportu v aplikaci Incident Management Console. Bude následovat analýza t chto dat a vymezení slabých stránek v oblasti firemní komunikace. Pro vytvo ení analýzy v pr hu práce byl detailn popsán provoz helpdesku. Teoretický základ práce sestává z úvodu do problematiky helpdesku a popisu pojm dané tematiky. Všechny pojmy uvád né v této práci jsou názvoslovím používaným ve spole nosti CSC. V práci budou vymezeny klí ové role pro fungování helpdesku, popsány pracovní úkoly a odpov dnosti každého z nich. Klí ové role budou znázorn ny v organiza ní struktu e spole nosti. Budou popsána kritéria hodnocení helpdesku na konkrétním íklad poskytování outsourcingové podpory pro pojiš ovny s více sv tovými pobo kami, s nimiž byly uzav eny konkrétní smluvní podmínky, tak zvané SLA (Service Level Agreement). V práci byly ponechány výrazy v angli tin. Je to p edevším proto, že v eském jazyce není pro tyto výrazy vymezen konkrétní název. eský p eklad je uveden v p ípad popisu výraz a pojm.

5 Abstract The aim of this bachelor work is to describe the way of providing Help Desk services and to propose several concrete improvements for target company. In this work I am using my own experiences from the company CSC. In the beginning I was trying to describe what does helpdesk mean, ways of supporting customers and the main practices of ITIL. I was introducing the key terms used in the company. The organization structure and the key roles were described. The work contains the description of instruments used in the company for customer support. Incident Management Console is the one which is mainly used in the company. I was creating three types of analysis: projects where the data were analyzed during three days of support by only one agent, seven days of support by all agents. The results of the questionnaire were assayed as well. At the end I was trying to summaries the main problems in Help Desk and propose several concrete improvements for target company.

6 OBSAH Úvod... 9 Teoretická ást Popis spole nosti Úvod do problematiky helpdesku Definice pojm Fungování helpdesku Klí ové role z pohledu agenta helpdesku Nástroje helpdesku Analytická ást Analýza zpracování incidentu za vybrané asové období Diagram aktivit Popis projektu Kritéria pro hodnocení helpdesk Analýza vybraných kritérií Speed of answer (rychlost p ijetí hovoru) SLA First Call Resollution (Úrove vy ešení incidentu) SLA Ticket accuracy (Popis incidentu) SLA Eskalace SLA Pr rný as na vy ešení incidentu SLA Customer Satisfaction (Spokojenost zákazníka) SLA Incident type (Typ incidentu) - vlastní kritérium hodnocení... 44

7 3.4.8 Call duration (Délka trvání hovoru) - vlastní kritérium hodnocení Knowledge Tool usage (Použití znalostní databáze) vlastní kritérium hodnocení Dotazník Výsledky analýzy Slabé stránky helpdesku Záv r Literatura Seznam tabulek Seznam obrázk Seznam graf Seznam p íloh... 71

8 Úvod Ve své bakalá ské práci jsem se rozhodla v novat analýze komunikace v helpdesku. vodem pro výb r tohoto tématu je vlastní pracovní zkušenost ve spole nosti, která se zabývá poskytováním outsourcingu IT služeb. Obecn je helpdesk orientován zejména na pomoc a podporu zákazník m/uživatel m. Na rozdíl od oby ejných call center eší agent helpdesku i složit jší požadavky. Zam stnanci helpdesku musí disponovat ur itými znalostmi a dle charakteru poskytované služby. Cílem mé práce bude volba vhodné metodiky a s jejím využitím zpracování analýzy komunika ních proces ve spole nosti Computer Science Corporation (CSC). Informace, komunikace a firemní kultura budou sloužit jako podklad pro analýzu komunika ních proces. Sb r dat bude realizován zaznamenáváním dat do systému, tvorbou report v aplikaci Incident Management Console, používaných ve spole nosti CSC. Bude následovat analýza t chto dat a návrh takových opat ení v oblasti firemní komunikace, které pomohou odstranit p ípadné poruchy v komunikaci uvnit firmy. Pro vytvo ení analýzy byl detailn popsán provoz helpdesku. Teoretický základ tvo í popis pojm dané tematiky. Všechny pojmy uvád né v této práci jsou názvoslovím používaným ve spole nosti CSC. V práci budou vymezeny klí ové role fungování helpdesku, popsány pracovní úkoly a odpov dnosti každého pracovníka. Klí ové role budou znázorn ny ve schématu organiza ní struktury spole nosti. Budou popsána kritéria hodnocení helpdesku na konkrétním p ípad poskytování outsourcingové podpory pro pojiš ovny s více sv tovými pobo kami, vymezeny konkrétní smluvní podmínky, tzv. SLA (Service Level Agrement). V textu práce byly ponechány výrazy v angli tin. Je to p edevším proto, že eský jazyk nezná p íslušné ekvivalenty k t mto výraz m. eský p eklad je uveden v p ípad popisu výraz a pojm. 9

9 Teoretická ást 1 Popis spole nosti hem více než 50 let si spole nost CSC udržela pozici sv tového lídra v poskytování technologií, hotových ešení a služeb. Ve východní a st ední Evrop spole nost reprezentují t i pobo ky v Praze, Sofii a Vilniusu, kde zam stnává kolem 1400 zam stnanc v oblasti consultingu, systémové integrace a outsourcingu. CSC zde poskytuje ešení na míru pro r zná pr myslová odv tví. V dnešní dob m že díky zkušeným operátor m helpdesku poskytovat kvalitní služby. Obrázek 1. Pokrytí spole nosti CSC ve st ední a východní Evrop. Zdroj: V roce 2007 spole nost CSC Computer Sciences s.r.o. otev ela v Praze tzv. Delivery Center. Pobo ka v Praze poskytuje podporu na velmi dobré úrovni. Centrum v Praze zam uje své aktivity na služby outsourcingu a konkrétn na podporu první a druhé úrovn. Podpora v helpdesku se provádí v devíti jazycích (n ina, angli tina, eština, polština, slovenština, francouzština, špan lština, italština a ruština). Komunikace mezi zam stnanci probíhá p evážn v angli tin [1]. 10

10 2 Úvod do problematiky helpdesku Pod pojmem helpdesk rozumíme pracovišt nebo službu, která poskytuje pomoc v r zných oblastech r zným subjekt m. V dnešní dob je možné se s tímto pojmem nej ast ji setkat v oblasti IS/ICT. V p ípad využití externího helpdesku v podniku, jehož fungování bude podrobn rozebráno v této práci, poskytuje firma podporu svým zákazník m (klient m). V p ípad interního helpdesku pak firma poskytuje podporu svým vlastním zam stnanc m. Helpdeskové pracovišt pak zpravidla eší požadavky spojené s uživatelskými problémy v oblasti po íta, notebook, tiskáren, telefon a mobilních za ízení. Zadavatel požadavku se spojí s ešitelským týmem telefonicky nebo prost ednictvím vhodné aplikace. ešitelský tým disponuje znalostmi a schopnostmi pot ebnými pro vy ešení problému. Zadavatel je bu veden k vy ešení požadavku nebo má agent helpdesku možnost vzdálen se p ipojit k po íta i zákazníka. Jinou možností poskytování podpory je p edání incidentu technikovi, který na pracovišt p ijde a vy eší požadavek. Má-li firma helpdeskové pracovišt, které musí p ijímat denn velké množství požadavk, vyplatí se jí implementovat specializovanou helpdeskovou aplikaci. Tato aplikace pak zpravidla nabízí p ehledné rozhraní pro ešitele požadavk a p ípadn i pro jejich zadavatele. ešitelé díky ní mají požadavky centráln na jednom míst, což umožní nap. i kontrolu jejich innosti managementem [2]. Velký po et na IT zam ených spole ností zvažuje využítí metodiky ITIL pro zlepšení ízení služeb provozu ICT, které dodává svým zákazník m. Pod zkratkou ITIL (Infrastructure Library) rozumíme rámec (framework), který slouží pro správu IT služeb. Je tzv. knihovnou, která popisuje nejlepší zkušenosti z praxe v oblasti údržby softwarových systém na základ nejlepších projekt. ITIL používá jasn definovanou terminologii ve sfé e IT, která byla p vodn vyvinuta pro britskou vládu. V dnešní dob je standardem používaným po celém sv. První verze ITIL vyšla na konci 80. let a sestávala z 46 knih, druhá verze vznikla v roce 2000 a skládá se pouze z osmi knih. Nejnov jší verze má jenom t i knihy a jednu p ehledovou studii. ITIL není standardem, pomocí kterého by bylo možné organizace posuzovat a hodnotit. Pro ú ely hodnocení organizace je používán mezinárodní standard ISO Na ITIL se dá certifikovat pracovníky helpdesku, ale ne organizaci samotnou. 11

11 Níže uvedena struktura verze 3 ITILu: Service Strategy zabývá se sla ováním podnikových proces s IT a jeho podporou, strategií IT služeb, plánováním. Sevice Design ešení IT služeb, návrh proces (tvorba a údržba IT architektury). Service Transition p edání IT služby do provozního prost edí. Service Operation správa aplikace, zm n, provozu. Continual Service Improvement hnací body ke zlepšení IT služeb. Official Service Improvement základní koncept ITSM, místo ITIL v modelu životního cyklu. [3]. 2.1 Definice pojm Všechny pojmy uvád né v této práci jsou názvoslovím používaným ve spole nosti CSC. V této kapitole p edstavuji pojmy pot ebné pro orientaci v dané problematice. Incident Pod pojmem incident rozumíme událost, která p esahuje rámec standardní operace a také vede nebo m že vést ke snížení kvality poskytovaného servisu. Typickým p ípadem je incident zaznamenaný koncovým uživatelem. Pod pojmem incident také rozumíme požadavek na poskytnutí rady, informace a dokumentace. Klient (koncový uživatel) Zaznamenává incident a informuje helpdesk o této skute nosti. B hem ešení incidentu dostává klient informaci o stavu incidentu. Klient m že být požádán o poskytnutí informací pot ebných k vy ešení incidentu. Helpdesk Je prvním kontaktem pro klienta, na který se má obracet v p ípad zaznamenání incidentu. Musí rychle reagovat na požadavek klienta, poskytuje vysokou úrove týmové spolupráce. Má za úkol p ízniv zap sobit na klienta. 12

12 Ticket Pod termínem ticket rozumíme záznam, který byl vytvo en agentem helpdesku. Každý ticket musí poskytovat informaci o zákazníkovi (jméno, p íjmení, ová adresa, kontaktní telefon, popis toho, co bylo ud láno agentem helpdesku pro vy ešení incidentu, a v p ípad, že incident ješt nebyl vy ešen, i název ešitelského týmu. Každému ticketu se automaticky id luje referen ní íslo, které slouží jako poznávací íslo pro klienta. SLA (Smlouva o poskytování služeb) Tato smlouva je základem pro obchodní vztahy a spolupráci s klientem. Obsah a rozsah SLA je spojen s velikostí organizace. Obecn zahrnují smlouvy SLA základní údaje o služb : název služby, organiza ní údaje (smluvní strany, datum schválení), provozní specifikace služby, cena služby, bonusy a sankce v p ípad nedosažení kvality jednotlivých parametr služeb. Knowledge tool (Znalostní databáze) Jedná se o aplikaci, která je používána všemi pracovníky helpdesku pro vytvá ení, vyhledávání, prohlížení a správu dat, které jsou pot ebné pro vy ešení incidentu. Znalostní databáze je postupn dopl ována daty, která jsou shromaž ována na základ praxe agent všech úrovní podpory. Znalostní tým tuto databázi postupem asu upravuje, aby existovalo aktuální ešení pro jakýkoliv incident. Status Informuje nás o aktuálním stavu ticketu a m že nabývat n kolika hodnot. Existují takové statusy jako resolved FCR (incident je vy ešen). Po vy ešení incidentu má klient p t pracovních dn na reklamaci a znovuotev ení incidentu. Po uplynutí pátého dne se status incidentu m ní na closed a incident nelze znovu otev ít. Pokud incident není vy ešen na první úrovni, ticketu je azen status assigned nebo in progress. V p ípad, že p i ešení incidentu eká ešitelský tým na reakce klienta, status incidentu je pending client action required. Každý ticket m že být uzav en jako vy ešený (resolved status) jen po domluv s klientem. (resolved no futher action required). 13

13 2.2 Fungování helpdesku Helpdesk plní službu CRM (Customer Relationship Management) a call centra. Agenti helpdesku se snaží v co nejkratším asovém okamžiku vy ešit primární množství požadavk od klienta. Za delší dobu fungování pomohla spole nost CSC více než sto klient m po celém sv. B hem mé pracovní innosti ve spole nosti jsem byla p irazena k týmu, který se zabývá poskytováním outsourcingové služby helpdesku pro v tší pojiš ovnu s pobo kami po celém sv. CSC má smlouvu o poskytování služeb s pojiš ovnou již déle než p t let. Podpora probíhá ve ty ech sv tových jazycích 24 hodin denn, 7 dní v týdnu v etn všech svátk. Provoz je zajišt n p ibližn stovkou agent první úrovn, kte í jsou rozd lováni do tým podle stát, v nichž konkrétní pobo ka pojiš ovny sídlí. Strukturu podpory na první úrovni ukazuje obrázek. 2. Obrázek 2. Struktura podpory na první úrovni. Podpora první úrovn Anglický tým Švýcarský tým (40) Italský tým Španelský tým ina Angli tina Italština Francouština Zdroj: vlastní zpracování. Ve spole nosti je p ítomna i druhá úrove podpory, která se skládá ze t í tým : 1) Idadmin tým se zabývá poskytováním p ístupu ke konkrétním aplikacím. Každý požadavek, který p ichází od klienta, musí být schválen manažerem. Až po schválení klientovi p id lují konkrétní p ístup k systému. 2) Lotus Notes tým se zabývá poruchami v ovém systému Lotus Notes a p ípadn konkrétními požadavky ze strany klienta. 14

14 3) Remote control tým využívá program Unicenter Remote Control. Agent druhé úrovn se p es vzdálený p ístup p ípojí k po íta i klienta a získává plnou kontrolu nad po íta em. Tento tým v tšinou eší chyby p i instalaci. Struktura podpory druhé úrovn je zobrazena na obrázku. 3. Obrázek 3. Struktura podpory na druhé úrovni. Podpora druhé úrovn Idadmin tým Lotus Notes tým Remote control tým Zdroj: vlastní zpracování. Jak už bylo eno, podpora podle smlouvy s klientem musí být zajišt na 24 hodin denn. Sm ny pro agenty helpdesku, kte í pracují p es den, jsou stanoveny mezi hodinou, pro agenty no ní podpory jsou od 19 do 7 hodin ráno. Standardní sm na je od 9 do 18 hodin, což vychází z toho, že nejvíce hovor bývá p ijato v tomto asovém rozmezí. Po et hovor p ijatých všemi agenty helpdesku není stejný. Je z ejmé, že do helpdesku p ichází více hovor p es den než v noci. Graf. 1 ukazuje po ty p ijatých hovor v závislosti na denní dob. Graf 1. Po et p ijatých hovor v závislosti na denní dob :00-09:00 9:00-12:00 12:00-14:00 14:00-16:00 16:00-18:00 18:00-20:00 20:00-06:00 Zdroj: vlastní zpracování. Ze zkušenosti vím, že mezi 9. a 12. hodinou p ichází více hovor. Vedoucí týmu musí zajistit sm ny agent tak, aby na tento asový okamžik p ipadalo více agent. Základem pro dobré výsledky je p edpoklad, že b hem t chto t í hodin, kdy je po et p íchozích požadavk 15

15 nejvyšší, se agent nejvíce soust edí na svou práci a pokouší se vyhov t co nejv tšímu množství klient. Po et p ijatých hovor se liší i v závislosti na dnu v týdnu. Nejvíce jich je p ijato od pond lí do st edy, po et se mírn snižuje b hem tvrtku a pátku. B hem víkendu dostáváme nejmenší po et hovor. Samoz ejm je to spojeno s tím, že klient má v tšinou volno. Vedoucí týmu zajiš uje maximální podporu b hem prvních t í dn v týdnu. V týmu jsou agenti pracující na zkrácený úvazek. Jejich sm ny v tšinou p ipadají na pond lí, úterý a st edu. Dva následující grafy popisují po et p ijatých hovor a zajišt ní po tu agent podle dn v týdnu. Graf 2. Po et p ijatých hovor podle dn v týdnu Pond l í Úterý St eda tvrtek Pátek Sobota Ned le UK L UK G Zdroj: vlastní zpracování. Graf 3. Po ty agent podle dn v týdnu Pond lí Úterý St eda tvrtek Pátek Sobota Ned le Zdroj: vlastní zpracování. 16

16 2.3 Klí ové role z pohledu agenta helpdesku Pro lepší porozum ní komunikace na helpdesku je d ležité osv tlit jeho organiza ní strukturu. Ta je znázorn na na obrázku. 4. Obrázek 4. Organiza ní struktura helpdesku. Vedoucí helpdesku Provozní editel První úrove podpory ový tým Druhá úrove podpory Vedoucí týmu UK Vedoucí týmu CH Vedoucí týmu ŠP a IT Zástupce vedoucího Agenti Zástupce vedoucího Agenti Zástupce vedoucího Agenti Idadmin Lotus Notes Remote control Zdroj: vlastní zpracování. Agenti helpdesku (Agents of the helpdesk) Role agent zastává v pr ru 25 lidí. Základním úkolem je vy ešení incidentu klienta telefonicky. P ed prvním p ijetím hovoru se musí každý nový agent zú astnit dvoutýdenního tréningu. Obvykle se trénink skládá ze dvou ástí: obecné informace o chodu helpdesku a specifický tréning zam ený na konkrétní tým. Každý agent se musí p izp sobovat situaci v týmu. Každý agent a pak i celý tým je hodnocen z r zných hledisek. Nap íklad má tým vytvo enou rezervu v po tu p ijatých hovor. M že dojít i k situaci, že v týmu momentáln není dostate ná rezerva ohledn hodnocení agenta klientem. Agent se musí více zam it na p íjemn jší a kvalitn jší komunikaci se zákazníkem než na kvantitu hovor. 17

17 Zástupce vedoucího (Account prime) ed postupem na pozici zástupce vedoucího je zam stnanec zpravidla agentem. asem v týmu vykrystalizuje pracovník, který je velmi p izp sobivý konkrétním situacím, zpravidla je technicky zam ený a má více zkušeností v konkrétním týmu. Zvykem je, že zástupce radí novým agent m, kterým chybí praxe. Vedoucí týmu (Team leader) Pozice vedoucího týmu obnáší celou adu povinností: plánuje sm ny, má na starosti podporu provozu, je zodpov dný za zajišt ní dostate ného po tu agent pro vedení každodenního provozu, hodnotí práci agent a v tšinou rozhoduje o uzav ení nebo ukon ení pracovního pom ru, sleduje atmosféru v týmu (dobra nálada v týmu je velice d ležitou sou ástí fungování helpdesku, oby ejn vedoucí týmu plánuje n jaké spole né setkání týmu nad rámec pracovní doby), komunikuje s vedením klienta. (Ob as totiž dochází k situaci, kdy je klient nespokojen s poskytnutým servisem a m že kontaktovat p ímo vedoucího helpdesku pro vy ešení situace.) ový tým ( team) Pro situace, kdy klient z n jakého d vodu nem že zavolat na helpdesk, byla pro zákazníky vytvo ena webová aplikace, kde mohou samostatn vytvo it ticket. ový tým má konkrétn vymezené asové období pro reakci na požadavek od klienta, který byl zadán prost ednictvím u nebo online systému. 18

18 Obrázek 5. Systém helpdesku online. Zdroj: CSC. 2.4 Nástroje helpdesku V této kapitole uvádím základní aplikace, které agenti helpdesku používají p i své práci. Incident Management a Remedy Knowledge Management jsou systémy, které agent helpdesku používá nej ast ji. Incident Management slouží pro vytvo ení incidentu, vyhledávání a pr žné ukládání pot ebných zm n v ticketu. Remedy Knowledge Management je tzv. Knowledge Tool (znalostní databáze). Lze v ní najít informace o aplikacích používaných zákazníkem. Pro každou aplikaci existuje popis chyb, které mohou v systému nastat, a také informace o ešitelských týmech. Na obrázku. 6 jsou znázorn ny tyto dv d ležité aplikace pot ebné pro fungování celého helpdesku. 19

19 Obrázek 6. Nástroje helpdesku. Zdroj: CSC. Po podrobn jším prozkoumání Incident Managementu lze identifikovat t i nej ast jší možnosti jeho použití: vytvo ení nového incidentu, vyhledání incidentu a p azení práce agent m helpdesku. P edstavu o vzhledu systému Incident Management Console a Remedy Knowledge Console si lze vytvo it na základ obrázk. 7 a 8. Obrázek 7. Incident Management Console. Zdroj: CSC. 20

20 Obrázek 8. Remedy Knowledge Console. Zdroj: CSC. Když vytvá íme nový incident poprvé, zapisujeme jméno a p íjmení klienta. Po zadání jména a p íjmení pak systém nabídne možnost vybrat profil klienta. M že se stát, že existují dv nebo více osob se shodným jménem a p íjmením, proto je povinnou procedurou ov ení všech detail klienta. Ov ujeme jeho jméno, p íjmení, telefonický kontakt, ovou a kontaktní adresu. Zpravidla klient volá s již existujícím incidentem a jeho referen ním íslem. V tomto ípad volíme možnost, kterou nabízí Incident Management Console pro již existující ticket. V sekci Assigned Work (p azená práce) m žeme sledovat tickety, které vyžadují dopln ní dodate ných informací. Obrázek 9. Citrix Systems. Zdroj: CSC. 21

21 Pro p ístup do aplikací používaných klientem se agent helpdesku musí p ihlásit do Citrix Systems Inc, jehož vzhled m žeme vid t na obrázku. 9. Jde o nadnárodní korporace dodávající technologie pro vitalizaci server, vitalizaci desktop, po íta ové sít, SaaS (software jako služba) a cloud computing více jak organizacím na celém sv. P ední technologie z oblasti vitalizace, cloud computingu, spolupráce a networkingu umož ují zjednodušovat komplexní firemní IT a podporují rozvoj mobilního pracovního stylu a jednotlivých cloudových služeb. Denn Citrix zasahuje až 75 procent internetových uživatel a spolupracuje s více jak deseti tisíci spole nostmi ve sta zemích sv ta. [4] Velký d raz p i vy ešení požadavku od klienta je kladen také na systém Bomgar, který agent m helpdesku umož uje vzdálený p ístup k po íta i klient [5]. 22

22 Analytická ást 3 Analýza zpracování incidentu za vybrané asové období 3.1 Diagram aktivit Na za átku analýzy jsem cht la stru popsat proces ešení incidentu agentem na první úrovní podpory. Nejlepší zp sob pro znázorn ní komunikace v helpdesku je pomocí diagramu aktivit (viz obr.. 10). V modelu jsou p edstaveny ty i organiza ní jednotky nebo tzv. entity, které jsou zodpov dné za proces. Jsou to ový tým, klient, helpdesk a workflow. Když na stran klienta nastane problém, má v tšinou t i možnosti k jeho vy ešení: pokusit se o samostatné ešení, zalogovat incident prost ednictvím online systému nebo zavolat na helpdesk. Na diagramu aktivit jsou dále popsány t i cesty vedoucí k vy ešení požadavku zákazníka. Na základ vlastních zkušeností mohu potvrdit, že první cesta, kdy klient vy eší incident zcela sám, není vždy zcela ideální. Existují systémové chyby, ke kterým m že dojít p i práci v r zných aplikacích. M že kup íkladu se zdát, že po restartování po íta e je incident vy ešen. Musíme však po ítat s tím, že za n jaký as se m že incident objevit znova. Zákazník je jen kone ným uživatelem a nemá speciální administrativní p ístup a znalosti, kterými disponuje helpdesk. Druhá možnost - zalogování incidentu online trvá delší dobu. ový tým pošle incident na ešitelský tým, který následn kontaktuje zákazníka. Nejlepším zp sobem je dle mého názoru zavolání do helpdesku a vy ešení incidentu telefonicky (obrácení se na horkou linku podpory). Prvním a povinným procesem p i komunikaci klienta a helpdesku je ov ení totožnosti klienta. Ov uje se kontaktní telefon, pracovišt a ová adresa v profilu klienta. Klient popisuje incident a agent zapisuje pot ebnou informaci do ticketu. Za átek hovoru vypadá následovn : Thank you for calling your helpdesk. My name is Natallia. Can I have your first and last name? Is your phone number? And where are you based, your location please? How can I help you? 23

23 Po ov ení volající popisuje sv j incident nebo požadavek. V pr hu komunikace agent pokládá dopl ující otázky pot ebné k vy ešení incidentu. Agent následn v kolonce ticket summary stru popíše problém, kv li kterému zákazník volal. Pro lepší názornost uvádím íklad ticketu a jeho popisu: KTZ 4263 #název aplikace# zm na hesla. D ležité je, aby každý stru ný popis obsahoval kód KTZ - kód znalostní databáze. V ticket notes (rozší ený popis incidentu) pak agent popisuje daný problém podrobn. P íklad: uživatelské jméno: X, název aplikace, ov ení osoby: ano, úsp šné zalogování: ano, rozší ený popis incidentu p i zm hesla. Zm na hesla m že být p íkladem jednoduššího incidentu. Základní informace, které musí klient poskytnout p ed zasláním ticketu na ešitelský tým, jsou: id_klienta, pracovišt, kontaktní telefon, ová adresa, jazyk podpory, popis incidentu klientem, po et klient zasažených incidentem, popis postup, které byly provád ny p i pokusu o vy ešení incidentu, referen ní íslo použité znalostní báze, asset number íselné ozna ení každého kusu hardwaru, tiskárny, LCD monitoru, notebooku atd). ležitým krokem je ov ení, zda incident ovliv uje více klient. V tomto p ípad má agent helpdesku informovat workflow pro potvrzení tzv. severity (naléhavosti) incidentu a ešitelského týmu. V závislosti na obtížnosti ešení incidentu m že být identifikováno hned nebo po ov ení pot ebné informace ve znalostní databázi. M že také dojít k situaci, že ve znalostní databázi se pot ebná informace nevyskytuje a agent se musí obrátit na zástupce vedoucího týmu. Ten má obvykle v tší zkušenosti s ešením obtížn jších incident a poskytuje jednotlivým agent m doporu ení. Agent a zástupce vedoucího týmu spolupracují na vy ešení incidentu. V p ípad, že má být incident vy ešen na druhé úrovni podpory, poskytne agent referen ní íslo incidentu, díky kterému si zákazník m že kdykoliv ov it status ticketu prost ednictvím helpdesku. i telefonické komunikaci je velký d raz kladen na dobré komunika ní schopnosti agenta helpdesku. Klient volá zpravidla proto, že sv j požadavek pot ebuje vz ešit v co nejkratším asovém úseku. Pro agenta m že být náro né klienta uklidnit a vést dialog natolik profesionáln, aby klient nem l sebemenší pochybnost o kompetentnosti daného agenta. CSC Computer Science s.r.o., je mezinárodní spole nost, ve které pracují lidé z celého sv ta. Pro v tšinu z agent není angli tina mate ským jazykem, a koli se p i komunikaci s klienty používá výhradn. Tato skute nost m že být p ekážkou v porozum ní mezi klientem a agentem helpdesku. 24

24 Obrázek 10. Business proces model komunikace v helpdesku. Zdroj: vlastní zpracování. 25

25 3.2 Popis projektu Hodnocení procesu komunikace v helpdesku byl realizován ve t ech etapách: pilotní projekt (3 dny), projekt (7 dní), analýza dotazník. Etapy se lišily v n kolika zásadních aspektech: Délka analýzy incident. V p ípad pilotního projektu byly incidenty zaznamenávány po dobu t í pracovních dn. V samotném projektu pak délka sledovaného období inila sedm dní. Po et analyzovaných incident. V prvním p ípad bylo hodnoceno 29 incident, ve druhém 1511 incident. Po et agent, kte í incidenty zaznamenávali. V pilotním projektu byly analyzovány incidenty, které zalogoval pouze jeden agent helpdesku, ve druhé fázi pak tickety p ijaté všemi agenty helpdesku. Níže uvedená tabulka ukazuje samostatn vytvo ená kritéria hodnocení helpdesku a analýzu navrženého dotazníku. V tabulce. 1 jsou zelenou barvou a výrazem ano vyzna ena kritéria spole ná ob ma projekt m. Tabulka 1. Kritéria hodnocení helpdesku. Kritéria hodnocení Zdroj: vlastní zpracování. Pilotní projekt (3 dny) Projekt (7 dní) 1 Rychlost p ijetí hovoru (Speed of answer) SLA1 ano 2 Úrove vy ešení incidentu (First Call resolution) SLA2 ano ano 3 Popis incidentu (Ticket accuracy) SLA3 ano 4 Spokojenost zákazníka (Customer satisfaction) SLA6 ano Dotazník 5 Typ incidentu (Type of incident) vlastní návrh ano ano ano 6 Délka trvání hovoru (Duration of call), vlastní návrh ano ano ano 7 Použití znalostní báze (Knowledge tool usage), vlastní návrh ano ano 26

26 Pilotní projekt (3 dny) Incidenty p ijaté od klient byly zpracovány za vybrané asové období od do jedním agentem helpdesku. V každém ze t í dn pilotního projektu ( tvrtek, pátek a sobota) jsme zaznamenali r zný po et p ijatých incident. B hem provozu ve tvrtek ( ) do helpdesku p icházelo více požadavk než nap íklad v sobotu ( ). hem této doby byl provoz helpdesku standardní, ili nebyly zaznamenány situace, které by narušily normální chod helpdesku. Nedošlo k výpadku systému, zvýšenému množství íchozích hovor ani k nedostatku agent helpdesku. Analýzu hodnocení incident za vybrané asové období jsme sestavovali na základ : úrovn vy ešení incidentu (First Call resolution) - SLA2, typu incidentu (Type of incident) - vlastní návrh, použití znalostní báze (Knowledge tool usage) - vlastní návrh, délky trvání hovoru (Duration of call ) - vlastní návrh. Sb r dat Pro analýzu pilotního projektu byla vytvo ena tabulka. 2 (na následujících stranách). Data byla p enesena z ticketu do tabulky a obsahují informace pot ebné pro analýzu komunika ních proces v helpdesku. Celkem jsme analyzovali 29 incident vytvo ených jedním agentem první úrovn podpory b hem t í dn. 27

27 Tabulka 2. Seznam p íchozích incident. Po adí Summary Notes Ticket Status Resolver group Time spent for resolving a ticket Submit date Resolved day Start Finish 1 KTZ 4263 #ESS# password reset Username:1 System Password required for:ess Security check: Y/User logged in successfully: Y First Call Resolved 1 level support 0:04:51 3/31/2012 3/31/ :26:48 12:31:39 2 KTZ 3042 mapped the printer Remote Control FCR User was not able to print reinstall the printer. First Call Resolved 1 level support 0:20:56 3/31/2012 3/31/ :53:58 12:14:54 3 KTZ 7925 cicso connection set up Remote Control FCR Remote control Cicso set up for the user. First Call Resolved 1 level support 0:21:20 3/30/2012 3/30/2012 5:09:55 5:31:15 4 KTZ 3940 #EDC# password reset Username:2 System Password required for:edc Security check:y/ User logged in successfully:y First Call Resolved 1 level support 0:05:56 3/30/2012 3/30/2012 5:01:17 5:07:13 5 SNF CApita issue LOG advise the contact [Information] Contact info provided:service delivery manager has advised that Cathy Wheeler should be the contact for any issues with this application. First Call Resolved 1 level support 0:11:30 3/30/2012 3/30/2012 4:47:53 4:59:23 6 KTZ 3221 cogen issue advise to contact Yogesh [Information] Not able to redirect the claim. Advise to Contact manager. First Call Resolved 1 level support 0:15:04 3/30/2012 3/30/2012 2:02:10 2:17:14 7 KTZ 3041 internet issue Remote Control FCR User was not able to cannot to the internet restart, the router works fine. First Call Resolved 1 level support 0:33:25 3/30/2012 3/30/2012 1:18:42 1:52:07 28

28 8 KTZ 5189 #core elixir# session clear Username:3 System Password required for: (ex:gad/sap/mf) core elixir User logged in successfully: Y First Call Resolved 1 level support 0:05:47 3/30/2012 3/30/2012 1:08:19 1:14:06 9 KTZ 3102 IT Direct advise to make a request Information] User is having issue with PCF viewer was no requested the access advice to request. First Call Resolved 1 level support 0:02:36 3/30/2012 3/30/2012 1:05:43 1:08:19 10 KTZ 3042 printer set up Remote Control FCR RKM(s) checked :3042 User ID :gblabt printer set up for the user First Call Resolved 1 level support 0:12:58 3/30/2012 3/30/ :18:17 12:31:15 11 KTZ 3359 ES password reset Username:4 System Password required for: ES Security check: Y/ User logged in successfully: Y First Call Resolved 1 level support 0:07:32 3/30/2012 3/30/ :58:21 12:05:53 12 KTZ 7452 Self Resolved Issue Internet issue Home user is calling having the issue with internet, having issue for past 2 days, the light for the internet on the router was showing while calling us internet starts working again if any. First Call Resolved 1 level support 0:06:27 3/30/2012 3/30/ :29:17 11:35:44 13 KTZ 5201 monitor settings Remote Control FCR RKM(s) checked :5201 User ID :5 user called reported the screen resolution is wrongly set up, sets up the correct one works fine. First Call Resolved 1 level support 0:09:01 3/30/2012 3/30/ :09:29 11:18:30 14 KTZ 4570 capita desktop issue Remote Control FCR RKM(s) checked :4570 User ID :6 user called regarding the issue with pop up blockers in IE blocking access for the appl delete cahe cookies works fine. First Call Resolved 1 level support 0:10:59 3/29/2012 3/29/2012 6:22:20 6:33:19 15 KTZ 5189 #elixir#session clear Username:7 System Password required for: (ex:gad/sap/mf) elixir Security check: Y/ User logged in successfully: Y First Call Resolved 1 level support 0:10:34 3/29/2012 3/29/2012 4:49:46 5:00:20 16 KTZ 7452 Self Resolved Issue BORP [Information] KTZ 7452 Self Resolved Issue Borp database First Call Resolved 1 level support 0:04:59 3/29/2012 3/29/2012 4:05:31 4:10:30 29

29 17 KTZ 5251 adobeacrobat 9.0 installation Remote Control FCR RKM(s) checked :5251 User ID :8 user was having problem to read pdf files updated adobeacrobat 9.0 standart. First Call Resolved 1 level support 0:20:30 3/29/2012 3/29/2012 3:42:04 4:02:34 18 KTZ 3940 #EDC# password reset Username:9 System Password required for: (ex:gad/sap/mf) EDC Security check: Y/ User logged in successfully: Y First Call Resolved 1 level support 0:14:55 3/29/2012 3/29/2012 1:30:55 1:45:50 19 KTZ 7452 Self Resolved Issue ecase Information] Name of user:11 Contact Info: Location:ZFS GBR-Birmingham- 126 Hagley Road case issue was resolved for the user. First Call Resolved 1 level support 0:05:34 3/29/2012 3/29/ :22:10 12:27:44 20 KTZ 5251 adobe installation 9.0 Remote Control FCR RKM(s) checked :5251User ID :12 user needs to get a new version of adobe to be able to view pdf files. First Call Resolved 1 level support 0:20:41 3/29/2012 3/29/ :01:38 12:22:19 21 KTZ 3102 IT Direct advise the user to make request Name of user:13 user called needs to have access to sap BW advised to make request in IT direct. First Call Resolved 1 level support 0:02:50 3/29/2012 3/29/ :35:31 11:38:21 22 KTZ 4982 #GAD#account unlock Username:14 System Password required for: (ex:gad/sap/mf) GAD Security check: Y/ User logged in successfully: Y First Call Resolved 1 level support 0:03:56 3/29/2012 3/29/ :28:25 11:32:21 23 KTZ 7452 checking the reques access shared mailbox User called with a ticket number EU- INC , called that is not completed checked with and user again works fine, user is having shared mailbox mapped. First Call Resolved 1 level support 0:03:10 3/29/2012 3/29/ :21:03 11:24:13 24 Wrong number Wrong number First Call Resolved 1 level support 0:02:01 3/29/2012 3/29/ :10:52 11:12:53 25 *1LU02/04@09-34 KTZ 7110 #SPS# password reset Username:15 System Password required for: SPS Security check: Y Assigned 2 level support ID Admin 3/31/2012 4/2/

30 26 KTZ 4971 instant letters 2 error User is working with a specificy policy on instant letters 2 number: Application error. Assigned 3 level support UK- Capita Cheltenham Support 3/30/ :32: KTZ 9377 reports not loaded CAD05/04@16:00G MT KTZ 5916 megger Power proff isssue Invested files from are not loaded, no reported are showing, these files (reports) are loaded weekly. APPLICATION:ZIG MI User is Megger PowerSuite Professinal application which should generate the reports to LN report, the user created is appearing in the different location. Assigned Assigned 3level support GSSC-BI- APP-ZIGMI 2 level of support Service Desk- Prague-UK Remote 3/30/ :41:40 3/29/2012 6:14:35 29 KTZ 3909 ecase claim issue User is accessing the particular claim on the ecase going the documents field and downloading the selected documents coming with the error. Assigned 3 level support UK- WIPROCEC 3/29/2012 4:11:00 Zdroj: vlastní zpracování. 31

31 Projekt (7 dní) Základem projektu trvajícího sedm dní byla data uložená v informa ním systému Incident Management Console (IMC). Ten umož uje vytvo it report na základ zadaných kritérií a požadavk. Získání dat Pro získání dat z informa ního systému byly provedeny následující kroky v Incident Management Console: 1) Vyhledání incident p ijatých v daném asovém okamžiku. Zajímali jsme se o incidenty p ijaté helpdeskem ( Service Desk-Prague ) b hem sedmi dn ($DATE$ -(7*24*60*60)). Níže uvedená syntaxe kritérií byla použita i vytvá ení reportu: Owner Group+'="Service Desk-Prague" AND 'Status*' < "Closed" AND 'Submit Date' > $DATE$ -(7*24*60*60). Obrázek 11. Vyhledávání incidentu v Incident Management Console. Zdroj: CSC. 2) Výb r dat a vytvo ení reportu. Po zpracování incident informa ním systémem máme k dispozici záznamy vhodné k analýze. Obrázek 12. Vytvo ení reportu v Incident Management Console. Zdroj: CSC. 32

32 3) Výb r kritérií, které budeme používat p i analýze (id_incidentu, summary, notes apod). Obrázek 13. Vytvo ení reportu v Incident Management Console. Zdroj: CSC. 4) Výb r formátu dokumentu CSV(do tabulky v Excelu) Obrázek 14. Vytvo ení reportu v Incident Management Console. Zdroj: CSC. Výsledky dotazu ukázaly 1511 incident vytvo ených agenty první úrovn podpory, hodnocených z r zných hledisek. Na rozdíl od pilotního projektu byly posuzovány incidenty, které byly p ijaty všemi agenty první úrovn helpdesku UK týmu (tedy p ibližn ty iceti agenty). M žeme konstatovat, že po et incident se výrazn zv tšil. 33

33 3.3 Kritéria pro hodnocení helpdesk Je nutné neustále sledovat a hodnotit pln ní outsourcingové smlouvy. Helpdesk je oby ejn hodnocen b hem n jakého asového období, v našem p iklad každý tyden. Pro smluvní podmínku používáme zkratku SLA (Service Level Agreement). Podmínky v sob zahrnují popis poskytované outsourcingové služby, práva a povinnosti konkrétních stran. tšinou jsou popsány takové atributy jako dostupnost služeb, spolehlivost, výkonnost, cenové podmínky a p ípadn sankce a pokuty p i porušení t chto podmínek. V tabulce. 3 uvádím konkrétní smluvní podmínky spole nosti CSC. Tabulka 3. SLA (Service Level Agreement). Critical service levels/kritické úrovn poskytování podpory Expected/o ekávaná hodnota Duration/Target Minimum/minimální hodnota Time % Time % SLA1 Speed of Answer/Rychlost p ijetí hovoru 30 sec SLA2 First Call Resolution/Úrove vy ešení incidentu SLA3 Ticket accuracy/popis incidentu SLA4 Escalations/Notifications 5 min min. 95 SLA5 Incident resolution/vy ešení incidentu Large facility/velký objekt 4 hod hod. 95 Small facility/malý objekt 8 hod hod. 95 SLA6 Customer satisfaction/spokojenost zákazníka Zdroj: CSC. 34

34 3.4 Analýza vybraných kritérií V první ásti analýzy jsme se zam ili na kritéria stanovená smlouvou SLA1, SLA2, SLA3, SLA6. Pro lepší p edstavu o procesu komunikace v helpdesku jsem navrhla vlastní kritéria hodnocení incidentu: typ incidentu, délka trvání hovoru, použití znalostní báze. Analýza byla provedena na základ dat v tabulce. 2 a v tabulce., která je uvedena v p íloze této práce Speed of answer (rychlost p ijetí hovoru) SLA1 Dle prvního kritéria hodnocení by m lo být 80 % všech hovor p ijato do 30 sekund od prvního zazvon ní telefonu. Pokud eká klient na spojení s agentem více než 30 sekund, stává se hovor podle SLA1 automaticky nezodpov zený. Speed of answer neboli rychlost p ijetí požadavku je pro helpdesk tím nejd ležit jším kritériem, p i jehož nedodržení m že být spole nost siln penalizována. Analýza projektu (7 dní) hem zkoumaného týdne helpdesk splnil podmínku SLA1 a p ijal 84,3 % všech íchozích požadavk do 30 sekund. Na toto kritérium je d ležité se zam it na za átku týdne, kdy musí tým vytvo it rezervu a p ijmout naprostou v tšinu hovor, a na konci týdne se v novat více i ostatním kritériím hodnocení. Nejv tší po et požadavk p ichází b hem pond lí a úterý. V t chto dnech je zvýšené riziko, že po et telefonát zodpov zených do 30 sekund klesne pod hranici 80 %. Pak ale tšinou dochází ke kompenzaci v dalších dnech v týdnu. Ve zkoumaném období se UK tým potýkal s t žkostmi na za átku týdne, kdy byl po et p íchozích požadavk nadpr rný. Z mého pohledu to bylo spojeno i s tím, že se zákazníci vraceli z dovolené. Helpdesk byl p ipraven na nadpr rný po et p íchozích požadavk v tomto asovém období a reagoval nasazením více agent. 35

35 3.4.2 First Call Resollution (Úrove vy ešení incidentu) SLA 2 Podle druhého kritéria hodnocení by m lo být minimáln 80 % p ípad vy ešeno i prvním kontaktu se zákazníkem na první úrovni podpory. P icházející incidenty m žeme t ídit podle toho, zda je agent vy eší ihned p i prvním zavolání, nebo je musí eskalovat ešitelskému týmu. Úrove vy ešení incidentu SLA2 byla analyzována v obou fázích výzkumu. V pilotním projektu vycházela analýza z incident p edaných k vy ešení na druhou úrove podpory. Ve druhé fázi analýzy v projektu (7 dní) jsme využili informa ní systém Incident Management Console, který zobrazuje status každého incidentu. Ve výsledném reportu jsem pak díky funkcionalitám programu Excel m la možnost vybrat incidenty podle jejich statusu. Pilotní projekt (3 dny) Z tabulky obsahující všechna data pilotního projektu byly vybrány ty incidenty, které nebyly vy ešeny na první úrovni podpory. Z celkového po tu (29) bylo 24 incident (tj. 82,6 %) vy ešeno p i prvním zavolání, zbylé ty i incidenty byly odeslány na druhou úrove podpory. Byly zaznamenány incidenty p edané na druhý nebo dokonce i t etí úrove podpory (17,4 %). Nej ast jší typ incidentu, který agent musí eskalovat na ešitelský tým, jsou chyby v aplikaci. První úrove podpory nemá možnost provést v aplikaci jakékoliv zm ny, což v rámci edepsaných proces potvrzuje i znalostní databáze. V jednom okamžiku došlo k situaci (incident. 25), kdy žádný z agent nem l p ístup k aplikaci SPS. Klient pot eboval zm nit heslo pro p ístup do aplikace. Incident musel být k vy ešení p edán druhé úrovni podpory, a koli agent helpdesku by za normálních okolností mohl incident vy ešit. Graf. 4 p edstavuje procentuální úsp šnost ešení incident podle jejich úrovn. Graf 4. Procentuální úsp šnost ešení incident podle jejich úrovn (projekt 3 dny). Zdroj: vlastní zpracování. 36

36 Tabulka 4. Procentuální úsp šnost ešení incident podle jejich úrovn (projekt 3 dny). Not FCR 17,4 % FCR 82,6 % Zdroj: vlastní zpracování. Projekt (7 dní) ehled o po tu FCR (First Call Resolved), tedy hovor vy ešených na první úrovni podpory, podává následující tabulka. Byla vytvo ena na základ analýzy dat (více p íloha.1). V tabulce m žeme vid t všechny statusy incidentu. Status je aktuálním stavem ticketu, podle kterého vidíme, co se s ticketem práv d je. Tabulka 5. Úrove vy ešení incidentu (projekt 7 dní). Status Status Reason Po et incident Assigned Assigned 47 Pending Pending Original Incident 51 Pending Monitoring Incident 25 Pending Client Action Required 24 Pending CSC Vendor Action Required 19 Pending Client Hold 6 Resolved First Call Resolved 1045 Resolved No Further Action Required 110 Resolved Resolved by Original Incident 35 Resolved Service Request Completed 131 In Progress In Progress 18 Celkem: 1511 Zdroj: vlastní zpracování. 37

37 Existuje jedenáct typ r zných status incident : Assigned a In Progress se používá v p ípad, že na ešení aktuáln pracuje jeden z ešitelských tým. Pending Original Incident a Resolved by Original Incident: b hem provozu helpdesku m že dojít k výpadku systému, aplikace nebo serveru a k jiným poruchám ovliv ujícím více zákazník. V co nejkratším ase musí být vytvo en tzv. master incident. Agent helpdesku p i zalogování incidentu používá status Pending Original Incident pro všechny incidenty, které souvisejí s master incidentem. Monitoring incident a Client Hold se používá p i aktuální práci s incidentem, nap. v okamžiku, kdy byl incident ešitelskému týmu p azen a jeho lenové práv zkoumají informace v n m obsažené a p edchozí akce, které byly vykonány pro jeho vy ešení. Client Action Required se používá v p ípad, kdy ekáme na reakci zákazníka. žeme od n j pot ebovat další informace a tento status používáme práv i neúsp šném pokusu o jeho kontaktování. CSC Vendor Action Required znamená, že práce je vyžadována na stran spole nosti CSC a v tomto okamžiku ešitelský tým pracuje na vy ešení incidentu. First Call Resolved je statusem, který se používá p i vy ešení incidentu agentem na první úrovni podpory. No Further Action Required se zvolí ve chvíli, kdy je incident vy ešen a není vyžadována jakákoliv další akce. Service Request Completed: existují incidenty v podob požadavku k vykonání jaké práce, nap. k získání dat ze serveru nebo obnovení náhodn vymazaného ležitého u. V tomto p ípad se tento incident liší od incidentu zalogovaného jako obnovení nefungujícího systému (Service Restoration). Po et incident s konkrétním statusem znázor uje následující graf. 38

38 Graf 5. Úrove vy ešení incidentu (projekt 7 dní). Zdroj: vlastní zpracování. Pro zjišt ní, zda byly dodrženy podmínky smlouvy poskytování podpory SLA2, byly spo ítány všechny incidenty, které nebyly vy ešeny na první úrovni podpory, ale pat ily do FCR. Status každého incidentu byl p edstaven v p íloze.1. Byly vytvo eny souhrny podle statusu incident. Other (Jiné incidenty)=pending Original Incident+Resolved by Original Incident+Service Request Completed Tabulka 6. Úrove vy ešení incident (projekt 7 dní). Úrove vy ešení Po et incident Úsp šnost v % FCR (First Call Resolution) ,50 Not FCR ,50 Other (Jiné incidenty) 217 Zdroj: vlastní zpracování. Graf 6. Úrove vy ešení incident (projekt 7 dní). Zdroj: vlastní zpracování. 39

39 hem zkoumaného období jsme koncem týdne zaznamenali 83,5 % ticket se statusem FCR. Kritérium hodnocení úrovn vy ešení incidentu byl spln n. B hem tohoto týdne došlo k interním posun m ve spole nosti. N kte í agenti pracující na pozici agenta helpdesku odešli na druhou úrove podpory nebo do jiného odd lení. Tak se na za átku týdne potýkal tým s nedostatkem technicky zdatného personálu. Výsledky pilotního projektu (82,6 %) i samotného projektu (83,5 %) co do po tu FCR status jsou velice podobné, nepatrn lepší výsledky ukazuje analýza b hem 7 dní. Z mého pohledu je to spojeno s tím, že agent, který zaznamenával incidenty v pilotním projektu, pracuje ve spole nosti delší dobu. Agenti, kte í mají více zkušeností, pracují na ešení obtížn jších incident Ticket accuracy (Popis incidentu) SLA 3 SLA 3 p edstavuje informaci o tom, zda agent první úrovn podpory správn popsal incident v ticketu a zda jsou informace dostate né pro jeho vy ešení. Podle smlouvy se zákazníkem musí být 95 % všech p íchozích požadavk správn popsáno. Projekt (7 dní) Statistika o SLA3 je obvykle zpracována statistickým týmem. P i tvorb reportu nemáme z dispozici informace o tom, jestli byl incident popsán dob e nebo špatn. Pro sestavení chto statistik jsem zpracovala 1511 incident a na základ informací obsažených v polích Summary (stru ný popis) a Notes (rozší ený popis) subjektivn za adila incidenty do kategorií dob e a špatn popsaných. V následující tabulce je p estaven p íklad analýzy kritéria popis incidentu. Obrázek 15. Kritérium Popis incidentu dob e popsaný incident. Zdroj: vlastní zpracování. 40

40 Nej ast ji se vyskytující chybou je neuvedení atributu KTZ (název dokumentu ve znalostní databázi). Níže je uveden p íklad špatn popsaného incidentu. Obrázek 16. Kritérium Popis incidentu špatn popsaný incident. Zdroj: vlastní zpracování. tšinou jsou pro popis incidentu používány šablony (tzv. template), kde je zobrazena pot ebná informace pro vy ešení incidentu. Základní template používaná p i popisu incidentu obsahuje následující položky: USER ID/uživatelské jméno, LOCATION/BUSINESS/umíst ní, PHONE NUMBER/telefon, ADDRESS/ ová adresa, PREFERRED LANGUAGE/jazyk, DESCRIPTION OF INCIDENT/popis incidentu, NO OF USERS AFFECTED/po et zákazník, TROUBLESHOOTING STEPS/odstra ování problém, KNOWLEDGE DOCUMENT USED/znalostní báze, ASSET NUMBER/ íslo PC, BOMGAR ATTEMPTED Y/N (if no state why not)/p ipojení k po íta i, RESOLUTION/ ešení. Výsledek analýzy kritéria Popis incidentu popisuje následující tabulka. Tabulka 7. Kritérium Popis incidentu projekt 7 dní. Ticket accuracy (Popis incidentu) Po et incident Procento incident Špatn popsané incidenty 50 3,2 % Dob e popsané incidenty ,8 % Zdroj: vlastní zpracování. 41

41 hem zkoumaného m síce agenti dodržovali p esnost popsání incidentu. Dané kritérium tak bylo spln no na úrovni 96,8 %. Chybovali zpravidla noví agenti. B hem školení by m l být na správný popis incidentu kladen velký d raz. Podle mého názoru je to první d ležitý aspekt práce, na který se agent musí zam it. Procesy ešení incidentu se ob as m ní, a proto je hodn ležité obracet se p i tom pokaždé na znalostní databázi. Graf 7. Popis incidentu SLA 3. Popis incident Bad Good Zdroj: vlastní zpracování. Pilotní projekt (3 dny) V dob provád ní projektu pilotní analýzy (3 dny) agenti správn popsali všechny incidenty, pro jejichž vy ešení byla použita znalostní databáze, tedy ty, které se poda ilo vy ešit ihned, a také ty, které musely být poslány na ešitelský tým. Kritérium hodnocení Popis incidentu bylo spln no na úrovni 100 % Escalation (Eskalace) SLA 4 V p ípad nespokojenosti s poskytovanými službami má klient kontakt na vedoucího týmu, se kterým eší konkrétní incident. Informace o pln ní tohoto kritéria bohužel není k dispozici agent m helpdesku. 42

42 3.4.5 Pr rný as na vy ešení incidentu SLA 5 Pr rný as k vy ešení problému se pohybuje v rozmezí mezi ty mi až osmi hodinami podle konkrétní pozice klienta (m že to být vetší i menší pracovišt ). Bohužel ani tato informace není k dispozici agent m helpdesku Customer Satisfaction (Spokojenost zákazníka) SLA 6 Projekt (7 dní) Spokojenost zákazníka s poskytovanými službami byla za vybrané asové období analyzována v projektu trvajícím 7 dní. Obdrželi jsme pozitivní i negativní hodnocení agent. ístup k dat m o spokojenosti zákazníka má každý agent k dispozici, aby mohl zlepšit vlastní komunikaci se zákazníkem. Po vy ešení incidentu obdrží zákazník s dotazníkem, ve kterém má možnost své pr h ešení incidentu zhodnotit a své hodnocení také zd vodnit. Z vlastní zkušenosti mohu íci, že pokud klient na dotazník neodpoví, je velmi d ležité mu žádost o odpov p ipomenout. Pak má agent v tší šanci získat pozitivní hodnocení za poskytnutou službu. Nespokojenost klienta m že asto nastat v p ípad, kdy je as pro vy ešení incidentu klienta delší, než je obecný pr r pro daný typ požadavku (zejména u zm ny hesla nebo instalace). Jako prevence negativní zkušenosti zákazníka je vhodné se jej p ímo zeptat, zda má agent k ešení dostatek asu. Pracujeli nap íklad klient z domova a nemá k dispozici vysokorychlostní internet, instalace m že trvat delší dobu. V tom p ípad je dobré se u klienta ujistit, zdá má k ešení incidentu dostatek asu. íklad negativní zkušenosti zákazníka: While the person who took my call was polite and helpful, the whole process took far too long and it was very frustrating waiting as I didn't expect this. I was told that the request which my business services colleague had set up on IT Direct was for application access and not access to the G Drive - this was not true. I had collegue check her confirmation of the request and there was no mention of application. I had to forward a copy of this but was still told it was for application access. While I am satisfied that I now have an access, it took far too long ( ). Zdroj:citováno z firemní databáze 43