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

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

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

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.

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 .

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.

OBSAH Úvod ...................................................................................................................................................... 9 Teoretická ást.................................................................................................................................... 10 1

Popis spole nosti ................................................................................................................... 10

2

Úvod do problematiky helpdesku ......................................................................................... 11 2.1

Definice pojm .......................................................................................................... 12

2.2

Fungování helpdesku ................................................................................................ 14

2.3

Klí ové role z pohledu agenta helpdesku ................................................................ 17

2.4

Nástroje helpdesku .................................................................................................... 19

Analytická ást ................................................................................................................................... 23 3

Analýza zpracování incidentu za vybrané asové období................................................... 23 3.1

Diagram aktivit .......................................................................................................... 23

3.2

Popis projektu ............................................................................................................ 26

3.3

Kritéria pro hodnocení helpdesk ............................................................................ 34

3.4

Analýza vybraných kritérií ....................................................................................... 35 3.4.1 Speed of answer (rychlost p ijetí hovoru) – SLA1 ..................................... 35 3.4.2 First Call Resollution (Úrove vy ešení incidentu) – SLA 2..................... 36 3.4.3 Ticket accuracy (Popis incidentu) – SLA 3 ................................................ 40 3.4.4 Eskalace – SLA 4.......................................................................................... 42 3.4.5 Pr

rný as na vy ešení incidentu – SLA 5 ............................................. 43

3.4.6 Customer Satisfaction (Spokojenost zákazníka) – SLA 6 ......................... 43 3.4.7 Incident type (Typ incidentu) - vlastní kritérium hodnocení ..................... 44

3.4.8

Call duration (Délka trvání hovoru) - vlastní kritérium hodnocení........... 48

3.4.9 Knowledge Tool usage (Použití znalostní databáze) – vlastní kritérium hodnocení ...................................................................................................... 50 3.5

Dotazník ..................................................................................................................... 53

3.6

Výsledky analýzy ...................................................................................................... 56

3.7

Slabé stránky helpdesku............................................................................................ 59

Záv r ................................................................................................................................................... 62 Literatura............................................................................................................................................. 65 Seznam tabulek................................................................................................................................... 68 Seznam obrázk ................................................................................................................................. 69 Seznam graf ...................................................................................................................................... 70 Seznam p íloh ..................................................................................................................................... 71

Ú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

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: www.csc.com.

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

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 20 000. Na ITIL se dá certifikovat pracovníky helpdesku, ale ne organizaci samotnou.

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

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í, e-mailová 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

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

Italský tým

Švýcarský tým (40)

ina

Angli tina

Italština

Španelský tým

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 e-mailovém systému Lotus Notes a p ípadn konkrétními požadavky ze strany klienta.

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


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 6.-21. 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 .

120 100 80 60 40 20 0 06:0009:00

9:0012:00

12:0014:00

14:0016:00

16:0018:00

18:00- 20:0020:00 06:00


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

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. 350 300 250 200

UK L

150

UK G

100 50 0

Pond lí Úterý St eda tvrtek Pátek Sobota Ned le


Graf 3. Po ty agent podle dn v týdnu.

40 30 20 10 0 Pond lí Úterý St eda tvrtek Pátek Sobota Ned le


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

E-mailový tým

První úrove podpory

Vedoucí týmu UK

Zástupce vedoucího

Agenti

Agenti

Remote control


Lotus Notes

Agenti

Vedoucí týmu ŠP a IT

Idadmin


Vedoucí týmu CH

Druhá úrove podpory


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

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.) E-mailový tým (E-mail 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. E-mailový tým má konkrétn vymezené asové období pro reakci na požadavek od klienta, který byl zadán prost ednictvím e-mailu nebo online systému.

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

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

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, e-mailovou 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

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 260 000 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

Analytická ást 3 3.1

Analýza zpracování incidentu za vybrané asové období 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 e-mailový 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. E-mailový 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 e-mailová 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

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 summary stru

v kolonce ticket

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, e-mailová 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

Obrázek 10. Business proces model komunikace v helpdesku.


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í

Pilotní projekt (3 dny)

Projekt (7 dní)

Dotazník

1

Rychlost p ijetí hovoru (Speed of answer) SLA1

ano

2

Úrove vy ešení incidentu (First Call resolution) SLA2

3

Popis incidentu (Ticket accuracy) SLA3

ano

4

Spokojenost zákazníka (Customer satisfaction) SLA6

ano

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

ano

ano


26

Pilotní projekt (3 dny) Incidenty p ijaté od klient byly zpracovány za vybrané asové období od 29. 3. 2012 do 31. 3. 2012 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 (29. 3. 2012) do helpdesku p icházelo více požadavk než nap íklad v sobotu (31. 3. 2012). 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

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/2012

12: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/2012

11: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

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/2012

12: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/2012

11: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/2012

11: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/2012

11: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

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:44 0121 6978846 Location:ZFS GBR-Birmingham126 Hagley Road case issue was resolved for the user.

First Call Resolved

1 level support

0:05:34

3/29/2012

3/29/2012

12: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/2012

12: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/2012

11: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/2012

11:28:25

11:32:21

23

KTZ 7452 checking the reques access shared mailbox

User called with a ticket number EUINC160089491, 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/2012

11:21:03

11:24:13

24

Wrong number

Wrong number

First Call Resolved

1 level support

0:02:01

3/29/2012

3/29/2012

11: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/2012

30

Assigned

3 level support UKCapita Cheltenham Support

3/30/2012

12:32:40

Assigned

3level support GSSC-BIAPP-ZIGMI

3/30/2012

11:41:40

3/29/2012

6:14:35

3/29/2012

4:11:00

26

KTZ 4971 instant letters 2 error

User is working with a specificy policy on instant letters 2 number:04612313 Application error.

27

KTZ 9377 reports 26.03 not loaded

Invested files from 26.03 are not loaded, no reported are showing, these files (reports) are loaded weekly. APPLICATION:ZIG MI

28

CAD05/04@16:00G MT KTZ 5916 megger Power proff isssue

User is Megger PowerSuite Professinal application which should generate the reports to LN report, the user created is appearing in the different location.

Assigned

2 level of support Service DeskPrague-UK Remote

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 UKWIPROCEC


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

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

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). Duration/Target Critical service levels/Kritické úrovn poskytování podpory

Expected/o ekávaná hodnota

Minimum/minimální hodnota

Time

%

Time

%

30 sec.

80

30

75

SLA1

Speed of Answer/Rychlost p ijetí hovoru

SLA2

First Call Resolution/Úrove vy ešení incidentu

80

75

SLA3

Ticket accuracy/Popis incidentu

95

90

SLA4

Escalations/Notifications

SLA5

Incident resolution/Vy ešení incidentu

SLA6

5 min.

95

10 min.

95

Large facility/Velký objekt

4 hod.

95

6 hod.

95

Small facility/Malý objekt

8 hod.

95

12 hod.

95

Customer satisfaction/Spokojenost zákazníka

95

85

Zdroj: CSC.

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.

3.4.1

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

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 úrove

p edaných k vy ešení na druhou

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).


36

Tabulka 4. Procentuální úsp šnost ešení incident podle jejich úrovn (projekt 3 dny). Not FCR

17,4 %

FCR

82,6 %


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

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

Resolved

First Call Resolved

Resolved

No Further Action Required

Resolved

Resolved by Original Incident

Resolved

Service Request Completed

In Progress

In Progress

Celkem:

Po et incident

6 1045 110 35 131 18 1511


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 e-mailu. 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

Graf 5. Úrove vy ešení incidentu (projekt 7 dní).


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)

1045

83,50

Not FCR Other (Jiné incidenty)

249 217

16,50


Graf 6. Úrove vy ešení incident (projekt 7 dní).


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 .

3.4.3

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.


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.


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, EMAIL ADDRESS/e-mailová 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

1495

96,8 %


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


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 %.

3.4.4

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

3.4.5

Pr Pr

rný as na vy ešení incidentu – SLA 5 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.

3.4.6

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 e-mail 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 email 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“ (22. 10 .2012). Zdroj:citováno z firemní databáze 43

V p ípad negativní zp tné vazby od zákazníka je úkolem vedoucího nebo jeho zástupce kontaktovat zákazníka znovu. M že nastat i situace, kdy zákazník pošle e-mail nebo dojde k jakémukoliv nedorozum ní. Reakce vedoucího týmu pak m že vypadat následovn : „The user is not satisfied due to the fact that it took too long to resolve the problem. She had no issues with the person who took her call, but the request for the network drive was sent and approved, a colleague got the confirmation and then she was told that the request was for application access when it was not. The user does not know where they got that from, because her colleague had the confirmation for the correct drive which was not application. So why the confusion?“ (23. 10. 2012) Zdroj:citováno z firemní databáze

íklad pozitivní zkušenosti zákazníka: „Very satisfied. I am happy with the way and manner the issue was resolved. It was really propmt.“ (22. 10. 2012) Zdroj:citováno z firemní databáze „Satisfied – Polite, helpful, efficient and resolved first time. Thanks – on this occasion you did a good job.“ (25. 10. 2012) Zdroj:citováno z firemní databáze

hem zkoumaného asového okamžiku bylo kritérium spokojenosti zákazníka spln no. UK tým dosáhl 92,5 % p i minimáln požadované úrovni 90 %. Tato data jsem získala z report týmu kontrolujícího kvalitu poskytovaných služeb. Z mého pohledu je to docela dobrý výsledek, protože v týmu p ibylo hodn nových agent , kte í nemají zkušenosti se všemi druhy incident .

3.4.7

Incident type (Typ incidentu) - vlastní kritérium hodnocení Typem incidentu rozumíme druh požadavku, s jakým se klient se obrátil na helpdesk.

Nej ast jšími typy incident jsou: zm na hesla pro r zné systémy, hardware incidenty, potíže s internetovým p ipojením, kontrola stavu požadavku, instalace aplikace, p ípady, kdy je incident vy ešen bez spolupráce s klientem, a také chyby v komunikaci. Popíšeme každý z výše zmín ných typ incident :

44

Zm na hesla Zákazník zavolá s požadavkem o zm nu hesla. Pomocí bezpe nostních otázek (security questions), které byly d íve stanoveny pro komunikaci s helpdeskem, ov íme jeho totožnost. Po správné odpov di na otázky m že agent klientovi zm nit heslo. Obrázek 17. Ov ení totožnosti zákazníka - security questions.

Zdroj: CSC firemní databáze

Hardware K danému typu incidentu pat í problémy spojené s poruchou po íta , monitoru, klávesnice, myši, tiskárny apod. Agent první úrovn podpory se pokouší problém vy ešit, pokud se to nepoda í, p edá incident inženýrovi, který z d vodu jeho vy ešení p ijde na pracovišt zákazníka. Internetové p ipojení Zákazník se na helpdesk obrací s potížemi s p ipojením k internetu. Agent musí d kladn a srozumiteln popsat kroky pro vy ešení incidentu. V tomto typu incidentu velmi zaleží na úrovni IT znalostí zákazníka. Kontrola stavu požadavku Pro p ístup k r zným aplikacím zákazník vytvo í požadavek, ud lení p ístupu pak trvá dva až t i dny. Ob as m že tento proces trvat déle a zákazník volá na helpdesk pro ov ení statusu svých požadavk . Instalace Ob as se vyskytne n jaká chyba p i instalaci aplikace. Tento incident má vy ešit agent první úrovn

podpory (v tšinou menší aplika ní balí ky) nebo Remote tým (v tší

aplika ní balí ky). Chyba v aplikacích Z popisu incidentu zákazníkem je z ejmé, že došlo k chyb

v aplikaci. Tento typ

problému se p edává ešitelskému týmu, který se stará o aplika ní podporu. 45

Chyby v komunikaci Incident vy ešen bez podpory agenta. Zákazník m že mít potíže s p ipojením k internetu, ale ve chvíli, kdy se dovolá na helpdesk, m že se problém vy ešit sám. Pod komunika ními chybami rozumíme nap íklad situaci, kdy zákazník volá na nesprávné íslo, agent a zákazník byli odpojeni v pr

hu hovoru apod.

Nepodporovaný incident

Projekt (3 dny) V pilotním projektu se nej ast ji objevoval incident, p i kterém klient žádal zm nu hesla. Z celkového po tu dvaceti devíti se jich sedm týkalo hesel v r zných aplikacích používaných klientem. Je d ležité zajistit všem agent m p ístup ke konkrétní aplikaci. Zm na hesel je jedním z nejsnáz vy ešitelných typ incident a agent helpdesku by s ním nem l mít problémy. Druhým nej ast jším typem incidentu, které agenti musí ešit, je requets checking (kontrola stavu objednávky). Ten už je obtížn jší – agent na první úrovni podpory musí kontaktovat agenta na druhé úrovni, aby byla informace o stavu objednávky poskytnuta. Out of scope znamená, že helpdesk neposkytuje podporu pro vy ešení incidentu klienta. Agent ale musí poskytnout informace ešiteli incidentu. Nicmén out of score se v sou asnosti ve spole nosti CSC tém nevyskytuje. V tabulce . 8 a na grafu 7 je nastín na etnost jednotlivých typ požadavk klient , které musí helpdesk zpracovat, uvedena jsou v procentech a po tech výskytu. Tabulka 8. etnost jednotlivých typ incident - projekt 3 dny. Typ incidentu

Po et

Zm na hesla

7

Kontrola stavu požadavku

5

Chyby v komunikaci

4

Chyba v aplikacích

4

Hardware

3

Internetové p ipojení

2

Instalace

2

Nepodporované incidenty

1

Zdroj: vlastní zpracování..

46

Graf 8. Procentuální výskyt jednotlivých typ incident - projekt 3 dny.


Projekt (7 dní) i provád ní sedmidenní analýzy byl hodnocen každý incident, který byl za azen do konkrétní kategorie. Podle notes a summary bylo zpracováno 1511 incident a do tabulky v priloze .1 (také obrázek . 18), která je k dispozici v p íloze této práce, byl dopl ován typ incidentu. Obrázek 18. Tvorba typ incident pro sedmidenní projekt.


Nejv tší po et incident

byl zaznamenán p i zm

hesla. Pak následují chyby

v aplikacích, potíže s hardwarem nebo internetovým p ipojením. Výskyt požadavk podle typu incidentu v sedmidenním projektu ukazuje tabulka . 9.

47

Tabulka 9. Po ty požadavk podle typu incidentu - sedmidenní projekt. Typ incidentu

Po et požadavk

1) Zm na hesla

640

2) Chyby v aplikacích

480

3) Hardware

163

4) Internetové p ipojení

93

5) Instalace

68

6) Kontrola stavu požadavku

61

7) Chyby v komunikaci

42

8) Nepodporované incidenty

1


Z hlediska kritéria SLA 6 se výsledky analýzy v jednotlivých projektech áste

liší.

Zm na hesla je nej ast jším typem incidentu jak v pilotním (3 dny), tak i v sedmidenním projektu. U druhého nej ast ji se vyskytujícího incidentu už najdeme odlišnosti: zatímco v pilotním projektu je to kontrola stavu požadavku, v sedmidenním projektu se jedná o chyby v aplikacích. Rozdíl ve výsledcích mohl být podle mého názoru zp sobený nedostatkem agent druhé úrovn podpory (IDAD tým), kte í p id lují p ístup k aplikaci na základ zákaznického požadavku.

3.4.8

Call duration (Délka trvání hovoru) - vlastní kritérium hodnocení

Projekt (3 dny) i pilotním projektu byly všechny incidenty hodnoceny podle jejich typu incidentu a pak podle pr

rné délky trvání hovoru (viz tabulka . 10 a graf . 9 na následujících stranách).

48

Tabulka 10. Pr Typ incudentu

rná délka trvání hovoru - pilotní projekt. Pr rná délka trvání hovoru

Vysv tlení

1) Zm na hesla

0:07:39

Hovor je podpr

rný. Zm na hesla probíhá rychle.

3) Hardware

0:14:18

Pr rný hovor. Požaduje p ipojení k po íta i klienta. Ov ení procesu ve znalostní databázi.

4) Internetové ipojení

0:27:22

Nadpr rný hovor. Nejtišší incident. V tšinou chybí internetové ipojení a agent musí slovn popsat klientovi postupy, jak vy ešit incident. Hlavn záleží na IT znalostech klienta.

5) Kontrola stavu požadavku

0:07:01

Podpr rný hovor. Agent poskytuje status požadavk . Záleží na rychlosti interní spolupráce mezi první a druhou úrovní podpory.

6) Instalace

0:20:36

Nadpr rný hovor. Záleží na rychlosti interní spolupráce mezi první a druhou úrovní podpory a také na rychlosti internetu ze strany klienta v p ípad , že se jedná o instalaci aplikace.

7) Incident je vy ešen bez podpory, chyby v komunikaci

0:09:25

Podpr rný hovor. V tšinou se stává, že n jaký server je b hem kolika minut nedostupný, což vyvolá požadavek klienta. Než se agent helpdesku p ipojí k po íta i klienta, server už zpravidla zase funguje.

8) Nepodporované incidenty

0:10:59

Pr rný hovor. V tšinou se jedná o zjišt ní, zda podporujeme aplikace nebo ne, i poskytování kontaktu, na který se klient m že obrátit.

Pr rná doba hovoru

0:13:54


49

Graf 9. Procentuální znázorn ní doby trvání hovoru v rámci pilotního projektu.

Pr

rná délka trvání hovoru 1) Kontrola stavu požadavku 2) Zm na hesla 3) Incident je vy ešen bez podpory, chyby v komunikaci 4) Nepodporované incidenty 5) Hardware 6) Instalace 7) Internetové p ipojení


Projekt (7 dní) Pr

rná délka trvání jednoho hovoru, pokud zpr

rujeme výkon všech agent v rámci

sedmidenního projektu, je 0:17:02. K tomuto výsledku jsem došla použitím nezbytných funkcí v nástroji Microsoft Excel (average - pr v pilotním projektu je podpr

r). Celková pr

rná doba na jeden hovor u agenta

rná, tj. 13 minut. Podle mého názoru je to spojeno s tím, že agent

pracuje na dané pozici už delší dobu a má v tší zkušenosti s ešením incident . Rozdíl v tomto ukazateli mezi projektem trvajícím 7 dní a pilotním projektem jsou 4 minuty (0:17 - 0:13 = 0:04), což považuji za docela velký rozdíl. Noví agenti pot ebují být lépe vyškoleni, aby mohli do budoucna ešit incidenty v kratší dob .

3.4.9

Knowledge Tool usage (Použití znalostní databáze) – vlastní kritérium hodnocení

Projekt (3 dny)

50

Kritérium hodnocení „Použití znalostní databáze“ bylo analyzováno jenom v pilotním projektu. Cht la jsem tím potvrdit, nebo vyvrátit nutnost použití znalostní báze. P edepsaným procesem je pro agenta helpdesku použití znalostní databáze. Když je p ijat požadavek od klienta na zm nu hesla pro aplikace ESS (employee self service – zm na hesla), do vyhledáva e agent zadá vyraz: ESS password reset. V praxi se ale znalostní databáze ne vždy použije. Existují incidenty, jejichž postup ešení si agent pamatuje. V tabulce . 11 a grafu . 10 je znázorn no, v kolika procentech p ípad se znalostní databáze používá a v kolika se bez ní agenti obejdou. Graf 10. Procento použití znalostní databáze v pilotním projektu.

Zdroj: vlastní zpracování. Tabulka 11. Použití znalostní databáze v rámci pilotního projektu. Použití znalostní databáze 1) Zm na hesla

Procento použití 3,4 %

Vysv tlení v závislosti na typu incidentu S v tším po tem p ijatých incident si agent pamatuje postup zm ny hesla. Ale vyskytují se aplikace, se kterými agent helpdesku zkušenost nemá. P íkladem m že být incident 25.

100,0 %

Když dojde k chyb v aplikaci, agent helpdesku skoro vždy použije znalostní databázi. Aplika ní chyby se hodn liší, pro jednu aplikaci m že existovat více ešitelských tým . P íkladem jsou incidenty 26-29.

3) Hardware

33,0 %

Klient používá adu r zných hardwar . Nap íklad p i instalaci tiskárny agentem se projeví odlišnosti ve zna ce hardwaru. P i nastavení monitoru vyhledáváme informace ve znalostní databázi, abychom nastavili specifické možnosti monitoru (incident 13).

4) Internetové ipojení

0,0 %

V praxi si agent pamatuje postup ov ování chyb v internetovém ipojení. Není tomu tak ale vždy, agent m že na n co zapomenout. Proto

2) Chyba v aplikaci

51

je doporu eno projít procesem pro vy ešení incidentu ve znalostní databázi krok za krokem. V tomto konkrétním p ípad agent znalostní databázi nepoužil. 5) Kontrola stavu požadavku

6) Instalace

0,0 %

100,0 %

7) Incident je vy ešen bez podpory agenta, chyby v komunikaci 8) Nepodporované incidenty

Kontrola stavu požadavk probíhá p i komunikaci s druhou úrovní podpory. Znalostní databáze se nepoužije. Agent ov uje, zda tuto aplikaci m že nainstalovat s týmem, který se zabývá instalacemi. Jedná se o p íklad kontaktování druhé úrovn podpory. Znalostní databáze se nepoužije.

0,0 %

Chyby v komunikaci ze strany klienta. Klient vy ešil incident samostatn .

100,0 %

Ve znalostní databázi je t eba ov it, zda opravdu nem žeme poskytnout klientovi n jakou pomoc. Vyhledáme kontakt a poskytneme jej klientovi.


Ve t ech typech incident z osmi znalostní báze použita nebyla. V n kterých p ípadech bylo využití znalostní báze pouze na nízké úrovni (nap . zm na hesla 3,4 %, chyba v aplikaci 33 %).

52

3.5

Dotazník Pro porovnání výsledku analýzy podle vybraných kritérií byl pro agenty první úrovn

podpory navržen dotazník. „Dotazníky slouží ke zjiš ování informací v populaci nebo i v n jaké menší skupin osob. Na jejich základ dochází k vyhodnocování ur itých skute ností (názor , postoj , preferencí) a orientaci dalších krok .“ [6] Dotazník se zam uje na to, ve kterých oblastech agenti pot ebují dodate ný as na školení, a na základ n j budeme také porovnávat výsledky analýzy pilotního projektu (3 dny) a projektu (7 dní).

Dotazník pro agenty podpory první úrovn Jméno, p íjmení/Datum nástupu: 1. Se kterými druhy incident pracujete nejvíce?

Tabulka 12. Výskyt typ incident z pohledu agenta první úrovn podpory (dotazník). Druh incidentu/Type of incident

Hodn asto

Pr

r

Málo

Zm na hesla/Password reset

29

4

2

Internetové p ipojení/Internet connection

15

15

5

Kontrola stavu požadavku/Request check

7

24

4

Chyby v aplikacích/Application error

7

20

8

Hardware/Hardware

5

10

20

Instalace/Installation

5

10

20

Incident vy ešen bez podpory agenta, chyby v komunikaci/Self resolved issue

5

10

20

Zdroj: vlastní analýza.

53

Graf 11. Výskyt typ incident z pohledu agenta první úrovn podpory (dotazník).


2. Kolik minut vám p ibližn zabere vy ešení níže uvedených druh incident ? V následující tabulce již p edkládáme pr z pr

rné hodnoty (v minutách) vypo ítané

ru odpov dí dotazovaných agent .

Tabulka 13. Délka trvání hovoru z pohledu agenta (dotazník). Druh incidentu/Type of incident

Pr

rný as (minuty)

Internetové p ipojení/Internet connection

15,0

Instalace/Installation

15,0

Kontrola stavu požadavku/Request check

10,0

Chyba v aplikacích/Applikation error

7,0

Hardware/Hardware

5,0

Zm na hesla/Password reset

4,0

Incident vy ešen bez podpory agenta, chyby v komunikaci/Self resolved issue/out of scope

3,0

Pr

8,4

r celkem:


54

Graf 12. Výskyt typ incident z pohledu agenta první úrovn podpory (dotazník).

. Zdroj: vlastní analýza.

Výsledky dotazníku Z 40 agent helpdesku jich na dotazník odpov

lo 35. Dotazník jim byl p edložen

v papírové podob . Po prozkoumání odpov dí dotazovaných je z ejmé, že s nejv tšími potížemi se setkávají p i ešení problém spojených s internetovým p ipojením. Výsledky také vypovídají o tom, že agenti cítí pot ebu dále se školit v oblasti Lotus Notes (chyby v aplikacích). Jako interní proces ve spole nosti CSC by m la být vylepšena komunikace mezi první a druhou úrovní podpory, a to konkrétn p i kontrole stavu požadavk . Agent první úrovn musí obvykle ekat delší dobu, než pot ebnou informaci od druhé úrovn podpory získá. Podle agent Pom rn

první úrovn

podpory je nej ast jším typem incidentu zm na hesla.

asto se s tímto typem incidentu potýká 29 z 35 agent . Nejmén se naopak vyskytují

nepodporované incidenty (out of scope) nebo incidenty vy ešené bez podpory agenta. Podle názoru dotazovaných agent je pr

rná délka trvání hovoru 8 minut.

55

3.6

Výsledky analýzy Z výsledk analýzy vybraných kritérií, které jsou uvedeny v tabulce . 14, vyplývá, že

všechny SLA (Service Level Agreement) byly dodrženy.

Tabulka 14. Výsledky analýzy. .

Pilotní projekt (3 dny)

Kritérium hodnocení

1

Rychlost p ijetí hovoru (Speed of answer) - SLA 1

2

Úrove vy ešení incidentu (First Call resolution) - SLA 2

3

Popis incidentu (Ticket accuracy) – SLA 3

4

Typ incidentu (Type of incident) - vlastní návrh

5

Délka trvání hovoru (Duration of call) - vlastní návrh

6

Použití znalostní báze (Knowledge tool usage) - vlastní návrh

7

Spokojenost zákazníka (Customer satisfaction) – SLA 6

Projekt (7 dní)

Dotazník

84,3 % 82,6 %

83,5 % 96,8 %

analyzován

analyzován

analyzován

13 minut

17 minut

8 minut

100 %

96,8 % 92,5 %


Rychlost p ijetí hovoru (Speed of answer) – SLA 1 Podle smlouvy SLA musí být 80 % p íchozích hovor

p ijato do 30 sekund. Toto

kritérium bylo hodnoceno v pilotním projektu. Data o rychlosti p ijetí hovoru byla p estavena statistickým tymem. Úrove vy ešení incidentu (First Call resolution) – SLA 2 Toto kritérium by m lo být na úrovni 80 %. Hodnoceno bylo v pilotním projektu (3 dny) i v projektu (7 dní). Podíváme-li se na výsledky pilotního projektu (procento FRC dosáhlo 82,6 %) a projektu (83,5 %), na první pohled se zdá, že se výsledky p íliš neliší. Výsledky analýzy trvající sedm dní jsou p esto lepší. Podle mého názoru je to dáno tím, že agent, který zaznamenával incidenty v pilotním projektu, pracuje ve spole nosti delší dobu. Více zkušený agent pak pracuje na ešení obtížn jších incident .

56

Popis incidentu (Ticket accuracy) – SLA 3 Celých 95 % ticket musí být vytvo ených a popsaných správn . B hem zkoumaného týdne agenti dodržovali p esnost popisu incidentu. Dané kritérium dosahovalo úrovn 96,8 %. V popisu incidentu chybovali zpravidla noví agenti. Na školení o správném popisování incident je kladen velký d raz. Podle mého názoru je to první d ležitou v cí, na kterou by se m l agent zam it. Procesy ešení incidentu se ob as m ní, a proto je p i tom velmi d ležité se pokaždé podívat do znalostní databáze. B hem pilotního projektu (3 dny) agent správn popsal incident, i vy ešení incidentu byla znalostní báze použita. Kritérium hodnocení bylo v rámci pilotního projektu (3 dny) na úrovni 100 %. Typ incidentu (Type of incident) - vlastní návrh Výsledky analýzy se v tomto kritériu lišily. Zm na hesla je nej ast jším typem incidentu jak v pilotním projektu (3 dny), tak i v projektu (7 dní). Dále se nej ast ji vyskytuje kontrola stavu požadavku (v pilotním projektu) a chyby v aplikacích (v projektu). Rozdíl ve výsledcích mohl být podle mého názoru zp soben nedostatkem agent na druhé úrovni podpory (IDAD tým), kte í p id lují p ístup k aplikaci na základ zákaznického požadavku. Podle agent z první úrovn podpory je nej ast jším typem incidentu zm na hesla. Velmi asto se s tímto typem incidentu potýká 29 z 35 agent . Nejmén se objevují nepodporované incidenty (out of scope) nebo incidenty vy ešené bez podpory agenta. Délka trvání hovoru (Duration of call) - vlastní návrh Pr

rná délka trvání jednoho hovoru všemi agenty je podle statistiky 17 minut

a 2 vte iny. Celková pr ozna it za podpr

rná doba na jeden hovor iní u jednoho agenta 13 minut, což lze

rnou hodnotu. Podle mého názoru je to dáno tím, že agent pracuje na dané

pozici už delší dobu a má s ešením incidentu v tší zkušenosti. Rozdíl mezi projektem a pilotním projektem (0:17 - 0:13 = 0:04) tvo í z hlediska tohoto kritéria 4 minuty, to lze považovat za pom rn velký rozdíl. Noví agenti pot ebují být lépe vyškoleni, aby mohli zákazníka rychleji uspokojit. i zpracování dotazníku se zjišt ní jím získané od výsledk p edchozí analýzy liší. Agenti pracující na první úrovni podpory p edpokládají, že vy ešení jednoho incidentu jim zabere v pr

ru asi 8 minut. Agent se ale m že domnívat, že se zákazníkem stráví telefonicky mén

57

asu, než tomu tak je ve skute nosti. Ov ování osoby volajícího, otev ení nového ticketu, ekání na otev ení jakékoliv aplikace – všechny tyto aktivity trvají n jakou dobu. Použití znalostní báze (Knowledge tool usage) - vlastní návrh Ve t ech z osmi typ incident nebyla použita znalostní báze, v jiných p ípadech je její využití na nízké úrovni (zm na hesla 3,4 %, chyba v aplikaci 33 %). Spokojenost zákazníka (Customer satisfaction) – SLA 6 hem zkoumaného asového okamžiku bylo spln no kritérium spokojenosti zákazníka. UK tým dosáhl hodnoty 92,5 % p i minimáln požadované úrovni 90 %. Tato data jsem získala z report vytvo ených týmem, který kontroluje kvalitu poskytovaných služeb. Z mého pohledu je to pom rn dobrý výsledek, protože v týmu pracuje hodn nových agent , kte í ješt nemají se všemi druhy incident zkušenosti. hem m síce zá í se UK tým skládal z 50 agent první úrovn podpory. Za átkem íjna se jejich po et snížil na 40. Interní posuny v organizaci ovlivnily n která kritéria hodnocení helpdesku. Zm ny se dotkly kritéria SLA 2, úrovn

vy ešení incidentu. Podle statistiky

z ervence, srpna a zá í dosahoval tým v kritériu SLA 2 lepší úrovn

(86,3 %, 87,1 %

a 86,2 %).V íjnu byly smluvní podmínky SLA 2 spln ny, ale kritérium hodnocení dosáhlo jen 83,5 %. Po prozkoumání výsledk

bylo navrženo dodate né školení agent

první úrovn

podpory. Vlastn vytvo ená kritéria hodnocení jako nap íklad typ incidentu, použití znalostní báze a délka trvání hovoru m že týmu posloužit p i sestavení školení pro nové agenty. Pot ebu dodate ného školení p itom vyjád ili i dotazovaní agenti.

58

3.7

Slabé stránky helpdesku Na základ provedené analýzy je možné mluvit o problémech, které se p i komunikaci

v helpdesku objevují. Níže budou stru

popsány.

1) Nedostate né vyškolení agenta helpdesku Každý lov k p ichází do helpdesku s ur itými znalostmi ve sfé e IT. Krom nich je ale také d ležitá komunikace se zákazníkem. Klient se na helpdesk obrací, protože pot ebuje pomoci vy ešit ur itý problém zpravidla v krátkém asovém okamžiku. Pro agenta je náro né klienta uklidnit a vést s ním dialog tak, aby p sobil dojmem, že potížím, které klienta trápí, rozumí. hem sedmidenního projektu do helpdesku nastoupili dva noví agenti. O tom, že nebyli dostate

vyškoleni, mluví výsledky analýzy – zejména kritérium úrove vy ešení incidentu.

Podle statistiky z ervence, srpna a zá í dosahovalo d íve kritérium SLA 2 mnohem vyšší úrovn (86,3 %, 87,1 % a 86,2 %).V íjnu sice smluvní podmínky SLA 2 spln ny byly, kritérium hodnocení ale bylo jen na úrovni 83,5 %. 2) Délka trvání hovoru Když klient zavolá na helpdesk, netuší, v em spo ívá problém, a nem že v

t, kolik

asu vy ešení incidentu zabere. V p ípad , že jde o instalaci nového balí ku, nap íklad obnovení verze Lotus Notes, bude agent pot ebovat více asu na jeho vy ešení. P edstavme si, že došlo k situaci, v níž zákazník po vy ešení incidentu pošle e-mail s negativním hodnocením helpdesku. vodem stížnosti je délka trvání hovoru. Z tohoto d vodu by m lo být všem novým agent m doporu eno zjistit, zda má klient dostatek asu na vy ešení celé záležitosti. P i porovnání výsledk projektu (7 dní) a zjišt ní získaných dotazníkem jsme zjistili asový rozdíl (17 minut a 8 minut). Podle mého názoru je to zp sobeno tím, že ov ování osoby volajícího, otev ení nového ticketu, ekání na otev ení jakékoliv aplikace si vyžádá více asu, než agent helpdesku edpokládá. 3) Nedostupnost vedoucího, který m že být kontaktován, aby incident pomohl vy ešit Když agent nem že požadovanou informaci ve znalostní databázi najít a zástupce vedoucího týmu není momentáln k dispozici, za íná se u n j projevovat nejistota p i komunikaci

59

s klientem. Jak vyplývá z grafu

. 1 (na str. 15), nejvíce hovor

prob hne v dopoledních

hodinách. Proto se doporu uje, aby agenti s více zkušenostmi pomáhali t m, kte í teprve za ínají. 4) Neefektivní práce s tickety hem vybraného asového období byl proveden test systému pro práci s tickety Incident Management Console. Test byl proveden týmem lokální podpory spole nosti CSC. Vyplývá z n j, že agent helpdesku ztratí p i práci s jedním ticketem dv minuty jen na vytvo ení a uložení pot ebných zm n. Dv minuty je pom rn dost asu pro klienty helpdesku. Vedoucí týmu požádal o zefektivn ní práce s informa ním systémem Incident Management Console. 5) Neznalost jazyka podpory Pro v tšinu z agent není jazyk podpory (angli tina) mate ským jazykem. Tato skute nost že být p ekážkou v porozum ní mezi klientem a agentem helpdesku. V poslední dob emís ují velké spole nosti své pobo ky do

eské republiky. Pozorujeme nar st pracovní síly

ze západní Evropy. Roste zde po et anglických rodilých mluv ích. 6) Zajišt ní p ístupu agent helpdesku ke všem aplikacím Agent a vedoucí týmu jsou zodpov dní za zajišt ní p ístupu ke všem aplikacím. V praxi ale dochází k tomu, že ne všichni agenti pot ebný p ístup skute

mají. Tento problém byl

zjišt n p i hodnocení incidentu z hlediska úrovn jeho vy ešení v pilotním projektu. Agent nem l k aplikaci p ístup a musel ticket poslat ešitelskému týmu. 7) Nefunk nost hardwaru na stran helpdesku íkladem m že být výpadek sít nebo elektrického proudu. Spole nost CSC má podle smlouvy p ijmout 80 % hovor zákazník do 30 sekund. P i výpadku sít je ale podpora klient nemožná. V tomto p ípad je nutné domluvit se s klientem na op tném zavolání. Lokální podpora spole nosti CSC si musí s problémem v co nejkratším ase poradit, aby nedošlo ke zhoršení výsledk v rychlosti p ijetí hovoru. 8) Nefunk ní znalostní báze Tato databáze p edstavuje popis incident a postupy vedoucí k jejich vy ešení. Ob as se ale m že stát, že se informace o nastalé chyb v aplikaci v databázi nevyskytují. Znalecký tým se

60

proto musí neustále starat o dopl ování nových postup

ešení incident . Dodržování t chto

princip vede ke spokojenosti zákazník se službami poskytovanými helpdeskem.

61

Záv r Spole nost CSC má více než padesátiletou zkušenost s poskytováním outsourcingových IT služeb. Pobo ka v Praze byla otev ená p ed n kolika lety, a p esto už dosáhla zna ných výsledk v IT podpo e klient m po celém sv

.

Podklady pro tuto práci byly zpracovány na základ

vlastní pracovní zkušenosti

ve spole nosti na pozici IT analyst. Cílem bakalá ské práce byla analýza komunika ních proces v helpdesku spole nosti CSC Computer Science s.r.o. Pro vytvo ení analýzy byl nejd íve detailn popsán provoz helpdesku. Teoretický základ se skládá zejména z popisu pojm . Veškeré uvád né pojmy jsou p itom názvoslovím používaným ve spole nosti CSC. V práci byly vymezeny klí ové role pro fungování helpdesku, popsány pracovní úkoly a odpov dnosti každého z jeho pracovník . Klí ové role byly zd razn ny v organiza ní struktu e spole nosti. Popsána byla také 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, s vymezenými smluvními podmínkami SLA (Service Level Agreement). Spole nost CSC sestávající z více než devadesáti pobo ek po celém sv

používá

pro zjednodušení procesu komunikace systém, v rámci n hož se vedou záznamy o nastalých incidentech. K systému mají p istup všichni zam stnanci po celém sv

. Práv ze systému

Incident Management Console byly použity podklady pro zpracování analýzy komunika ních proces . Analýza byla zpracována na základ zp sob p ijetí telefonických požadavk od klienta, všímali jsme si t chto aspekt : Rychlost p ijetí hovoru (Speed of answer) – SLA 1 Toto kritérium bylo hodnoceno pouze v pilotním projektu. Data o rychlosti p ijetí hovor byla poskytnuta statistickým týmem. Úrove vy ešení incidentu (First Call resolution) – SLA 2 Kritérium bylo analyzováno v pilotním projektu (3 dny) a projektu (7 dní).

62

Popis incidentu (Ticket accuracy) – SLA 3 hem zkoumaného týdne agenti dodržovali p esný popis incidentu. Dané kritérium dosáhlo úrovn 96,8 %. I v pilotním projektu byly incidenty správn popsány. Typ incidentu Byla provedena analýza p íchozích požadavk

od klienta a vymezeny nejvíce se

vyskytující typy incident . Po ty vy ešených incident Byly zjišt ny po ty vy ešených incident jedním agentem první úrovn podpory. Dále byly analyzovány situace, které mohly vy ešení incidentu na první úrovni podpory zabránit. Znalostní databáze Zd razn na byla d ležitost použití znalostní databáze pro dodržování p edepsaného procesu p i komunikaci s klientem. Délka trvání hovoru i vy íslení délky trvání hovoru bylo možné vid t, že p íchozí požadavky byly v rámci projektu (3 dní) vy ešeny zkušeným agentem helpdesku, který se zam uje na obtížn jší incidenty. Délka trvání hovor v pilotním projektu byla podpr

Pro znázorn ní komunika ních proces

rná.

ve spole nosti byl vytvo en Business Proces

Model. P i analýze modelu m žeme íct, že nejlepším zp sobem pro vy ízení incidentu je telefonát do helpdesku. Obecn

se helpdesk orientuje zejména na pomoc a podporu

zákazník m/uživatel m. Na rozdíl od oby ejných call center eší agenti helpdesku i složit jší požadavky. Zam stnanci musí disponovat ur itými znalostmi a dle charakteru poskytované služby absolvovat i pravidelná školení. Podle mého názoru nastávají problémy p i komunikaci s klientem práv

kv li

nedostate nému vyškolení pracovník helpdesku. Každý z nich p ichází do helpdesku s ur itými znalostmi ve sfé e IT. Krom

nich ale musí mít velmi dobré komunika ní schopnosti,

v komunikaci se zákazníkem se pak m že dále vylepšovat p i pravidelných školeních.

63

které z proces vyžadují blízkost kultur, jazyka nebo legislativy. Pro v tšinu z agent není angli tina (jazyk podpory) mate ským jazykem. I tato skute nost m že být p ekážkou v porozum ní mezi klientem a agentem helpdesku.

64

Literatura [1] CSC COMPUTER SCIENCES s.r.o. Delivery Center - Czech Republic / Prague. CSC.com [online]. [cit. 2012-05-17]. Dostupné z: http://www.csc.com/eastern_europe/ds/27730/38525wss_center_czech_republic_prague. [2] Help desk. In: Wikipedia: the free encyclopedia [online]. St. Petersburg [Florida]: Wikipedia Foundation, 2006-12-11, last modified on 2012-07-28 [cit. 2012-11-27]. Dostupné z: http://cs.wikipedia.org/w/index.php?title=Help_desk&oldid=8831553. [3] PROCHÁZKA, Jaroslav a Cyril KLIMEŠ. Provozujte IT jinak: Agilní a štíhlý provoz, podpora a údržba informa ních systém a IT služeb. 1. vyd. Praha: Grada, 2011. ISBN 978-80247-4137-6. Dostupné z: http://books.google.com/books?id=66pbyrwnUUEC&pg=PA46&dq=servicedesk+p odpora&hl=ru&sa=X&ei=7MK0UOjSOarK0QWypoCgCA&ved=0CDwQ6AEwAg#v=onepage &q=servicedesk%20podpora&f=false. [4] Citrix Systems. In:Wikipedia: the free encyclopedia [online]. St. Petersburg [Florida]: Wikipedia Foundation, 2006-12-11, last modified on 2012-04-21 [cit. 2012-04-28]. Dostupné z: http://cs.wikipedia.org/w/index.php?title=Citrix_Systems&oldid=8438503 [5] OHLHOTST, Frank. Bomgar Offer an Appliance for All Remote Support Needs. Channel Insider

[online].

2009-01-13

[cit.

2010-07-03].

Dostupné

z:

http://www.channelinsider.com/c/a/Reviews/Bomgar-Offers-an-Appliance-for-All-RemoteSupport-Needs/. [6] Dotazník. In: Wikipedia: the free encyclopedia [online]. St. Petersburg [Florida]: Wikipedia Foundation, 2006-12-11, last modified on 2012-11-08 [cit. 2012-12-04]. Dostupné z: http://cs.wikipedia.org/w/index.php?title=Dotazn%C3%ADk&oldid=9268801. [7] SANTLEROVÁ, Kv toslava a kol. Telemarketing v praxi: jak profesionáln telefonovat se zákazníky. 2., aktualiz. a rozš. vyd. Praha: Grada, 2011. 222 s. ISBN 978-80-247-3928-1. 65

[8] P IKRYLOVÁ, Jana a Hana JAHODOVÁ, Hana. Moderní marketingová komunikace. 1. vyd. Praha: Grada, 2010. 303 s. ISBN 978-80-247-3622-8. [9] WALKER, Alfred J. a kol. Moderní personální management: nejnov jší trendy a technologie. 1. vyd. Praha: Grada, 2003. 253 s. ISBN 80-247-0449-8. [10] VYSEKALOVÁ, Jitka a kol. Chování zákazníka: jak odkrýt tajemství „ erné sk

ky“.

1. vyd. Praha: Grada, 2011. 356 s. ISBN 978-80-247-3528-3. [11] STA KOVÁ, Anna. Podnikáme úsp šn s malou firmou. 1. vyd. Praha: C.H. Beck, 2007. 199 s. ISBN 978-80-7179-926-9. [12] TVRDÍKOVÁ, Milena. Aplikace moderních informa ních technologií v

ízení firmy:

nástroje ke zvyšování kvality informa ních systém . Praha: Grada, 2008. 173 s. ISBN 978-80247-2728-8. [13]

BOCIJ,

Paul

et

al. Business

Information

Systems:

Technology,

Development

and Management for the E-business. 3. vyd. New York: Financial Times/Prentice Hall, 2005. 827 s. ISBN 0-273-68814-6. [14] BRUTON, Noel. How to manage the I.T. helpdesk. Oxford: Butterworth-Heinemann, 1997. 220 s. Computer weekly professional series. ISBN 0-7506-3811-7. [15] Reflective learning in practice [online]. Aldershot, Hants, England: Gower, 2002 [cit. 201205-18]. Dostupné z: http://site.ebrary.com/lib/natl/Doc?id=10046803. [16] VO ÍŠEK, Ji í a kol. Aplika ní služby IS/ICT formou ASP: pro

a jak pronajímat

informatické služby. 1. vyd. Praha: Grada, 2004. 213 s. ISBN 80-247-0620-2. [17] DOMBERGER, Simon. The Contracting Organization: a Strategic Guide to Outsourcing. 1. vyd. Oxford: Oxford University Press, 1998. 229 s. ISBN 0-19-877457-5. [18] CLICK, Rick L. a Thomas N. DUENING. Business Process Outsourcing: the Competitive Advantage. Hoboken: Wiley, 2005. 241 s. ISBN 0-471-65577-5.

66

[19] BROWN, Douglas. The black Book of Outsourcing: How To Manage the Changes, Challenges, and Opportunities [online]. Hoboken, N, J. John Wiley & Sons, Inc., 2005 [cit. 2012-05-18]. Dostupné z: http://site.ebrary.com/lib/natl/Doc?id=10114144. [20] DVO

EK, Ji í a Ladislav TYLL. Outsourcing a offshoring podnikatelských inností.

1. vyd. Praha: C.H. Beck, 2010. 183 s. ISBN 978-80-7400-010-2. [21] KENDRICK, Rupert. Outsourcing IT: a Governance Guide [online]. Ely, U.K.: IT Governance

Pub.,

2009 [cit.

2012-05-18].

Dostupné

z:

http://site.ebrary.com/lib/natl/Doc?id=10439460. [22] KEUPER, Frank (ed.). Managed Services: IT-Sourcing der Nächsten Generation [online]. 1. vyd.

Wiesbaden:

Gabler,

2009

[cit. 2012-05-18].

Dostupné

z:

http://www.springerlink.com/content/u76114/?p=a26ccf6b18254990bf284b7a4b01ea1f&pi=127. ISBN 978-3-8349-8290-2. [23] CORBETT, Michael F. The outsourcing Revolution: Why It Makes Sense and How To Do It Right [online]. Chicago, IL: Dearborn Trade Pub., 2004 [cit. 2012-05-18]. Dostupné z: http://site.ebrary.com/lib/natl/Doc?id=10064732.

67

Seznam tabulek Tabulka 1. Kritéria hodnocení helpdesku. ......................................................................................... 26 Tabulka 2. Seznam p íchozích incident . .......................................................................................... 28 Tabulka 3. SLA (Service Level Agreement). .................................................................................... 34 Tabulka 4. Procentuální úsp šnost ešení incident podle jejich úrovn (projekt 3 dny). ............. 37 Tabulka 5. Úrove vy ešení incidentu (projekt 7 dní). ..................................................................... 37 Tabulka 6. Úrove vy ešení incident (projekt 7 dní). ..................................................................... 39 Tabulka 7. Kritérium „Popis incidentu“ – projekt 7 dní. .................................................................. 41 Tabulka 8. etnost jednotlivých typ incident - projekt 3 dny. ..................................................... 46 Tabulka 9. Po ty požadavk podle typu incidentu - sedmidenní projekt........................................ 48 Tabulka 10. Pr

rná délka trvání hovoru - pilotní projekt. ........................................................... 49

Tabulka 11. Použití znalostní databáze v rámci pilotního projektu. ................................................ 51 Tabulka 12. Výskyt typ incident z pohledu agenta první úrovn podpory (dotazník). .............. 53 Tabulka 13. Délka trvání hovoru z pohledu agenta (dotazník). ....................................................... 54 Tabulka 14. Výsledky analýzy. .......................................................................................................... 56

68

Seznam obrázk Obrázek 1. Pokrytí spole nosti CSC ve st ední a východní Evrop . ............................................... 10 Obrázek 2. Struktura podpory na první úrovni.................................................................................. 14 Obrázek 3. Struktura podpory na druhé úrovni. ................................................................................ 15 Obrázek 4. Organiza ní struktura helpdesku..................................................................................... 17 Obrázek 5. Systém helpdesku online. ................................................................................................ 19 Obrázek 6. Nástroje helpdesku........................................................................................................... 20 Obrázek 7. Incident Management Console........................................................................................ 20 Obrázek 8. Remedy Knowledge Console. ......................................................................................... 21 Obrázek 9. Citrix Systems. ................................................................................................................. 21 Obrázek 10. Business proces model komunikace v helpdesku. ....................................................... 25 Obrázek 11. Vyhledávání incidentu v Incident Management Console. .......................................... 32 Obrázek 12. Vytvo ení reportu v Incident Management Console. .................................................. 32 Obrázek 13. Vytvo ení reportu v Incident Management Console. .................................................. 33 Obrázek 14. Vytvo ení reportu v Incident Management Console. .................................................. 33 Obrázek 15. Kritérium „Popis incidentu“ – dob e popsaný incident............................................... 40 Obrázek 16. Kritérium „Popis incidentu“ – špatn popsaný incident. ............................................ 41 Obrázek 17. Ov ení totožnosti zákazníka - security questions....................................................... 45 Obrázek 18. Tvorba typ incident pro sedmidenní projekt. ........................................................... 47

69

Seznam graf Graf 1. Po et p ijatých hovor v závislosti na denní dob . .............................................................. 15 Graf 2. Po et p ijatých hovor podle dn v týdnu. ........................................................................... 16 Graf 3. Po ty agent podle dn v týdnu. ........................................................................................... 16 Graf 4. Procentuální úsp šnost ešení incident podle jejich úrovn (projekt 3 dny). ................... 36 Graf 5. Úrove vy ešení incidentu (projekt 7 dní). ........................................................................... 39 Graf 6. Úrove vy ešení incident (projekt 7 dní). ........................................................................... 39 Graf 7. Popis incidentu SLA 3. .......................................................................................................... 42 Graf 8. Procentuální výskyt jednotlivých typ incident - projekt 3 dny. ...................................... 47 Graf 9. Procentuální znázorn ní doby trvání hovoru v rámci pilotního projektu. .......................... 50 Graf 10. Procento použití znalostní databáze v pilotním projektu. .................................................. 51 Graf 11. Výskyt typ incident z pohledu agenta první úrovn podpory (dotazník). .................... 54 Graf 12. Výskyt typ incident z pohledu agenta první úrovn podpory (dotazník). .................... 55

70

Seznam p íloh íloha 1. Seznam p íchozích incident projekt 7 dní.

71

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

Recommend Documents