IZBOLJŠAVE PROCESA V CENTRU ZA PODPORO UPORABNIKOM · 2017. 11. 28. · Univerza v Mariboru ² Fakulteta za organizacijske vede Diplomsko delo visokoolsko strokovnega tudija Jožef

Diplomsko delo visokošolskega strokovnega študija Informatika v organizaciji in managementu

IZBOLJŠAVE PROCESA V CENTRU ZA PODPORO UPORABNIKOM

Mentor: red. prof. dr. Robert Leskovar Kandidat: Jožef Omerzel

Kranj, februar 2015

ZAHVALA Zahvaljujem se mentorju dr. Robertu Leskovarju za pomoč in nasvete pri izdelavi diplomskega dela. Posebna zahvala gre tudi moji družini, ki me je podpirala pri moji študijski poti.

POVZETEK

V nalogi so predstavljene izboljšave v Centru za podporo uporabnikom (CPU) z določitvijo vlog agentov in natančnejšim merjenjem dosežkov agentov. Podlaga izboljšave je ITIL, ki ga sestavlja 5 glavnih delov: strategija storitve (Service Strategy), načrtovanje storitve (Service Design), prehod na nove storitve (Service Transition), izvajanje storitve (Service Operation) in stalno izboljševanje storitve (Continual Service Improvement). V nalogi smo uporabili študijo priporočil ITIL 2 in ITIL 3, modeliranje in merjenje značilnosti procesa ter statistično analizo meritev. Meritve procesov v CPU so bile narejene z orodjem COCOS v letih 2011—2013. Ključni pokazatelji procesa so odstotek zgrešenih klicev, povprečno število odgovorjenih klicev na dan in povprečni čas reševanja zahtevkov. Na podlagi meritev je bila uvedena razdelitev vlog agentov na telefonista in terenskega agenta. Rezultat uvedbe orodja COCOS in organizacijskih sprememb so izboljšave: odstotek zgrešenih klicev se je zmanjšal za 8,21 %, čas reševanja zahtevka se je skrajšal za 80,43 % razmerje med zabeleženimi in odgovorjenimi klici se je povečalo za 4,32 %. Merjenje procesa v CPU omogoča tudi rotacijo vlog, identifikacijo manj učinkovitih agentov in predvsem nadzor v realnem času. Izboljšala se je tudi motiviranost agentov v CPU.

KLJUČNE BESEDE:

center za podporo uporabnikom

ITIL

upravljanje z incidenti

ABSTRACT

The thesis introduces improvements in Service Desk (SD) with the allocation of the roles of agents and more precise measurement of results of agents. Basis for improvements is ITIL which consists of 5 major parts: Service Strategy, Service Design, Service Transition, Service Operation and Continual Service Improvement. In the thesis we used study recommendations of ITIL 2 in ITIL 3, process modelling, measuring of process characteristics and statistical analysis of measurements. The measurements of processes in SD were done by the tool COCOS in years from 2011 to 2013. The key indicators for the process are percentage of missed calls, average number of answered calls per day and average time to resolve requests. On the basis of measurements division of roles of agents into telephone operator and field agent was introduced. The results of implementation of new tool COCOS was: improved percentage of missed calls by 8,21 %, resolving time was reduced by 80,43 %, ratio between answered calls and entered tcikets was improved by 4,32 %. The measurement of process in SD makes it possible to rotate the roles, to identify less effective agents and mostly monitoring in the real time. Motivation of SD agents was also improved.

KEYWORDS:

service desk

ITIL

incident management

KAZALO 1 UVOD ................................................................................ 1

2 METODOLOGIJA DELA.............................................................. 2

2.1 PREDSTAVITEV PROBLEMA ........................................................ 2

2.2 DEFINICIJA CILJEV .................................................................. 2

2.3 UPORABLJENE METODE, TEHNIKE IN ORODJA .................................. 3

3 UPRAVLJANJE Z IT STORITVAMI .................................................. 4

3.1 PRIPOROČILA ITIL ZA UPRAVLJANJE Z INCIDENTI .............................. 4

3.2 PREDSTAVITEV ITIL3 ............................................................... 5

3.2.1 STRATEGIJA STORITVE (SERVICE STRATEGY) ............................. 6

3.2.2 NAČRTOVANJE STORITEV (SERVICE DESIGN) .............................. 6

3.2.3 PREHOD NA NOVE STORITVE (SERVICE TRANSITION) ..................... 6

3.2.4 IZVAJANJE STORITVE (SERVICE OPERATION) .............................. 6

3.2.5 STALNO IZBOLJŠEVANJE STORITEV (CONTINUAL SERVICE IMPROVEMENT) ................................................................ 7

3.3 PREDSTAVITEV IZVAJANJA STORITVE (SERVICE OPERATION) ................. 7

3.3.1 UPRAVLJANJE DOGODKOV (EVENT MANAGEMENT) ....................... 8

3.3.2 UPRAVLJANJE Z INCIDENTI (INCIDENT MANAGEMENT) ................... 9

3.3.3 IZPOLNJEVANJE ZAHTEV (REQUEST FULFILMENT) ....................... 10

3.3.4 UPRAVLJANJE S PROBLEMI (PROBLEM MANAGEMENT) .................. 10

3.3.5 UPRAVLJANJE DOSTOPOV (ACCESS MANAGEMENT) ..................... 11

3.3.6 FUNKCIJE V IZVAJANJU STORITVE ......................................... 11

3.4 PREDSTAVITEV PODROČIJ IZGRADNJE IN UPRAVLJANJA UČINKOVITEGA CENTRA ZA PODPORO UPORABNIKOM .......................................... 13

3.4.1 DEFINIRANJE PROCESOV CPU ............................................... 14

3.4.2 PRORAČUN .................................................................... 15

3.4.3 ORGANIZIRANJE CPU ........................................................ 15

3.4.4 OSEBJE CPU................................................................... 16

3.4.5 ORODJA ZA CPU .............................................................. 17

3.4.6 MERITVE UČINKA CPU ....................................................... 19

3.4.7 PROMOCIJA CPU ............................................................. 20

4 POSNETEK STANJA ................................................................ 21

4.1 PREDSTAVITEV OKOLJA ........................................................... 21

4.2 MODEL PROCESA ................................................................... 29

4.3 DEFINICIJA KLJUČNIH KAZALCEV PROCESA IN MERITVE OBSTOJEČEGA PROCESA ........................................................................... 33

5 PREDLOGI ZA SPREMEMBE PROCESOV .......................................... 44

5.1 PRERAZPOREDITEV NALOG MED AGENTI ....................................... 44

5.2 SPREMEMBE PROCESA ............................................................. 45

5.3 VPELJAVA NOVIH ORODIJ ........................................................ 52

5.4 MERITVE KLJUČNIH KAZALCEV SPREMENJENEGA PROCESA .................. 58

6 DISKUSIJA .......................................................................... 69

6.1 REZULTATI ......................................................................... 69

6.2 PRIDOBLJENE IZKUŠNJE .......................................................... 71

6.3 MOŽNOSTI NADALJNJEGA RAZVOJA ............................................ 71

7 ZAKLJUČEK ......................................................................... 73

LITERATURA IN VIRI ....................................................................... 74

KAZALO SLIK ............................................................................... 75

KAZALO TABEL ............................................................................. 76

KRATICE IN AKRONIMI ..................................................................... 77

Univerza v Mariboru – Fakulteta za organizacijske vede Diplomsko delo visokošolsko strokovnega študija

Jožef Omerzel: Izboljšave procesa v Centru za podporo uporabnikom stran 1

1 UVOD V današnjem času si ne moremo predstavljati opravljanja večine nalog in zadolžitev v neki organizaciji brez uporabe informacijske tehnologije (IT). Ta tehnologija omogoča enostavnejše, hitrejše in učinkovitejše opravljanje nalog in zadolžitev. Predstavlja se nam kot centralizirane baze podatkov, skupni podatkovni mrežni pogoni na podatkovnih strežnikih, programska oprema usklajena z internimi potrebami v podjetju in usklajena z zahtevami in zakonodajo na državnem ali svetovnem nivoju, internetne storitve z elektronsko pošto in spletom na čelu, vsa strojna, tiskalniška in mrežna oprema ter ostale komunikacijske storitve od pametnih telefonov, tablic in VPN povezave. Zaposleni v organizaciji so lahko strokovnjaki z določenih področij (finance, nabava, logistika, prodaja, razvoj in raziskave ipd.) ali nespecializirani zaposleni (v proizvodnji, skladišču ipd.), vendar s pomočjo informacijske tehnologije opravljajo svoje vsakodnevne zadolžitve in opravila, zato so se priučili, kako jo uporabljati. Z uporabo informacijske tehnologije pa lahko vedno pride do težav (incidentov), in sicer da nek program ne deluje, računalnik se ne odziva več, v tiskalniku so se zataknili papirji, podatki na skupnem mrežnem pogonu so nedosegljivi ali pa uporabnik preprosto potrebuje pomoč pri izvedbi določene funkcije v pisarniškem programu ali preselitev računalniške opreme na novo delovno mesto ali priklop nove opreme. Za pomoč pri odpravi lažjih težav lahko uporabniki povprašajo sodelavce, če so iznajdljivi, poiščejo rešitev na internetu, za večje incidente ali zahteve pa pričakujejo, da jih bo rešil oddelek informacijske tehnologije, saj jim je ta dal to tehnologijo, izdelke ali storitve v uporabo. Oddelki informacijske tehnologije v večini primerov organizirajo posebno skupino ljudi, ki pomaga uporabnikom pri reševanju teh incidentov in zahtev ter uporabnikom predstavlja centralno kontaktno točko: Center za podporo uporabnikom (CPU). CPU nudi kot formalna organizacija znotraj oddelka IT podporno funkcijo uporabnikom, in sicer na področju izdelkov, storitev in tehnologije, ki se uporabljajo v organizaciji, in je lahko razdeljen na več nivojev podpore. CPU v večini primerov predstavlja edini stik uporabnikov z oddelkom IT v organizaciji. CPU predstavlja neke vrste »prevajalni« sistem med uporabniki in IT skrbniki, hkrati pa v očeh IT skrbnikov predstavlja strelovod pred uporabniki, saj CPU zabeleži incidente in jim jih posreduje v reševanje, namesto da bi uporabniki direktno klicali IT skrbnike. Hkrati pa CPU oddelku IT predstavlja vir informacij, kaj se z izdelki, storitvami in tehnologijo dogaja, na kakšne težave naletijo uporabniki in kakšne želje po izboljšavah imajo. Ugled CPU v očeh vodstva oddelka IT predstavlja ugled celotnega oddelka IT. V večini primerov uporabniki CPU enačijo z oddelkom IT, tako da slabo delo CPU enačijo s slabim delom celotnega oddelka IT. Zato se v večini mednarodnih korporacij izvajajo obsežne periodične mnenjske ankete, kjer se preverja zadovoljstvo uporabnikov, pripombe, komentarji in predlogi za izboljšave dela oddelka IT.



2 METODOLOGIJA DELA 2.1 PREDSTAVITEV PROBLEMA V diplomski nalogi bomo preučili in predlagali izboljšave za CPU, in sicer samo na 1. nivoju podpore. CPU opazovane organizacije deluje znotraj lokalne enote IT v mednarodni korporaciji, ki deluje na področju proizvodnje, razvoja in trženja ter skrbi za okoli 4.500 uporabnikov v skoraj 20 državah. CPU se v zadnjih treh letih spoprijema s povečanim številom zahtev, ki so s strani uporabnikov v veliki večini podane telefonsko. Zaradi porasta zahtev s strani uporabnikov se je povečalo tudi število neodgovorjenih telefonskih klicev. Zaradi večjega števila neodgovorjenih klicev je začel upadati tudi ugled CPU, kakor tudi posledično celotne enote IT. Na drugi strani pa povečano število zahtevkov uporabnikov negativno vpliva na ključne kazalce procesa: povečano število izgubljenih klicev, daljši čas reševanja in slabše razpoloženje v samem CPU. V opazovani organizaciji se CPU spoprijema s sledečimi izzivi:

Zaradi porasta zahtev s strani uporabnikov, ki so večinoma podane telefonsko, se je povečalo število neodgovorjenih klicev.

Zaradi porasta števila zahtevkov se je podaljšal čas reševanja teh zahtevkov.

Večje kot je število neodgovorjenih klicev, večje je nezadovoljstvo s CPU in posledično s celotno enoto IT.

Povečano število zahtev s strani uporabnikov agentom v CPU velikokrat daje občutek nemoči, preobremenjenosti, neučinkovitosti in lahko vodi v sindrom izgorelosti.

2.2 DEFINICIJA CILJEV V diplomski nalogi bomo analizirali sedanje stanje:

Analiza sedanjega stanja in izdelava predlogov za izboljšave procesov.

Razdelitev vlog med agenti CPU.

Vpeljava aplikacije »COCOS Call.Center«.

Vpeljava drugih orodij in metod ter izobraževanj za izboljšavo učinkovitosti dela CPU.

Definirali bomo ključne kazalce procesa ter oblikovali predloge za izboljšanje odstotka odgovorjenih klicev ter skrajšanja časa reševanja zahtevkov. S tem se bo tudi izboljšala učinkovitost CPU:

Zmanjšanje števila neodgovorjenih klicev s 25 % na vsaj 15 %.

Skrajšanje časa reševanja zahtev uporabnikov v povprečju za vsaj 25 %.

Povečanje razmerja med zabeleženimi zahtevami uporabnikov in odgovorjenimi klici za vsaj 10 %.

Izboljšanje morale in zadovoljstva agentov v CPU, ker bodo dobili orodja in znanja za učinkovitejše in hitrejše reševanje zahtev.



2.3 UPORABLJENE METODE, TEHNIKE IN ORODJA

Študij priporočil ITIL 2 in ITIL 3

Modeliranje procesa

Merjenje značilnosti procesa

Statistična analiza meritev

Uporabljena orodja: COCOS Call.Center, MS Excel, SPSS



3 UPRAVLJANJE Z IT STORITVAMI Najboljše prakse (Best Practises) predstavljajo proces razvoja in sledenja standardiziranemu načinu, kako se določene stvari opravljajo in ki ga lahko pri svojem delu uporabijo mnoge organizacije. Najboljše prakse se uporabljajo zato, da se vzdržuje kvaliteta kot alternativa obveznim standardom, predpisanim z zakonodajo, ki je zasnovana na samoocenjevanju in meritvah (povzeto po spletni strani http://www.securityprocedure.com/comparison-between-cobit-itil-and-iso-27001). V informacijski tehnologiji so najbolj razširjene najboljše prakse, ki dajejo najboljša priporočila organizacijam za upravljanje informacijskih sistemov COBIT, ITIL in ISO27001. Kratica COBIT predstavlja Control Objective over Information and Related Technology. COBIT je izdala ISACA (Information System Control Standard), neprofitna organizacija za IT Governance. Glavna funkcija COBIT je pomagati organizacijam začrtati IT procese glede na ISACA standard najboljših praks. Za COBIT se večinoma odločijo organizacije, ki izvajajo nadzor informacijskih sistemov, ki je vezan na finančni nadzor ali na splošen IT nadzor. Kratica ITIL predstavlja Information Technology Infrastructure Library. ITIL je bil izdan s strani OGC (Office of Government Commerce) in predstavlja skupek ogrodij za upravljanje z IT stopnjami storitev (IT Service Level). Čeprav je ITIL zelo podoben COBIT, je glavna razlika v tem, da je COBIT standard zasnoval na procesih in tveganjih, medtem ko je ITIL zasnoval standard na podlagi osnovnih IT storitev. ISO27001 se precej razlikuje od COBIT in ITIL, ker predstavlja standard za varnost, zato je njegov obseg manjši, vendar gre na tem področju bolj v globino kot COBIT in ITIL. S stališča implementiranja standarda v neko organizacijo je standard ITIL najlažje uvesti. COBIT in ISO27001 gledata na procese širše, zato ju je težko implementirati po delih, medtem ko lahko ITIL uvedemo po delih, pa to še vedno ne bo vplivalo na samo storitev. V primeru, da ima oddelek IT omejena finančna sredstva, lahko prvo leto uvede samo en proces iz ITIL, naslednje leto pa lahko uvede par naslednjih procesov.

3.1 PRIPOROČILA ITIL ZA UPRAVLJANJE Z INCIDENTI Priporočila ITIL za upravljanje z incidenti so povzeta po knjigah, izdanih s strani The Stationery Office. V svojih začetnih letih se je informacijska tehnologija kot nova tehnologija v glavnem posvečala razvoju programske opreme. Izkoriščanje očitnih prednosti te nove tehnologije se je osredotočalo zagotavljanju ustvarjanja programske opreme kot del širše ponudbe storitev, ki je podpiralo samo poslovanje.



V 1980-ih letih je naraščalo upravljanje IT storitev, prav tako pa je naraščala odvisnost posla od teh storitev. Pojavila se je potreba po preoblikovanju pogleda na IT storitve, zato so se pojavili IT Help Deski, ki so se poskušali ukvarjati s težavami, ki so jih imeli tisti, ki so uporabljali IT storitve kot sestavni del svojega poslovanja. Hkrati je vlada Velike Britanije, ki je imela potrebo po učinkovitosti, začela dokumentirati, kako so najboljše in najbolj uspešne organizacije pristopile k upravljanju storitev. V poznih 1980-ih in zgodnjih 1990-ih letih so proizvedli serijo knjig, ki so dokumentirale pristop k upravljanju tistih IT storitev, ki so bile potrebne za podporo poslovnih uporabnikov. Ta knjižnica praks je bila naslovljena IT Infrastructure Library – na kratko ITIL. Leta 2004 je organizacija OGC začela z drugo revizijo ITIL, in sicer zato, ker so se pojavile nove arhitekture tehnologij, virtualizacija in najem zunanjih izvajalcev (outsourcing), ki so postali glavna opora informacijski tehnologiji. Tako je nastal ITIL3, ki ga sestavlja 5 glavnih področij.

3.2 PREDSTAVITEV ITIL3 ITIL3 sestavlja pet glavnih področij (slika 1):

Strategija storitve (Service Strategy)

Načrtovanje storitve (Service Design)

Prehod na nove storitve (Service Transition)

Izvajanje storitve (Service Operation)

Stalno izboljševanje storitve (Continual Service Improvement)

Slika 1: ITIL storitveni življenjski cikel (ITIL, 2007).



3.2.1 STRATEGIJA STORITVE (SERVICE STRATEGY) Strategija storitve (Service Strategy) zagotavlja smernice, kako gledati na upravljanje storitev ne samo kot na organizacijsko zmožnost, ampak kot na strateško sredstvo (asset). Pokriva področja: razvoj trgov storitev (development of service markets), karakteristike notranjih in zunanjih tipov ponudnikov (characteristics of internal and external provider types), sredstva storitev (service assets), portfelj storitev in implementacijo storitev skozi življenjski cikel storitev (the service portfolio and implementation of strategy through the Service Lifecycle). Med glavnimi temami se nahajajo: upravljanje financ (Financial Management), upravljanje zahtev (Demand Management), organizacijski razvoj (Organizational Development) in strateška tveganja (Strategic Risks). 3.2.2 NAČRTOVANJE STORITEV (SERVICE DESIGN) Načrtovanje storitve (Service Design) nudi smernice za model in razvoj storitev in praks za upravljanje storitev. Pokriva principe modela in metode za spremembo strateških ciljev v portfelje storitev in sredstev storitev (service assets). Namen načrtovanja storitev ni omejen na nove storitve, ampak vključuje spremembe in izboljšave, potrebne za povečanje ali vzdrževanje koristi strankam skozi celoten življenjski cikel storitev, doseganje nivojev storitev in skladnost s standardi in regulativami. Glavne teme so: katalog storitev (Service Catalogue), razpoložljivost (Availability), zmožnost (Capacity), stalnost (Continuity) in upravljanje nivojev storitev (Service Level Management). 3.2.3 PREHOD NA NOVE STORITVE (SERVICE TRANSITION) Prehod na nove storitve (Service Transition) nudi smernice za razvoj in izboljšanje zmožnosti prehoda novih in spremenjenih storitev v žive storitvene operacije (live service operation). Prehod na nove storitve predstavlja sistem upravljanja znanja (the Service Knowledge Management System), ki se gradi na podlagi podatkov in informacij, pridobljenih znotraj konfiguracije (Configuration), zmožnosti (Capacity), znanih napak (Known Error), definitivnega medija (Definitive Media) in sistema sredstev (Assets systems) ter povečuje uporabo informacij o storitvah v sposobnost uporabe znanja za odločanje in upravljanje storitev. 3.2.4 IZVAJANJE STORITVE (SERVICE OPERATION) Izvajanje storitve (Service Operation) vključuje prakse v upravljanju vsakodnevnih storitvenih operacij. Vključuje smernice za doseganje razpoložljivosti in učinkovitosti v nudenju in podpori storitev ter zagotavljanje koristi strankam in ponudnikom storitev. V izvajanje storitev spadajo storitve, kot so: upravljanje z dogodki (Event Management), upravljanje z incidenti (Incident Management), upravljanje s problemi (Problem Management), upravljanje z zahtevami (Request



Management), upravljanje z aplikacijami (Application Management) in tehnično upravljanje (Technical Management). 3.2.5 STALNO IZBOLJŠEVANJE STORITEV (CONTINUAL SERVICE IMPROVEMENT) Stalno izboljševanje storitve zagotavlja smernice v ustvarjanju in vzdrževanju koristi strankam skozi boljši model, tranzicijo in delovanje storitev. To dosega s kombinacijo principov, praks in metod skozi upravljanje s kakovostjo (Quality Management), upravljanje s spremembami (Change Management) in izboljšave zmožnosti (Capability improvement).

3.3 PREDSTAVITEV IZVAJANJA STORITVE (SERVICE OPERATION) Izvajanje storitve je faza v ITIL storitvenem življenjskem ciklu, ki je odgovorna za vsakodnevne aktivnosti in infrastrukturo, potrebno za nudenje storitev. Namen izvajanja storitve je koordinirati in izvajati aktivnosti in procese, potrebne za izvedbo in upravljanje storitev na podlagi dogovorjenih stopenj s poslovnimi uporabniki in strankami (slika 2). Izvajanje storitev je tudi odgovorno za stalno upravljanje tehnologij, ki se uporabljajo za izvedbo in podporo storitvam.

Slika 2: Vpetost izvajanja storitve v ostale procese (ITIL, 2007).



V vseh fazah ITIL storitvenega življenjskega cikla skupaj nastopajo izraziti procesi, funkcije in aktivnosti, ki opravljajo cilje izvajanja storitve. Procesi:

Upravljanje dogodkov (Event Management)

Izpolnjevanje zahtev (Request Fulfilment)

Upravljanje z incidenti (Incident Management)

Upravljanje s problemi (Problem Management)

Upravljanje dostopov (Access Management) Funkcije:

Nadzor in kontrola (Monitoring and Control)

Center za podporo uporabnikom – CPU (Service Desk)

Tehnično upravljanje (Technical Management)

Upravljanje IT operacij (IT Operations Management)

Upravljanje aplikacij (Application Management) 3.3.1 UPRAVLJANJE DOGODKOV (EVENT MANAGEMENT) Dogodek se lahko definira kot vsak pripetljaj, ki ga lahko zaznamo ali opazimo in ima pomen za upravljanje IT infrastrukture ali izvedbo IT storitev ter oceno, kakšen vpliv ima ta odklon na storitve. Dogodki so običajno opozorila, ki so posledica IT storitve, element konfiguracije (Configuration Item)1 ali nadzornega orodja. Učinkovito izvajanje storitve je odvisno od poznavanja statusa infrastrukture in zmožnosti zaznavanja vsakega odklona od normalnega ali pričakovanega delovanja. To mu omogočajo nadzorni in kontrolni sistemi, zasnovani na dveh tipih orodij:

Aktivna nadzorna orodja, ki preverjajo status in razpoložljivost ključnih elementov konfiguracije. Vsaka izjema sproži alarm in mora biti sporočena z ustreznim orodjem ali timom za akcijo.

Pasivna nadzorna orodja, ki zaznajo ali korelirajo operativne alarme in komunikacije, ki jih generirajo elementi konfiguracije.

Upravljanje dogodkov se lahko uporabi v vseh pogledih upravljanja storitev, ki morajo biti nadzorovane in so lahko avtomatizirane:

Elementi konfiguracije: o Nekateri elementi konfiguracije bodo vključeni, ker morajo ostati v

konstantnem stanju (npr. mrežno stikalo mora biti stalno »gor«). o Nekateri elementi konfiguracije bodo vključeni, ker se mora njihov

status pogosto spreminjati, upravljanje dogodkov pa se lahko uporabi za avtomatizacijo tega, in posodablja CMS (npr. posodabljanje podatkovnega strežnika).

Pogoji okolja (npr. detektorji ognja in dima).

Nadzor licenc programske opreme, da se zagotovi optimalna oz. legalna uporaba in dodelitev.

1 Element konfiguracije (Configuration Item (Service Transition)) – katera koli komponenta,

ki jo je potrebno upravljati, da se nudi IT storitev.



Varnost (tj. zaznavanje vdorov).

Normalna aktivnost (npr. spremljanje uporabe aplikacije ali delovanja strežnika).

Korist upravljanja dogodkov je običajno poslu vidna posredno:

Upravljanje dogodkov zagotavlja mehanizme za zgodnje zaznavanje incidentov. V mnogih primerih je možno zaznati incident in ga dodeliti ustrezni grupi v reševanje, preden se zgodi dejanski izpad.

Upravljanje dogodkov omogoča, da so nekatere vrste avtomatiziranih aktivnosti nadzorovane z izjemami, s čimer bi odpravili potrebno po dragem in temeljitem nadzoru sredstev v realnem času, hkrati pa se zmanjša čas izpada.

Ko je vključeno v drug proces upravljanja storitev (npr. upravljanje razpoložljivosti ali upravljanja zmožnosti), potem lahko upravljanje dogodkov sporoči spremembe statusov ali izjem, ki omogočajo osebi ali timu, da zgodaj odreagirata, s čimer izboljša izvedbo procesa.

Upravljanje dogodkov zagotavlja osnovo za avtomatizirane operacije, s čimer poveča učinkovitost in omogoča porabo dragih človeških virov za bolj inovativno delo, kot je recimo zasnova novih ali izboljšanih funkcionalnosti ali definiranje novih načinov, s katerimi lahko posel izrablja tehnologijo za povečano konkurenčno prednost.

3.3.2 UPRAVLJANJE Z INCIDENTI (INCIDENT MANAGEMENT) Upravljanje z incidenti vključuje vsak dogodek, ki prekine ali lahko prekine storitev. Sem so vključeni dogodki, ki jih direktno sporočijo uporabniki ali preko CPU ali preko nekega vmesnika, povezanega z orodjem za upravljanje z incidenti. Incidente lahko zazna CPU sam ali jih v orodje za upravljanje z incidenti zabeleži tehnično osebje, če recimo opazi napake v delovanju strojne ali mrežne komponente, ter jih naslovi na CPU. Upravljanje z incidenti se ukvarja z incidenti, ki so rezultat okvar ali napak v okviru standardne računalniške in programske opreme ter so posledica dejanskih ali možnih odklonov od načrtovanega delovanja omenjene opreme. Vzrok za incident je lahko očiten in se mu lahko posvetimo brez nadaljnjega poizvedovanja, tako da izvedemo popravilo, začasno rešitev (workaround) ali pa zahtevo za spremembo, da odstranimo napako. V teh primerih se reševanja incidenta lotimo zelo hitro, mogoče tudi brez neposrednega iskanja izvornega vzroka incidenta, tj. problema. Namen upravljanja z incidenti je čim prej vzpostaviti normalno stopnjo delovanja storitev, medtem ko upravljanje s problemi poskuša najti izvorni vzrok incidenta in ga trajno odpraviti. Korist upravljanja z incidenti je zelo vidna poslu, tako da se jo tu lažje prikaže kot na drugih področjih izvajanja storitev. Zaradi tega je upravljanje z incidenti eden prvih procesov, ki se vpelje v projektih upravljanja storitev. Upravljanje z incidenti poslu predstavlja sledečo korist:

Zmožnost zaznavanja in reševanja incidentov, kar se poslu odraža v krajših izpadih in pomeni večjo razpoložljivost storitve — posel je zmožen izrabljati funkcionalnost storitve, tako kot je bila zasnovana.



Zmožnost uvrstiti IT aktivnosti v prioritete posla v realnem času — upravljanje z incidenti vključuje zmožnost identifikacije prioritet posla in dinamično razporejanje virov glede na potrebe.

Zmožnost identifikacije potencialnih izboljšav storitev — to je rezultat razumevanja, kaj določa incident, in kontakta z aktivnostmi operativnega osebja v poslu.

CPU lahko skozi reševanje incidentov identificira dodatne storitve ali potrebe po izobraževanjih v IT ali v poslu.

3.3.3 IZPOLNJEVANJE ZAHTEV (REQUEST FULFILMENT) Izraz »zahteva po storitvi« (Service Request) se uporablja kot generični opis za mnoge različne potrebe, ki jih uporabniki podajo v IT. V glavnem gre za majhne spremembe, ki predstavljajo majhno tveganje, se pojavljajo pogosto in niso drage (npr. zahteva za menjavo gesla, namestitev dodatne programske opreme na določeno delovno postajo, preselitev določene strojne opreme) ali preproste zahteve po dodatnih informacijah. Te zahteve se zaradi svoje pogostosti in majhnega tveganja bolje upravljajo v ločenem procesu, kot pa da se kopičijo ali motijo normalno upravljanje z incidenti ali upravljanje s spremembami. Nekatere organizacije brez problemov zahteve po storitvi obravnavajo v procesu in orodjih upravljanja z incidenti, čeprav incident predstavlja nenačrtovan dogodek, medtem ko so zahteve po storitvi lahko in bi morale biti načrtovane. Mnoge zahteve po storitvi se bodo ponavljale, zato se lahko izdela vnaprej definiran model s koraki za izpolnitev zahteve, osebami oz. timi, vključenimi v izvedbo, časovnimi okvirji in eskalacijskimi potmi. Nekateri modeli lahko vključujejo tudi nekakšno obliko vnaprejšnje odobritve kot del upravljanja s spremembami. 3.3.4 UPRAVLJANJE S PROBLEMI (PROBLEM MANAGEMENT) Problem je v ITIL definiran kot neznan vzrok enega ali večjega števila incidentov. Glavni namen upravljanja s problemi je preprečiti, da bi se problemi in posledični incidenti zgodili, da se odpravi ponavljajoče se incidente in da se minimizira vpliv incidentov, ki se jih ne more preprečiti. Upravljanje s problemi vključuje aktivnosti, ki diagnosticirajo izvorni vzrok incidenta in določijo rešitev teh problemov. Prav tako je odgovorno za zagotavljanje implementacije rešitev skozi primerne nadzorne procese, še posebej skozi upravljanje s spremembami in upravljanje z izdajami (Release Management). Upravljanje s problemi bo prav tako vzdrževalo informacije o problemih in primernih začasnih rešitvah ter rešitvah, ki so za organizacijo pomembne za zmanjšanje števila in vpliva incidentov skozi čas. Upravljanje s problemi tesno sodeluje z upravljanjem baze znanja in orodji, kot je baza znanih napak. Upravljanje s problemi vključuje dva večja procesa:

Reaktivno upravljanje s problemi, ki se izvaja kot del izvajanja storitev.



Proaktivno upravljanje s problemi, ki je del izvajanje storitev, vendar se izvaja kot del stalnega izboljševanja storitev.

3.3.5 UPRAVLJANJE DOSTOPOV (ACCESS MANAGEMENT) Upravljanje dostopov je proces, ki skrbi, da vsi avtorizirani uporabniki dobijo dostop za uporabo storitve, medtem ko neavtoriziranim uporabnikom preprečuje dostop. Upravljanje dostopov je izvajanje upravljanja razpoložljivosti (Availability Management) in upravljanje informacijske varnosti (Information Security Management). Upravljanje dostopov se lahko sproži preko zahtevka za storitev, poslanega na CPU. Koristi za posel:

Nadzorovan dostop storitev zagotavlja, da lahko organizacija bolj učinkovito vzdržuje zaupnost svojih informacij.

Zaposleni imajo pravi nivo dostopa za učinkovito izvajanje svojih nalog.

Zmožnost pregledovanja uporabe storitev in odkritja zlorab.

Zmožnost enostavnejšega odvzema pravic dostopa, ko je to potrebno.

Morda je potrebno za regulatorno skladnost (npr. SOX, HIPAA, COBIT ipd). 3.3.6 FUNKCIJE V IZVAJANJU STORITVE Nadzor in kontrola (Monitoring and Control) Merjenje in nadzor storitev je zasnovan na stalnem ciklu nadzorovanja, poročanja in kasnejših akcij, saj so te osnova za izvedbo, podporo in izboljšavo storitev. Ta cikel zagotavlja osnovo za določitev strategije, snovanje in testiranje storitev in dosego pomembnih izboljšav. Center za podporo uporabnikom — CPU (Service Desk) CPU je funkcionalna enota določenega števila osebja, odgovorna za ukvarjanje z različnimi storitvenimi dogodki, najpogosteje sporočenimi preko telefona, spletne forme ali preko avtomatsko sporočenih infrastrukturnih dogodkov. CPU je vitalen del oddelka IT in mora uporabnikom predstavljati centralno kontaktno točko (single point of contact). CPU se ukvarja z incidenti in zahtevami za storitve, običajno za vnos in upravljanje tovrstnih dogodkov uporablja specializirana orodja. Korist učinkovitega CPU ne sme biti podcenjena — dober CPU lahko velikokrat kompenzira za slabosti drugod v IT organizaciji, medtem ko lahko slab CPU zakrivi slabo oceno celotnega drugače zelo učinkovitega oddelka IT. Glavni cilj CPU je uporabnikom vzpostaviti normalno stopnjo delovanja storitev kar se da hitro. Tako rešuje tehnične napake, prav tako pa izpolnjuje zahteve po storitvah in odgovarja na vprašanja uporabnikov; kar koli je potrebno, da lahko uporabniki čim hitreje zopet normalno opravljajo svoje delo.



Tehnično upravljanje (Technical Management) Tehnično upravljanje se nanaša na skupine, oddelke ali time, ki nudijo tehnično strokovno znanje in celotno upravljanje IT infrastrukture. Tehnično upravljanje ima dve vlogi:

Skrbništvo nad tehničnim in strokovnim znanjem v zvezi z upravljanjem IT infrastrukture. Tako zagotavlja, da se znanje, potrebno za zasnovo, testiranje, upravljanje in izboljšavo IT storitev, identificira, razvije in izboljša.

Zagotavlja, da so viri učinkovito trenirani in izrabljeni za zasnovo, izgradnjo, tranzicijo, izvedbo in izboljšavo tehnologije, potrebne za izvedbo in podporo IT storitev.

Upravljanje IT operacij (IT Operations Management) Vloga upravljanja IT operacij se definira kot funkcija, odgovorna za stalno upravljanje in vzdrževanje IT infrastrukture organizacije, da se zagotovi izvedba dogovorjene stopnje IT storitev poslu:

Nadzor operacij — nadzor izvedbe in kontrole operativnih aktivnosti in dogodkov v IT infrastrukturi:

o Upravljanje konzol (Console Management) — definiranje centralnih opazovalnih in kontrolnih zmožnosti in uporaba teh konzol za izvedbo opazovalnih in kontrolnih aktivnosti.

o Načrtovanje urnika opravil (Job scheduling) ali upravljanje rutinskih serijskih opravil in skript.

o Varnostno kopiranje in restavriranje podatkov. o Upravljanje tiskalniških poslov. o Izvajanje vzdrževalnih aktivnosti v imenu tehničnih ali aplikacijskih

timov ali oddelkov.

Upravljanje objektov (Facilities management), ki se nanaša na upravljanje fizičnega IT okolja, kot so sistemski prostori ali računalniške sobe in knjižnice za varnostno kopiranje z vsemi potrebnimi napajalnimi in hladilnimi sistemi.

Upravljanje aplikacij (Application Management) Upravljanje aplikacij je odgovorno za upravljanje aplikacij skozi celotni življenjski cikel in ga lahko izvaja katera koli enota, skupina ali tim, ki je vključen v upravljanje in podporo operativnim aplikacijam. Upravljanje aplikacij ima tudi zelo pomembno vlogo zasnove, testiranja in izboljšave aplikacij, ki so del IT storitev, zato je lahko vključeno v razvojne projekte, vendar ni nujno, da je del razvojnih timov aplikacij.



3.4 PREDSTAVITEV PODROČIJ IZGRADNJE IN UPRAVLJANJA UČINKOVITEGA CENTRA ZA PODPORO UPORABNIKOM

Kot smo predhodno zapisali, je glavni cilj CPU vzpostaviti uporabnikom normalno stopnjo delovanja storitev kar se da hitro. Tako rešuje tehnične napake, prav tako pa izpolnjuje zahteve po storitvah in odgovarja na vprašanja uporabnikov; karkoli je potrebno, da lahko uporabniki zopet normalno opravljajo svoje delo. Zakaj pa se potem organizacije odločajo, da znotraj oddelka IT vzpostavijo formalni Center za podporo uporabnikom? Razloge bi lahko združili v sedem glavnih točk (Wooten, 2001):

Uporabnikom nudi prvi in centraliziran kontakt z oddelkom IT. Večina uporabnikov se bo z oddelkom IT prvič in tudi v kasnejših stikih srečevala preko CPU. Zato želimo, da so deležni profesionalne, učinkovite in uspešne storitve, ki vodi v čim večje zadovoljstvo naših strank.

Premošča tehnološki razkorak med uporabniki in »super tehničnimi« sodelavci v IT. Mnogi IT strokovnjaki so znani po tem, da so introvertirani in neprijazni do uporabnikov. CPU omogoča uporabnikom kar se da »uporabniško prijazno« komunikacijo, saj skušajo delovati kot neke vrste prevajalec med uporabnikom in IT strokovnjaki.

Dovoljuje sodelavcem v IT, da opravijo delo, za katero so plačani. CPU kot centralna kontaktna točka omogoča uporabnikom sporočanje incidentov in zahtev, hkrati pa programerjem in specialistom omogoča čim bolj nemoteno opravljanje njihovega dela, saj jih uporabniki ne motijo z zahtevami, kot je npr. ponovna nastavitev gesla.

Zagotavlja sinergijo iz centralizirane organizacije, ki obravnava računalniške težave. CPU lahko sestavlja množica fizično ločenih lokacij, vendar na zunaj uporabnikom daje občutek centralizirane organizacije, saj ima znanja o tehnologiji in programski opremi, s katero delajo uporabniki.

Ustvarja fizično centralizirano zbirko znanj. Takšna baza znanj omogoča agentom dostop do seznama predhodnih problemov in rešitev ter jim pomaga hitreje razreševati ponavljajoče se težave.

Nudi pomoč, ko trenutne računalniške metode za pomoč ne dosegajo pričakovanj. Včasih je bolje zgraditi interni CPU, kot pa da to storitev nudi zunanja firma, ki je npr. dobavitelj specifične programske opreme ali strojne opreme, še posebej če posamezni oddelki niso zadovoljni z njihovo storitvijo.

Pomaga, da se tehnologija uporablja dosledno in usklajeno. CPU agenti ne morejo vsiliti dosledno uporabo tehnologije, lahko pa skozi svoje delo in opažanja opozorijo, kaj deluje in kaj ne deluje, ter to sporočijo uporabnikom ali vodilnim v oddelku IT.

Vzpostavitev CPU je šele prvi korak, izgradnja učinkovitega CPU pa je dolgotrajen in stalen proces, ki se ne sme nikoli ustaviti, tako kot se nikoli ne ustavi razvoj informacijske tehnologije, poslovanje in potrebe organizacije ter delovanje in



naloge posameznikov v organizaciji. Zato si bomo ogledali področja, na katerih mora potekati izgradnja učinkovitega CPU. 3.4.1 DEFINIRANJE PROCESOV CPU Poslanstvo CPU — podobno kot imajo organizacije in podjetja zapisano svoje poslanstvo, tako ima CPU zapisano deklaracijo idealov za organizacijo, kateri vsakodnevno nudi svoje storitve. Poslanstvo je potrebno občasno preveriti in dopolniti, saj se lahko vmes zgodijo občutne spremembe na področju tehnologije, posla ali samih uporabnikov. Definiranje storitev — poslanstvo CPU je lahko zapisano na široko in ne more dobro določati področij delovanja. Zato to definiramo v izjavi o storitvah ali v katalogu storitev, kar določa tudi, kaj CPU ne dela, hkrati pa definira organizacijsko zgradbo CPU ter orodja in druge potrebne vire. Definiranje standardov — definiranje standardnih tehnologij, ki jih bo CPU podpiral pri nudenju pomoči uporabnikom. Tukaj je lahko všteta podpora računalniške, mrežne in tiskalniške opreme, podpora aplikacijam, nabava, priprava in vodenje seznama opreme, zagotavljanje kvalitete storitev, izvajanje sprememb, skratka vse, kar je dogovorjeno s poslom in za kar so podpisane pogodbe (SLA). Določitev ur delovanja — ure delovanja so v večini primerov prilagojene uram delovanja uporabnikov, vendar je pri planiranju potrebno upoštevati ure, kdaj se določeni kritični procesi v organizaciji izvajajo, in razpoložljivost osebja. Preusmerjanje klicev — določitev, na kakšen način pridejo klici v CPU, je ključnega pomena. Klice lahko sprejema celoten CPU, klice lahko sprejema dispečer in jih preusmeri, klice lahko sprejemajo in obravnavajo tehnološki pripomočki in jih nato preusmerijo. Upravljanje z incidenti uporabnikov — uporabniki kličejo CPU z namenom, da bodo dobili rešitev incidenta. CPU mora imeti dobro vzpostavljene procese, orodja in znanja za čim prejšnjo odpravo teh težav, saj je to njegov primarni razlog za obstoj. Zato je ključnega pomena, da se CPU zna kosati z vsem, kar mu bodo uporabniki sporočili v obliki incidenta, zahteve ali vprašanja. Uporabniki si ne želijo, da bi jim podporo nudil CPU, ki ne ve, kaj storiti, ali pa sploh nič ne bo storil. Obveščanje — obveščanje uporabnikov o prihajajočih posodobitvah ali izpadih sistema, status odpravljanja težave, druge novice. Pravočasno sporočene informacije ali novosti preko internih komunikacijskih kanalov lahko kasneje zmanjšajo število klicev in vprašanj s strani uporabnikov. Odgovornosti uporabnikov — komunikacija med uporabniki in CPU mora biti dvosmerna, zato je treba izobraževati uporabnike, kaj se od njih pričakuje za čim boljšo in učinkovito komunikacijo s CPU. Veliko časa, energije in slabe volje se lahko prihrani, če CPU izobrazi uporabnike, kaj točno jim morajo sporočiti ob prijavi točno določenega incidenta. Še več časa in energije pa se lahko prihrani,



če se vlaga v izobraževanje uporabnikov na področjih, kot so uporaba računalniške opreme, uporaba orodij za samopomoč (baze znanja). Odgovornosti oddelka IT — oddelek IT mora biti usklajen, delovati mora kot en tim, tako da lahko njegovo učinkovitost čutijo in vidijo uporabniki, saj je njegova vloga delati in skrbeti za vsa področja delovanja organizacije, definirana v katalogu storitev.

Interna komunikacija — čeprav je glavna usmeritev pozornosti namenjena uporabnikom, ne smemo pozabiti na lastne ljudi, ki morajo biti sproti obveščeni o novostih, spremembah, poročilih delovanja itn. V ta namen se lahko za komunikacijo uporabi elektronsko pošto, sestanke, interni časopis, spletne strani, koledar ipd. 3.4.2 PRORAČUN Pri načrtovanju proračuna je potrebno dobro poznavanje internih organizacijskih pravil, kako se pripravi proračun (pomembno predvsem pri vzpostavitvi novega CPU). V večini primerov proračun ni odobren brez predhodne debate in razprave, zato je potrebno imeti določene strategije in pogajalske sposobnosti, da dobimo odobren delujoč proračun. Pri načrtovanju proračuna je pomembno poiskati tudi odgovore na sledeča vprašanja: Ali proračun na koncu leta ne sme biti presežen ali pa lahko gremo v deficit? Ali nam bo sredstva za proračun zagotovila organizacija ali se bo moral CPU financirati sam preko zaračunavanja svojih storitev? Ali v organizaciji dajejo prednost osebju ali orodjem ali obratno? Kaj je najbolje za organizacijo? V proračun je treba vključiti razne postavke, kot so: zavarovanje, prehrana, pisarniška oprema in potrebščine, pogodbe z zunanjimi partnerji, plače, nagrade, licence za programsko opremo in vzdrževanje, davki, izobraževanja, potovalni stroški, članarine v organizacijah. Tisti, ki financira CPU, želi tudi vedeti, kakšno korist ima od CPU oz. ali bo vrednost storitve odražala vložen denar: povečanje dobička, povečanje produktivnosti, zmanjšanje stroškov, povečanje zadovoljstva uporabnikov. 3.4.3 ORGANIZIRANJE CPU Na organiziranje CPU lahko vpliva več faktorjev, med glavnimi so: širina tehnologije, ki jo bomo podpirali, število uporabnikov, ki jih bomo podpirali, in število agentov, ki so nam na voljo. Velikokrat na žalost na število agentov vpliva faktor, ki smo ga zapisali malo prej. Proračun se ne ozira na število tehnologij in uporabnikov, ki jih podpiramo, tako da je potrebno sprejeti določene kompromise in agentom določiti več vlog in odgovornosti, kot bi bilo sicer potrebno.



CPU se večinoma organizira na dva načina, in sicer z dispečerskim ali razreševalnim pristopom. Pri dispečerski zasnovi uporabniki kličejo 1. nivo podpore, ki poskuša poloviti čim več klicev, agenti na tem nivoju nimajo potrebnih znanj, da rešijo težavo ali vprašanje, klic lahko zabeležijo v neko orodje ali pa tudi ne. Klic preusmerijo na 2. nivo podpore, če pa gre za specifično težavo, pa na 3. nivo podpore (popravilo strojne opreme ali težava s specifično aplikacijo). Dobra lastnost tega pristopa je, da je odgovorjenih veliko klicev uporabnikov, trajanje posameznih klicev je kratko, vendar to ne pomeni, da bodo te težave tudi hitro rešene. Zlahka se lahko zgodi, da čakalna vrsta težav, ki jih je treba rešiti, postane prevelika in neobvladljiva. Na drugi strani pa se uporabniki lahko naučijo, kdo v resnici rešuje njihove težave in začnejo klicati direktno agente na 2. in 3. nivoju ter obidejo 1. nivo podpore, saj se jim ne da govoriti z dvema osebama in dvakrat opisovati isto težavo. Pri razreševalnem pristopu organizacije CPU imamo na 1. nivoju podpore tehnično in analitično visoko usposobljene agente, ki poskušajo težavo uporabnika rešiti že ob prvem klicu. Na 2. nivo podpore se preusmerijo le specifične težave, kot je npr. popravilo strojne opreme ali pomoč pri specifični aplikaciji. Prednost tega pristopa je, da se bodo težave poskušale rešiti že ob prvem klicu in bodo zato rešene hitreje kot pri dispečerski zasnovi. Paziti je le treba, če reševanje traja predolgo, saj lahko zato drugi uporabniki predolgo čakajo, da pridejo na vrsto. Zato je dobro uvesti orodja za avtomatsko distribucijo klicev, za zmanjšanje časa, potrebnega za razrešitev težave, pa razne baze znanj, ekspertne sisteme in orodja za oddaljeni pristop. 3.4.4 OSEBJE CPU CPU agent mora imeti raznovrstna znanja in sposobnosti, da doprinese k uspešnemu in učinkovitemu CPU. Pripravljen je treba imeti opis delovnega mesta, ki olajša iskanje in izbor primernih kandidatov. Dober agent naj bi bil dober v sledečih veščinah: močne komunikacijske sposobnosti, dober poslušalec, sposoben empatije, samomotiviran, energičen in entuziastičen, timski človek, zmožen sprejemati spremembe, sposoben večopravilnosti, sposoben prevzeti odgovornost, dobro logično razmišljanje, prisebnost in splošno razumevanje izdelkov in storitev, ki ji bo podpiral. Z rastjo CPU se pokaže potreba po menedžerjih, ki imajo v osnovi podobne veščine kot agenti, vendar potrebujejo še druge, dodatne veščine: veščine dela z ljudmi, zmožnost videti, kako organizacija uporablja izdelke, ki jih CPU podpira, veščine določanja prioritet, sposobnost odločanja, sposobnost delegiranja, vizija. Določitev optimalnega števila agentov — na število agentov vpliva zasnova organizacije, število klicev oz. zahtevkov, proračun, špice, ki se kažejo v nenadnem povečanju klicev. Agente lahko dodajamo po enega naenkrat (glede na rast potreb), lahko jih najamemo samo za pomoč pri povečanem obsegu dela (špice) ali po N+1 metodi (na podlagi ocene povprečnega dneva osebju dodamo še enega dodatnega agenta).



Osebje CPU mora stalno razvijati analitične in komunikacijske veščine, predvsem pa se mora izobraževati, saj se tehnologija v IT hitro spreminja. Po drugi strani pa je treba spremljati kariero posameznega agenta, saj gredo ti skozi fazo rasti, razvoja in dozorevanja, dokler ne pridejo do točke, ko nam pregorijo; ali ima nekdo sposobnosti, zaradi katerih ostane CPU agent za celotno življenje, ali ima sposobnosti, zaradi katerih napreduje in dobi nove odgovornosti. Vodja mora posvetiti pozornost predvsem tistim agentom, ki lahko pregorijo, njihov učinek upade, do uporabnikov niso več sočutni in profesionalni ter ne sodelujejo več s preostankom tima. Delo v CPU zna biti zelo stresno, še posebej ob dnevih, ko pride do izpada kakšnega pomembnejšega sistema ali storitve, takrat se lahko agenti zlomijo. Bolj kot je stresno okolje ali če proces izbora kadrov ni najboljši, večja je lahko fluktuacija agentov, ostali agenti so pod stresom zaradi uvajanja novih sodelavcev, na splošno kvaliteta storitve CPU upade. Po drugi strani pa mora vodja spremljati razvoj agenta, ki kaže znake napredovanja in preraščanja trenutnega okolja, saj se lahko hitro zgodi, da če agent nima možnosti ali informacije o možnosti razvoja svoje kariere, da bo postal nezadovoljen in si bo poiskal izzive v drugem okolju. Priporočljivo je, da vodje periodično izvajajo t.i. letne pogovore, kjer se s posamezniki pogovorijo o njihovem zadovoljstvu, strahovih, frustracijah in željah za prihodnost. Po drugi strani pa lahko posamezniki od vodje dobijo oceno svojega dela, pripombe in predloge za izboljšave. Vodja mora stalno skrbeti, da so uporabniki deležni profesionalnih storitev in da so njihove zahteve (u)slišane. Zadovoljne uporabnike in učinkovit CPU ustvarja homogen tim, odgovornost vodje je stalno motivirati agente, da kvaliteta storitev na pade. Zato se mora z agenti pogovarjati, občasno izreči pohvalo, ustvariti sproščeno in stimulativno delovno okolje, organizirati dogodke izven službe (skupno kosilo ali večerja, v današnjem času priljubljeni t.i. »tim buildingi«), omogočiti obiske sejmov in seminarjev, skratka, na splošno mora pokazati, da so mu ljudje pomembni. Del odgovornosti pa leži tudi na agentih, saj morajo tudi sami poskrbeti za timsko atmosfero in pomagati sodelavcem pri vsakodnevnem delu ter predvsem v najtežjih trenutkih, ki lahko vodijo v zlom (izgorelost) posameznika. 3.4.5 ORODJA ZA CPU Na povečanje ali zmanjšanje produktivnosti agenta lahko vpliva fizično delovno okolje, v katerem sedi agent. Osvetlitev delovnega prostora, kjer je pravilna mešanica naravne in umetne svetlobe, pravilna razporeditev miz, da svetloba ne sije na monitor, namizna lučka, ki pomaga pri dodatni osvetlitvi (npr. pri natančnih strojnih opravilih, kot je menjava osnovne plošče, ali za lažje branje uporabniških navodil). Primerno delovno mesto: nekateri so mnenja, da jim le ločena pisarna omogoča učinkovito in koncentrirano delo, drugod pa vpeljejo pregrajena delovna mesta, ki



reducirajo hrup, ki nastane ob telefonskih pogovorih z uporabniki, na drugi strani pa onemogoča očesni kontakt in lažjo komunikacijo s sodelavci pri debati ali iskanju rešitve težave. Ponekod je dobro imeti tudi table za pisanje s flomastri (white board), kjer lahko na hitro vpišemo ključne podatke za dnevne operacije ali obvestila ob izpadih ključnih sistemov. Na voljo morajo biti tudi dovolj velike delovne mize za vso opremo agenta: računalnik, monitor, telefon in druga pisarniška oprema. Komunikacijska orodja — najbolj pomembno orodje CPU agenta je telefon, ki je lahko opremljen s slušalkami, saj agent največ časa preživi prav na telefonu. Predvsem zaradi tega je pomembno organizirati usmerjanje klicev v CPU. Pri tem lahko dodelimo vsakemu agentu svojo telefonsko številko, vendar se lahko hitro zgodi, da bodo uporabniki klicali »najboljše« agente, ostali pa bodo brez dela, »najboljši« agenti pa bodo preobremenjeni in se lahko hitro zgodi, da nam bodo pobegnili. Drugi pristop je takšen, da dodelimo agenta, ki mu vedno prvemu zazvoni telefon. Če je zaseden, gre klic na naslednjega agenta. Ta metoda se največkrat uporablja, ko želi menedžer v delo hitro uvesti novega agenta. Slabost te metode pa je v tem, da tisti, ki prvi odgovarja na klice, skoraj nikoli nima odmora. Naslednja metoda je zasnovana na »zakonitosti povprečij«, kjer je klic najprej dodeljen tistemu agentu, ki najdlje čaka na nov klic. Naslednja metoda je kombinacija druge in tretje metode, le da tukaj definiramo primarno skupino agentov, ki odgovarjajo na klice, če pa so vsi zasedeni, potem se klic preusmeri na sekundarno skupino agentov. Glasovna pošta oz. telefonski odzivnik se v današnjem času veliko uporablja, predvsem pa omogoča, da agent, ko ima čas ali ko se vrne na delovno mesto, preveri sporočilo in reši težavo ali jo preusmeri na ustrezno podporno skupino. Mobilni telefoni ali prenosni telefoni, ki pridejo prav še posebej, ko agent odpravlja težave na terenu, saj ga v primeru prijave težave v bližnjem okolišu lahko kontaktiramo in ga pošljemo na odpravljanje naslednje težave. Kot dodaten način lahko vpeljemo elektronsko pošto in spletne obrazce za prijavo težav s strani uporabnikov. Orodje za beleženje incidentov, zahtev in vprašanj je nujno orodje vsakega CPU. Vsebovati mora: podatke o uporabniku, telefonsko številko, njegovo lokacijo in opis težave, kategorizacijo in prioritete težav ter rešitev težave. To je lahko kupljena rešitev ali v hiši narejena rešitev ali preprosta razpredelnica. Oprema in tehnologije CPU agenta — osebni računalnik, ki omogoča agentu vnos prijav v aplikacijo ali seznam, iskanje rešitev v skupni bazi znanja ali na internetu,



povezovanje za oddaljeni pristop na uporabnikov računalnik, komunikacijo z agenti na oddaljenih lokacijah s komunikacijskimi orodji (Skype, Microsoft Lync). Osnovna pisarniška oprema, kot so pisala, notesniki, škarje, selotejp, sponke ipd. Tiskalnik je lahko skupni, mrežni, saj je včasih treba stiskati npr. navodila za reševanje težave ali poročila ali navodila, ki jih damo uporabniku. Skupni prostor — če je možno, lahko uredimo tudi skupni prostor za agente, kamor se lahko umaknejo, vendar so lahko še vedno produktivni. Napolnimo ga z raznim izobraževalnim materialom, kot so priročniki, revije, knjige, brošure, novice ipd. Ta material jim omogoča, da ostanejo v stiku s trendi v IT industriji, da so obveščeni o rezultatih, novostih in usmeritvi organizacije, hkrati pa jim omogoča, da se sprostijo od klicev uporabnikov. Kultura — poskrbeti je treba, da so agenti usklajeni s kulturo organizacije, kar se kaže v oblačenju, pristopu k delu in izobraževanju. CPU mora biti zaveznik poslu, zato naj bo zunanji izgled in delovanje agentov podoben ostalim zaposlenim. 3.4.6 MERITVE UČINKA CPU Vodja CPU mora zavzeti vlogo kontrolorja in stalno preverjati delovanje CPU. Preverjati mora, kako uspešno se CPU spoprijema z zahtevami uporabnikov, kako učinkovit je pri reševanju težav uporabnikov, kakšno je razmerje med stroški in učinkovitostjo CPU ter kolikšna je vrednost CPU v očeh posla. Zato mora CPU stalno poročati o svojem delu, in sicer vodjem, ki so vključeni v vodenje IT storitev, da lahko na podlagi empiričnih podatkov lažje sprejemajo odločitve glede IT storitev in infrastrukture, ki jih uporabljajo naši uporabniki. Po drugi strani pa lahko poročila pripravljamo tudi za naše stranke oz. uporabnike, da jim pokažemo vrednost naše storitve, katere ravni storitve dosegamo na podlagi podpisanih pogodb o storitvah (SLA) in na splošno, kakšni so naši rezultati na ključnih kazalcih delovanja CPU. Periodično (mesečno, četrtletno, polletno, letno) je potrebno preverjati število klicev (tudi po agentih) in število zgrešenih oz. neodgovorjenih klicev, saj s tem dobimo oceno, ali imamo na voljo dovolj osebja. Če uporabljamo orodje za avtomatsko distribucijo klicev, lahko analiziramo povprečen čas, potreben za odgovor na klic, saj dobimo s tem sliko, ali mora uporabnik dolgo čakati na prostega agenta. Analizirano lahko tudi povprečen čas trajanja pogovorov na splošno in po agentih, saj dobimo s tem oceno njihovega znanja in analitičnih sposobnosti. Prav tako je potrebno periodično preverjati število incidentov in zahtev, zato je treba poskrbeti, da je vse vneseno v orodje za upravljanje z incidenti. Podrobneje lahko analiziramo še način sporočanja incidentov in zahtev: telefonski klic, e-pošta, spletni obrazec, osebno ipd. Pomemben podatek je tudi odstotek zahtevkov, ki jih rešimo ob prvi prijavi, saj s tem dobimo oceno usposobljenosti in znanja CPU ter stopnjo težav, ki jih rešujejo naši agenti. Vendar je treba hkrati preverjati tudi, koliko zahtevkov je bilo ponovno odprtih, saj nam to pokaže, da se agenti bolj posvečajo hitrosti reševanja kot pa kvaliteti rešitve, zato nas nezadovoljni uporabniki ponovno kontaktirajo.



Preverjati je potrebno tudi trenutno odprte incidente in zahtevke ter koliko časa so že odprti, in sicer na vseh ravneh podpore. S tem dobimo informacijo, zakaj zahtevki še niso bili rešeni, če so bili pravilno dodeljeni na druge nivoje podpore in katere akcije se bodo izvedle, da se zahtevki dokončno rešijo. Hkrati lahko tudi preverjamo odstotek zahtevkov, ki so bili dodeljeni na druge nivoje podpore. Preverjamo lahko tudi, koliko-krat so zahtevki potovali med prvim in drugimi nivoji podpore. S tem dobimo sliko, ali imajo agenti na prvem nivoju dovolj znanja in veščin in če dovolj kvalitetno opremijo zahtevke z vsemi potrebnimi podatki. Pomembne so tudi analize, ki preverjajo, kolikšen je bil povprečni čas reševanja zahtevkov glede na njihovo prioriteto, saj se morajo incidenti z visoko prioriteto rešiti v čim krajšem času. Preverjamo lahko, kolikšen je bil povprečni čas reševanja glede na kategorizacijo in tip storitve, saj dobimo s tem oceno, na katerih področjih imajo naši uporabniki največ težav. Pomembno je tudi preverjati, če nas uporabniki kličejo zaradi težav, ki so posledica slabo izvedenih ali spodletelih sprememb kot del procesa upravljanja s spremembami. Preverjati je potrebno tudi odzive naših uporabnikov, še posebej če naše orodje za upravljanje z incidenti avtomatsko razpošilja ankete ob rešeni težavi. Priporočljivo je tudi periodično izvesti javnomnenjske ankete zadovoljstva uporabnikov z našim delom in storitvami. 3.4.7 PROMOCIJA CPU CPU moramo obravnavati kot posel. CPU ima izdelke in storitve, ki jih prodaja. Stranke jih ne bodo kupile, ker CPU obstaja. Iz istega razloga ga vodstvo ne bo finančno podprlo. Svojim strankam in vodstvu moramo stalno kazati in dokazovati, kaj nudimo. Stalno moramo skrbeti za našo podobo, da smo vredni zaupanja in da je naša storitev vredna zaupanja. Ustvariti moramo podobo o profesionalnem in storitveno usmerjenem storitvenem centru, ki strankam in vodstvu nudi storitve na visokem nivoju z dodano vrednostjo. Svoje stranke obvešča o standardnih procedurah in tehnologijah, nudi stalna izobraževanja in odgovore na najbolj pogosta vprašanja ter obvestila o prihajajočih spremembah s področja tehnologije.



4 POSNETEK STANJA 4.1 PREDSTAVITEV OKOLJA Opazovana organizacija je del mednarodne korporacije, tako da se v njej uporabljajo globalno standardizirani procesi, globalno standardizirana strojna oprema (namizni in prenosni računalniki, monitorji, tiskalniki, mobilni aparati, strežniška, mrežna in tiskalniška infrastruktura) in globalno standardizirano informacijsko in aplikativno okolje, zasnovano predvsem na Microsoft, Oracle, Unix in Citrix platformi. Ker ima organizacija tudi razvojno in proizvodno ter trženjsko dejavnost, se uporablja tudi razna lokalna strojna oprema in programska orodja.

Enoto informacijske tehnologije v opazovani organizaciji sestavlja več oddelkov (slika 3), ki skrbijo za infrastrukturo (del tega oddelka je tudi CPU), nudijo podporo poslovnim aplikacijam, podporo spletnim aplikacijam, podporo proizvodnim funkcijam, ERP podporo in skrbijo za informacijsko varnost. Enota informacijska tehnologija ima izdan katalog storitev, svoje storitve drugim enotam nudi preko podpisanih pogodb (SLA — Service Level Agreement), podpora uporabnikom je na voljo 365/24/7.

Enota

informacijska tehnologija

Oddelek

infrastruktura

Oddelek

podpora poslovnim aplikacijam

Oddelek

podpora spletnim aplikacijam

Oddelekpodpora proizvodnim

funkcijam

OddelekERP podpora

Oddelek

informacijska varnost

Slika 3: Organizacijska shema enote informacijska tehnologija.



Oddelek infrastrukture skrbi za strežniško, mrežno in tiskalniško opremo, računalniško opremo uporabnikov (namizni in prenosni računalniki, monitorji, periferija) in mobilno opremo (mobilni aparati, tablice in mobilne internetne dostopne točke). V oddelek infrastrukture organizacijsko spada tudi center za podporo uporabnikom. CPU predstavlja centralno vstopno točko za okoli 4.500 uporabnikov iz skoraj 20 držav. Deluje po globalnih standardiziranih procesih, ki so zasnovani po ITIL, za lokalno specifične procese pa uporablja lokalne splošne postopke in interna navodila, ki so prav tako zasnovana po ITIL. Pri svojem delu se srečuje predvsem z izvajanjem storitev (Service Operations) in procesi znotraj tega procesa: upravljanje dogodkov (Event Management), izpolnjevanje zahtev (Request Fulfilment), upravljanje z incidenti (Incident Management), upravljanje s problemi (Problem Management), upravljanje dostopov (Access Management), upravljanje opreme (Asset Management). CPU je kot centralna kontaktna točka za uporabnike dosegljiv preko unikatne telefonske številke in spletnega obrazca, uporabniki, ki jim na telefon ne uspe dobiti agenta, pa lahko pustijo sporočilo na telefonskem odzivniku. Za beleženje težav in zahtev uporabnikov agenti uporabljajo globalno orodje BMC Remedy, ki je zasnovano po ITIL. Podpora uporabnikom se nudi na treh nivojih (slika 4):

1. nivo podpore — HelpDesk

2. nivo podpore — 2. nivo podpore za aplikacije in tehnične sisteme

3. nivo podpore — zunanji izvajalci in IT vodstvo

Uporabniki

HelpDesk

2. nivo podpore za aplikacije

2. nivo podpore za tehnične sisteme

Zunanji izvajalci

IT vodstvo

1. nivo podpore

2. nivo podpore

3. nivo podpore

Slika 4: Nivoji podpore v CPU.



Posamezne vloge v procesu podpore uporabnikom so sledeče: Na uporabnika vpliva incident, zato kontaktira CPU. CPU kot centralna kontaktna točka nudi 1. nivo podpore (HelpDesk) in obravnava incidente, sporočene s strani uporabnikov, običajno pomagajo uporabnikom rešiti tehnične in ne-tehnične incidente v zvezi s standardno računalniško strojno in programsko opremo. 2. nivo podpore za aplikacije pomaga poslovni organizaciji in CPU agentom rešiti incidente, ki so v glavnem povezanimi s konfiguracijami in poslovnimi aplikacijami. 2. nivo podpore za tehnične sisteme pomaga pri reševanju incidentov, povezanih z IT infrastrukturo in IT varnostjo. 3. nivo podpore izvajajo zunanji izvajalci ali IT vodstvo. Zunanji izvajalci so odgovorni za vzdrževanje in nameščanje računalniške opreme in sistemov. V primeru, da rešitev incidenta ni v okviru standardnih ali znanih procedur, lahko CPU agenti incident posredujejo IT vodstvu, ki prvenstveno definira rešitev (vendar jo ne izvrši). Incident se posreduje agentom na primernem nivoju podpore, da izvršijo rešitve. 1. NIVO PODPORE (HELPDESK) Ker se diplomska naloga ukvarja z izboljšavami delovanja 1. nivoja podpore CPU (HelpDesk), si oglejmo, kako je ta organiziran in zasnovan (slika 5); trenutno 1. nivo podpore v CPU sestavlja sedem agentov. Med njimi jih šest opravlja vlogo agenta, eden pa opravlja vlogo koordinatorja CPU (koordinator ekipe in vsakodnevnih operacij) in vlogo agenta, nad delom CPU pa bedi vodja CPU.

Vodja CPU

Koordinator CPU

CPU agenti

Slika 5: Organiziranost CPU.



Vloge in odgovornosti CPU agenta so:

Sprejem telefonskih klicev in obdelava ostalih prijav s strani uporabnikov.

Zbere vse potrebne informacije v zvezi z incidentom, odpre, klasificira in shrani nalogo v aplikaciji za upravljanje z incidenti, definira prioriteto in datum rešitve (glede na prioriteto). Če je potrebno, poišče ujemanje incidenta med obstoječimi incidenti v bazi znanja (Knowledge Database). Nudi prvotno podporo in diagnozo ter vodi incident k rešitvi glede na raven storitve in/ali glede na dogovorjen datum razrešitve. Zapiše rešitev incidenta v aplikacijo za upravljanje z incidenti in v primeru upravičenega razloga tudi v bazo znanja.

Če je potrebno, posreduje incident primerni skupini na 2. nivoju podpore (za incidente, povezane z aplikacijami, 2. nivoju podpore za aplikacije in za incidente, povezane s tehničnimi sistemi, 2. nivoju podpore za tehnične sisteme).

Če je potrebno izvršiti vzdrževanje računalniške strojne ali programske opreme, posreduje incident zunanjemu izvajalcu na 3. nivo podpore.

Posreduje resne probleme z reševanjem incidenta IT vodstvu na 3. nivoju podpore.

Vloge in odgovornosti koordinatorja CPU so:

Vse vloge in odgovornosti CPU agenta.

Dnevni pregled trenutno odprtih incidentov, opozarjanje in usmerjanje agentov k rešitvi incidentov.

Priprava statističnih poročil dela CPU.

Priprava razporeda dežurstev. Vloge in odgovornosti vodje CPU so:

Odgovoren za učinkovito in uspešno upravljanje z incidenti z vodenjem in nadzorom osebja, ki je odgovorno za upravljanje z incidenti.

Pridobiva in analizira informacije s področja upravljanja z incidenti z namenom iskanja in odprave vzroka.

Obvešča in poroča IT vodstvu, kar zagotavlja kakovostno analizo trendov, če je le možno, vezano na aplikacijo oz. sistem.

Ponavljajoči dogodki in trendi se ugotavljajo z rednim pregledovanjem seznama incidentov. O rezultatih se obvesti IT vodstvo.

CPU je fizično prisoten na sedežu organizacije med 6. in 16. uro, s tem da en agent stalno opravlja jutranje dežurstvo med 6. in 7. uro (samo delovni dnevi), ostali agenti pridejo na delo med 7. in 8. uro. Odhod iz delovnega mesta je med 15. in 16. uro. Med delovnim časom se opravljajo še ostala dežurstva, in sicer je en agent stalno prisoten (samo delovni dnevi) na proizvodni lokaciji na sedežu podjetja, en od agentov opravlja celotedensko dežurstvo (samo delovni dnevi) na lokaciji okoli 20 kilometrov izven sedeža organizacije (to dežurstvo opravlja pet agentov, ki se jih rotira). Med 16. uro in 6. uro zjutraj naslednjega dne se izvaja popoldansko dežurstvo, popoldansko dežurstvo opravlja vseh sedem agentov, in sicer se jih rotira, dežurstvo pa traja cel teden (sedem dni, od ponedeljka od 16. ure do naslednjega ponedeljka do 6. ure), tisti, ki opravlja popoldansko dežurstvo določen teden, je fizično prisoten na lokaciji do 16. ure, potem so klici preusmerjeni na mobilni telefon. Grafični prikaz organiziranosti CPU skozi delovni dan prikazuje slika 6.



Slika 6: Razpored dežurstev in vlog agentov.

Glede na to, da predstavlja CPU na sedežu organizacije vstopno kontaktno točko za uporabnike iz skoraj 20 držav, so na posameznih lokacijah postavljeni t.i. IT koordinatorji, ki so lahko usposobljeni IT strokovnjaki ali poslovni sekretarji/poslovne sekretarke ali zaposleni z »žilico« za IT. Njihova naloga je predvsem omejena na pomoč pri distribuciji, namestitvi ali pobiranju računalniške opreme in pri reševanju incidentov, ki jih CPU ne more rešiti na daljavo, v tem primeru ti ljudje delujejo kot t.i. podaljšane roke in noge (»hands & feet«) CPU agentov. CPU uporablja za beleženje težav in zahtev uporabnikov globalno orodje BMC Remedy, ki je zasnovano po ITIL. BMC Remedy je modularno zasnovan, in sicer vsebuje za potrebe opazovane organizacije sledeče glavne module: upravljanje z incidenti, upravljanje s problemi, upravljanje s spremembami, upravljanje z zahtevami, baza znanja, upravljanje opreme (Asset Management), upravljanje zahtev po storitvi (Service Request Management); to so vnaprej pripravljene šablone za sporočanje incidentov (npr. prijava napak, zahteva za restavriranje podatkov) in zahtev (naročilo dodatnega računalnika, aktivacija mrežnega priključka, namestitev ali vračilo strojne opreme ipd.), modul za analizo in poročila (slika 7).



Slika 7: Izgled začetne strani in modulov v BMC Remedy (www.zdnet.com, 2014).

Podporne skupine v BMC Remedy so organizirane glede na lokacijo (globalna podpora, podpora na državnem ali lokalnem nivoju) ali glede na vsebino (podpora za specifično aplikacijo, strojno opremo ali proces). Orodje omogoča, da se v obstoječe incidente (slika 8) in zahteve dodajajo komentarji, priponke in da se jih enostavno dodeli v reševanje katerikoli podporni skupini znotraj korporacije. Na globalnem nivoju so v orodju BMC Remedy nastavljena avtomatska sporočila o kršitvi pogodbe o storitvi (SLA breach), ki so zasnovana na podlagi prioritete incidenta ali vsebine incidenta (npr. incident za ponovno nastavitev gesla ali odklepanje uporabniškega računa).

Slika 8: Izgled in ostale funkcije incidenta v BMC Remedy (www.grafixoft.com, 2014).



Pri svojem delu CPU uporablja tudi skupno mrežno mapo, kjer so na voljo predvsem razna navodila, gonilniki računalnikov, tiskalnikov, skenerjev in razni avtorizacijski obrazci. Vzpostavljeno ima tudi skupno timsko spletno stran, ki je zasnovana na Microsoft SharePoint platformi. Timska spletna stran vsebuje Wikipedijo (bazo znanja), povezave do ključnih orodij, portalov in informacij, razporede dežurstev, poročila o popoldanskih dežurstvih, koledar odsotnosti, zapisnike kolegijev, statistična poročila, opravila (Tasks), obvestila (Announcements) in ključne dokumente, potrebne za delo (pravilnik, splošni postopki in interna navodila). Za sprejem klicev uporablja CPU orodje COCOS Call.Center podjetja CDE, d. o. o., iz Ljubljane, glavne funkcionalnosti tega orodja so avtomatsko in inteligentno razporejanje klicev, avtomatska identifikacija klicočega, glasovna pošta in analitika vstopnih klicev in učinkovitosti operaterjev. COCOS Call.Center je zgrajen modularno, tako da uporabniku omogoča izbor posameznih funkcionalnih sklopov glede na potrebe. Programska rešitev ima za osnovo COCOS strežnik kontaktnega centra, ki teče na Microsoft Windows Server platformi in izvaja nadzor nad uporabniki in v navezi s podatkovnimi bazami usklajuje aktivnosti in procese med uporabniki in posameznimi funkcionalnimi moduli. CPU agenti kot glavno orodje uporabljajo aplikacijo COCOS klient kontaktnega centra, ki je nameščena lokalno na delovno postajo agenta. Maska (slika 9) omogoča nastavljanje statusov agentov (sprejem klicev, odmor in delo na terenu), spremljanje zgodovine klicev, število agentov, prijavljenih v aplikacijo, in njihove statuse ter pošiljanje sporočil znotraj skupine agentov.

Slika 9: Pogled na masko COCOS klienta kontaktnega centra (Opazovana organizacija, 2014).

Vodja CPU in koordinator CPU pri svojem vsakodnevnem delu uporabljata aplikacijo COCOS administrator klicnega centra (slika 10), kjer lahko dobita razne uporabne informacije na dnevnem, mesečnem ali poljubnem obdobju glede klicev in agentov.



Slika 10: Pogled na masko in funkcionalnosti COCOS administratorja klicnega centra (CDE, 2014).



4.2 MODEL PROCESA Reševanje incidentov in zahtev uporabnikov v opazovani organizaciji se izvaja po lokalnem splošnem postopku za upravljanje z incidenti (Incident Management). Po ITIL so incidenti (Incidents), ki se zgodijo kot rezultati okvar ali napak v okviru standardne računalniške strojne in programske opreme, posledica dejanskih ali možnih odklonov od načrtovanega delovanja omenjene opreme. Incidente ocenjujemo glede na vpliv, tako dejanski kot tudi potencialni, ki jih imajo na nudene storitve uporabnikom (the business services). Vzrok za incident nam je lahko očiten in se mu lahko posvetimo brez nadaljnjega poizvedovanja, tako da izvedemo popravilo, začasno rešitev (workaround) ali pa zahtevo za spremembo (a change request), da odstranimo napako. V teh primerih se lahko reševanja incidenta (tj. vpliva ali možnega vpliva na stranko) lotimo zelo hitro, morda tudi brez neposrednega iskanja izvornega vzroka incidenta (the underlying cause of the incident), tj. problema (the problem). V drugih primerih se problem označuje kot izvorni vzrok za incident (the underlying cause of the incident) in kazalec za neznano napako, zato ga je potrebno identificirati. Rezultat uspešne rešitve problema je identificiranje izvorne napake (underlying error), ko pa odkrijemo začasno rešitev in/ali razvijemo zahtevo za spremembo (a change request — CR), se lahko problem spremeni v znano napako (a known error). Če pogledamo posplošeno (slika 11), je incident (Incident) vsak dogodek, ki ni del standardnega delovanja storitve in ki povzroči ali lahko povzroči prekinitev (an interruption) ali znižanje (a reduction) kakovosti te storitve. Problem (Problem) je po drugi strani neznan izvorni vzrok (the unknown underlying cause) enega ali več incidentov, znana napaka (Known Error) pa je uspešno diagnosticiran problem, za katerega poznamo začasno rešitev. Napaka

Incident(i) Problem Znana napaka Rešitev

CR

Slika 11: Povezava med upravljanjem z incidenti, upravljanjem s problemi in upravljanjem s spremembami.

Postopek reševanja incidentov v opazovani organizaciji je prikazan z diagramom poteka na sliki 12. Ko uporabnik kontaktira CPU, CPU agentu na 1. nivoju podpore v primeru, ko ne gre za incident, v smislu reševanja incidenta ni potrebno nič narediti, uporabniku posreduje potrebne informacije oz. mu svetuje. Če se izkaže potreba po novi storitvi, se zahteva posreduje timu za upravljanje z zahtevami. V primeru incidenta agent zbere vse potrebne informacije, odpre nalogo v globalni aplikaciji za upravljanje z incidenti in nalogo klasificira. Uporabnik je avtomatsko obveščen o odprtju naloge. CPU agent diagnosticira incident in ugotovi, če ga lahko reši. Če incident lahko reši, definira njegovo rešitev, če incidenta ne more rešiti, zbere vse informacije o njem ter zapiše vse korake dotedanjega reševanja incidenta v odprto nalogo.



Slika 12: Postopek reševanja incidentov (opazovana organizacija, 2014).

Nalogo lahko posreduje primerni skupini na 2. nivoju, in sicer za incidente, povezane z aplikacijami, 2. nivoju podpore za aplikacije ali za incidente,



povezane s tehničnimi sistemi, 2. nivoju podpore za tehnične sisteme ali 3. nivoju podpore, če je potrebno izvršiti vzdrževanje računalniške strojne ali programske opreme. V kolikor potrebujejo dodatne informacije, lahko 2. nivo podpore ali 3. nivo podpore kontaktira agente na 1. nivoju podpore. V kolikor se v danem trenutku incidenta ne da rešiti, se v dogovoru z uporabnikom reševanje incidenta odloži na kasnejši datum. Če se skozi postopek reševanja incident definira kot problem, se ga posreduje timu za upravljanje s problemi. Če se kot rešitev incidenta pojavi potreba po spremembi, se to zahtevo posreduje timu za upravljanje s spremembami. Ko je naloga rešena, se rešitev zapiše v nalogo v globalni aplikaciji za upravljanje z incidenti. Če se pokaže upravičena potreba, agent rešitev zapiše v bazo znanja. Ob zaprtju naloge je uporabnik avtomatsko obveščen, da je bila ta rešena. Po 15 dneh je naloga avtomatsko zaključena (to velja le za incidente), v vmesnem času lahko uporabnik zahteva ponovno odprtje naloge in zahteva ponovno reševanje njegove težave. Glede na zbrane informacije ob prijavi incidenta s strani uporabnika, se incidenti klasificirajo s sledečimi prioritetami in zahtevajo sledeče reakcijske čase za odpravljanje incidenta (tabela 1): Tabela 1: Prioritete incidentov in reakcijski časi.

Prioriteta Opis Reakcijski čas

1 — kritično Odpoved strežnika (napaka na strojni ali programski opremi strežnika).

V 15 minutah.

2 — visoka Napake, ki vplivajo na poslovni proces (strojna ali programska napaka).

Maks. 1 ura.

3 — srednja Napake, ki ne vplivajo bistveno na poslovni proces.

Maks. 2 uri.

4 — nizka Napake, ki ne vplivajo na poslovni proces.

V dogovoru z uporabnikom.

CPU je organiziran po razreševalnem pristopu, in sicer so na 1. nivoju podpore tehnično in analitično visoko usposobljeni agenti generalisti (vsak naj bi vedel vse), ki poskušajo težavo uporabnika rešiti že ob prvem klicu. V zdajšnji situaciji je pristop CPU k reševanju incidentov in zahtev predvsem reaktiven: ko uporabnik sporoči zahtevo, se prijavo diagnosticira, se jo zavede v globalno orodje za upravljanje z incidenti in poskuša takoj rešiti. Večino zahtev se da rešiti telefonsko ali z oddaljenim pristopom na uporabnikov računalnik, če je potrebno osebno posredovanje na sedežu organizacije, uporabnika obišče agent, ki je sprejel zahtevo, za ostale lokacije se naloga dodeli agentu ali IT koordinatorju.



Trenutni dogovor je, da morata biti v pisarni vedno vsaj dva agenta, ki odgovarjata na telefonske klice in poskrbita za uporabnike, ki se zglasijo v CPU osebno. Zaradi tega se lahko zgodi, da če sprejmeta klic, ki zahteva osebno posredovanje, se to posredovanje lahko zavleče. CPU na 1. nivoju podpore mesečno dobi okoli 4.000 do 6.000 klicev, nanje jim jih uspe odgovoriti okoli 3.000 do 4.000, v globalno orodje za upravljanje z incidenti pa agenti na vseh nivojih podpore vpišejo okoli 3.000 do 4.000 incidentov in zahtevkov. Rezultate CPU agentov na 1. nivoju podpore se meri na mesečnem nivoju, in sicer po sledečih kriterijih:

vsaj 85 % incidentov mora biti rešenih v istem dnevu,

razmerje med vpisanimi nalogami v BMC Remedy in odgovorjenimi telefonskimi klici mora biti vsaj 75 %,

rezultati anket zadovoljstva s strani uporabnikov. Vodja CPU enkrat tedensko izvaja kolegij CPU (v času njegove odsotnosti ga nadomešča koordinator CPU), kjer se z ekipo pogovori o prihajajočih spremembah in novostih, izpostavi probleme in posluša predloge in pripombe ter preveri izvajanje tekočih nalog in zadolžitev. Vsak agent mora ob koncu delovnega tedna poslati tedensko poročilo, kjer zapiše specialne naloge, opravljene v tekočem tednu, naloge, ki jih ima odprte za naslednji teden, pripombe, predloge in spisek izpadov pomembnejših sistemov in storitev v tekočem tednu. Koordinator CPU na podlagi vseh poročil za vodjo CPU pripravi skupno poročilo, to poročilo potem vodja CPU pošlje ključnim vodjem oddelkov znotraj IT.



4.3 DEFINICIJA KLJUČNIH KAZALCEV PROCESA IN MERITVE OBSTOJEČEGA PROCESA

Kot smo že v uvodu zapisali, se opazovani CPU v zadnjih letih spoprijema s povečanim številom telefonskih klicev s strani uporabnikov. Zaradi porasta telefonskih klicev se je tudi povečalo število neodgovorjenih telefonskih klicev, kar je razvidno iz spodnje slike (slika 13), saj se je po grobi oceni število neodgovorjenih klicev dvignilo z okoli 10.000 na okoli 17.000.

Slika 13: Število vstopnih klicev in odgovorjenih klicev med leti 2007 in 2012.

Deloma so razlogi za občutno povečanje števila vstopnih klicev večje spremembe v tehnologiji, in sicer prehod iz MS Office XP na MS Office 2010, prehod iz MS Windows XP okolja na MS Windows 7 okolje in prehod iz Lotus Notes poštnega sistema na MS Outlook poštni sistem. Posledično so uporabniki zaradi tega imeli več težav in vprašanj z uporabo teh orodij, ki so jih naslovili na CPU, kot je razvidno iz grafa, predvsem telefonsko. Drugi razlog za to pa so menjave agentov na 1. nivoju podpore, predvsem so se leta 2012 CPU pridružili trije novi člani. Povprečna uvajalna doba za novega agenta, da lahko deluje kolikor toliko samostojno, je v opazovani organizaciji 3 mesece.



V tabeli 2 si lahko ogledamo število vstopnih, odgovorjenih in zgrešenih klicev po mesecih, pozitivna informacija je le to, da agentom uspeva iz leta v leto dvigniti število odgovorjenih klicev. Tabela 2: Primerjava števila vstopnih klicev in odgovorjenih klicev med letoma 2011 in 2012.

V tabeli 3 je razvidno število klicev, kjer so uporabniki pustili sporočilo na avtomatskem odzivniku (stolpec avtomatski odzivnik), in koliko klicev so uporabniki prekinili že po 5 ali 10 sekundah, preden se jim je na telefon oglasil agent. Tabela 3: Primerjava števila sporočil, puščenih na avtomatskem odzivniku, in prekinjenih klicev v 5 in 10 sekundah med letoma 2011 in 2012.

Iz zgornje tabele je razvidno, da se malo uporabnikov odloči pustiti sporočilo na avtomatskem odzivniku, da jim je ljubši pogovor z agentom kot s strojem. Prav tako malo uporabnikov prekine po prvih desetih sekundah, in sicer slišijo v tem času pozdravno sporočilo in v primeru, da so vsi agenti zasedeni, slišijo sporočilo, da trenutno ni na voljo nobenega operaterja.



V tabeli 4 je razvidno število klicev, kjer so uporabniki klice prekinili po 30 ali 60 sekundah, preden se jim je na telefon oglasil agent. Po teh številkah bi lahko sklepali, da so uporabniki kar potrpežljivi, da kar nekaj časa čakajo, da bi se jim na telefon oglasil agent. Tabela 4: Primerjava števila prekinjenih klicev v 30 in 60 sekundah med letoma 2011 in 2012.

Tabela 5 predstavlja dejansko število zgrešenih klicev in kolikšen je ta odstotek glede na vse vstopne klice. To število se izračuna po sledeči enačbi: zgrešeni klici = vstopni klici – odgovorjeni klici – klici, prekinjeni v 10 sekundah – avtomatski odzivnik Tabela 5: Primerjava števila zgrešenih klicev med letoma 2011 in 2012.



Tabela 6 predstavlja povprečni čas pogovora med agentom in uporabnikom (povprečje se računa na vsak uspešen klic). Iz tabele je razvidno, da traja povprečen pogovor slabe tri minute in pol, v zadnjem četrtletju se je občutno povečal, kar sovpada z nastopom dela dveh oz. treh novih agentov. Tabela 6: Primerjava povprečnega časa pogovora v sekundah med letoma 2011 in 2012.

Tabela 7 predstavlja povprečno trajanje klica od vzpostavitve do prevezave na agenta (v ta čas so všteta vsa pozdravna sporočila, vrsta, najava agenta in čas prevezave klica z odzivnika na agenta). Povprečje se računa na vsak klic, ki je prišel do agenta (brez klicev, ki so bili obdelani in zaključeni na odzivniku, in brez neodgovorjenih klicev). Tabela 7: Primerjava povprečnega časa čakanja pogovora v sekundah med letoma 2011 in 2012.



Tabela 8 prikazuje povprečni čas čakanja strank v vrsti, in sicer samo za neodgovorjene (izgubljene) klice. Tabela 8: Primerjava povprečnega časa čakanja v vrsti v sekundah med letoma 2011 in 2012.

Tabela 9 prikazuje stopnjo uspešnosti kontaktnega centra. Iz tabele je razvidno, da se je uspešnost iz leta 2011 do leta 2012 v povprečju dvignila, razlog za to bi iskali v večjem številu odgovorjenih klicev in manjšem številu zgrešenih klicev. Tabela 9: Primerjava stopnje uspešnosti kontaktnega centra med letoma 2011 in 2012.



Tabela 10 prikazuje primerjavo rešenih nalog med posameznimi agenti. Iz tabele je razvidno, da dva občutno izstopata po absolutnih številkah, deloma tudi pri povprečnih številkah. Za ostale bi bilo treba opraviti podrobnejšo analizo glede njihove usposobljenosti in koliko časa jim vzamejo posebej dodeljene naloge. Tabela 10: Primerjava opravljenih delovnih dni in rešenih nalog po agentih med letoma 2011 in 2012.



Tabela 11 prikazuje število nalog, ki jih je odprl oz. zabeležil posamezen agent v orodju za upravljanje z incidenti BMC Remedy. V to so vštete naloge, ki jih je sam rešil ali naslovil v reševanje na druge agente na katerem koli nivoju podpore. Zopet občutno izstopata dva agenta po absolutnih številkah, ostali agenti pa so v bledem povprečju. Tabela 11: Primerjava odprtih nalog po agentih med letoma 2011 in 2012.



Tabela 12 prikazuje število odgovorjenih klicev po posameznih agentih. V letu 2011 je vidno, da je izstopal agent 4, zaradi česar je bil zamenjan z agentom 8, ki je v letu 2012 dosegal dobre rezultate. V letu 2012 so se pridružili trije novi agenti, med katerimi je agent 9 hitro dosegal podobne rezultate kot »stari mački«, agent 11 pa je ravno začel z uvajanjem v decembru 2012. Agent 10 ima slabše rezultate zato, ker je njegova prvenstvena naloga podpora proizvodnji, šele na drugem mestu je odgovarjanje klicev. Tabela 12: Primerjava odgovorjenih telefonov po agentih med letoma 2011 in 2012.



Naslednja tabela (tabela 13) prikazuje enega od kriterijev, po katerih se ocenjuje agente, in sicer razmerje med odprtimi oz. zabeleženimi nalogami v orodju za upravljanje z incidenti BMC Remedy in odgovorjenimi klici. Dogovor je, da mora biti ta odstotek nad 75 %, iz tabele je razvidno, da ga kar nekaj agentov ne dosega na letnem nivoju. Iz tega lahko sklepamo, da se veliko število klicev sploh ne zabeleži v orodje. Zaradi tega celoten CPU in ostale podporne skupine ter oddelek informacijske varnosti ne more dobiti prave slike ob periodičnih pregledih, kaj se dogaja oz. s kakšnimi težavami ali zahtevami se srečujejo uporabniki. Tabela 13: Primerjava razmerja med odprtimi nalogami in odgovorjenimi klici po agentih med letoma 2011 in 2012.



Tabela 14 prikazuje drugega od kriterijev, po katerih se ocenjuje agente, in sicer odstotek rešenih incidentov v istem dnevu, ki mora biti nad 85 %. Iz tabele je razvidno, da ga večina agentov ne dosega na letnem nivoju. V navezavi s prejšnjo tabelo bi lahko rekli, da če bi se potrudili pri vpisu vseh nalog, bi vsi agenti zlahka dosegali ta kriterij. Tabela 14: Primerjava odstotka rešenih nalog v istem dnevu po agentih med letoma 2011 in 2012.



Tabela 15 kaže povprečni čas reševanja incidentov po agentih, ki se računa kot razlika med datumom in uro zaprtja incidenta in datumom in uro odprtja incidenta. Tabela 15: Povprečni čas reševanja incidentov po agentih v letih 2011 in 2012.

V letu 2011 je skupno povprečje CPU večje od enega dneva, v letu 2012 pa znaša nekaj več kot 1,5 delovnega dneva. V letu 2011 predvsem izstopa agent 4, ki je bil zaradi slabih rezultatov na večjem številu področij zamenjan z agentom 8. Skupno povprečje v letu 2012 je še vedno preveliko, saj kaže, da naj bi agenti incidente zaključevali naslednji delovni dan.



5 PREDLOGI ZA SPREMEMBE PROCESOV

5.1 PRERAZPOREDITEV NALOG MED AGENTI CPU je organiziran po reševalnem konceptu, vsi agenti pa naj bi imeli podobna, če ne že enaka znanja (generalist) z vseh področij delovanja CPU. Ob prijavi incidenta ali zahteve poskuša CPU agent rešiti nalogo sam, če je potrebno osebno posredovanje pri uporabniku, ga obišče, razen če se uporabnik nahaja na lokaciji, ki je agent ne pokriva (proizvodnja, druge lokacije izven sedeža organizacije). Omenili smo, da se je vsa leta poskušalo CPU agente usposabljati v smeri, da naj bi vsak agent vse vedel oz. bil pri svojem delu generalist. V realnosti pa se je dogajalo, da če so uporabniki klicali zaradi specifičnih težav ali vprašanj, so agenti z manj znanja vedno za pomoč spraševali enega ali več določenih agentov, ki so imeli več znanja s tega področja. Eden od takih primerov so vprašanja, kako točno se uporabljajo določene funkcije v MS Excel, ki so jih naslavljali agentu, ki je velikokrat vodil izobraževanja s področja MS Office. Drugi takšen primer je, da so vprašanja v zvezi z uporabo mobilnega aparata iPhone preusmerili na agenta, ki ima tudi sam takšen aparat. Še eden od takih primerov je, da so agenti s krajšim delovnim stažem začeli z delom v CPU po migraciji poštnega sistema Lotus Notes v MS Outlook, tako da so jim pri reševanju pomagali kolegi, ki so še iz »obdobja« Lotus Notes. Takšnih primerov je še več, zato se je v CPU uvedel t.i. »SuperUser« koncept. Identificiralo se je ključne aplikacije, storitve, produkte in procese, ki jih je po zadnjem štetju 23. »SuperUser« je v tem primeru postal agent, ki ima več specifičnega znanja z nekega področja kot ostali agenti, ali pa se mu je dodelilo »skrbništvo« nad določenim področjem, da je skupno število področij kar se da enakomerno razporejeno med vsemi agenti. Ob vpeljavi »SuperUser« koncepta se je področja dodelilo agentom (glej tabelo 16), in sicer se je skoraj za vsako področje določilo dva agenta, ki sta en drugemu namestnika v primeru odsotnosti. Naloga agentov v tem začetnem obdobju je bila zbrati vse aktualne informacije in navodila s teh področij, se izobraziti in jih dodati v Wikipedijo CPU. V primeru, da je uporabnik podal zahtevo z določenega področja in jo je sprejel agent, ki ni najbolj podkovan na tem področju, je lahko rešitev poiskal v Wikipediji, lahko je za pomoč povprašal »SuperUserja« tega področja ali mu preprosto predal nalogo v reševanje. Naloga »SuperUserja« po začetnem obdobju je sedaj takšna, da se agenti redno izobražujejo s področja, ki ga pokrivajo, hkrati pa redno ažurirajo vsebino v Wikipediji ter o spremembah obveščajo kolege. Če pride do menjave agenta v CPU, novi agent prevzame področja predhodnega agenta. V najkrajšem možnem času se mora seznaniti in izobraziti na področjih, ki mu »pripadajo«.



Tabela 16: »SuperUser« koncept v CPU, kjer so z zeleno barvo označena »SuperUser« področja.

Z uvedbo »SuperUser« koncepta se je doseglo najmanj dve pozitivni spremembi v CPU: čas reševanja naloge se je skrajšal, saj se lahko rešitev najde v Wikipediji ali pa rešitev poda ali izvede »SuperUser«. Hkrati pa se je razbremenilo vse agente, saj ne čutijo več pritiska, da morajo vedeti vse. Najbolj pomembno je, da so uporabniki tudi na boljšem, ker prej pridejo do rešitve, agenti pa imajo več časa, da sprejmejo še kakšen telefonski klic več, ki zato ne gre v statistiko zgrešenega klica.

5.2 SPREMEMBE PROCESA V zaključku prejšnjega podpoglavja smo omenili ključni problem, s katerim se sooča CPU v opazovani organizaciji: vedno večje število zgrešenih klicev. Vloga CPU je predvsem reaktivna: poskuša ujeti čim več klicev uporabnikov in jih poskuša čim prej in čim bolj kvalitetno rešiti. Predhodno smo že omenili, da so deloma razlogi za občutno povečanje števila vstopnih klicev večje spremembe v tehnologiji v opazovani organizaciji, in sicer prehod iz MS Office XP na MS Office 2010, prehod iz MS Windows XP okolja na MS Windows 7 okolje in prehod iz Lotus Notes poštnega sistema na MS Outlook poštni sistem. Kot drugi razlog smo omenili, da so na večje število zgrešenih klicev v letih 2011 in 2012 vplivale menjave agentov na 1. nivoju podpore, saj je v letu 2011 prišlo do ene menjave, v letu 2012 pa so se CPU pridružili trije novi člani. Prav tako se je v drugem četrtletju 2012 spremenila vloga enega od teh novih članov in



koncept podpore v proizvodnji, saj sedaj ta agent prvenstveno skrbi za odpravljanje incidentov in izvedbo zahtev, če mu preostane kaj časa, pa odgovarja na telefonske klice. V tabeli 12 je razvidno, da odgovori na pol manj klicev kot preostali del ekipe, ta številka bi bila še manjša, če ne bi opravljal popoldanskega dežurstva. Iz tega lahko sklepamo, da ima CPU z vpeljavo tega koncepta enega agenta manj, ki lahko odgovarja na klice uporabnikov. Predvsem zaradi tega, ker se je vloga enega od agentov spremenila in ker se je občutno povečalo število vstopnih klicev, smo šli v analizo, ob katerih urah ima CPU največ klicev. Iz tabele 17 je razvidno, da med 6. in 7. uro še ni toliko vstopnih klicev, kljub temu da zaposleni iz proizvodnih enot začenjajo z delom ob 6. uri, ostali pa šele prihajajo na delo. Med 7. in 8. uro se že vidi občutno povečanje števila klicev, saj začnejo v službo prihajati zaposleni iz drugih poslovnih enot. Tabela 17: Primerjava klicev med posameznimi enournimi časovnimi intervali med 2011 in 2012.

Število klicev doseže vrh nekje med 8. in 10. uro, ko so vsi na svojih delovnih mestih. Med 10. in 12. uro začne število klicev padati, ker je takrat čas malice. Med 12. in 14. uro je število klicev dokaj ustaljeno, saj se malica zaključi. Po 14. uri začne število klicev upadati, saj večina zaposlenih iz proizvodnih enot takrat zaključi z delom. V analizo smo vključili tudi število vstopnih klicev med 16. in 17. uro, ki je manjše od tistega med 6. in 7. uro. Iz tega sklepamo, da agent, ki opravlja popoldansko dežurstvo, zmore sam odgovoriti na večino klicev in da delovnega časa celotne ali dela CPU ekipe ni potrebno podaljševati na 17. uro.

Slika 14 prikazuje porazdelitev števila klicev po urah za leti 2011 in 2012. Ker smo za časovni interval izbrali eno uro, nam ne prikaže dovolj natančnega dogajanja, vidimo lahko le, da se nekje okoli 7. ure občutno poveča število vstopnih klicev.



Slika 14: Porazdelitev klicev po enournih časovnih intervalih v letih 2011 in 2012.

Analizo smo zato razširili, in sicer smo si ogledali vstopne klice po 15-minutnih intervalih (tabela 18). Opazili smo, da se začne porast vstopnih klicev okoli 6:45, vrh pa doseže med 8:30 in 8:45. To sovpada z delovnih časom v opazovani organizaciji, saj ta omogoča zaposlenim v poslovnih enotah prihod na delo med 7:00 in 8:30. Število vstopnih klicev se začne zmanjševati okoli 14:45, saj začnejo takrat delo zapuščati tisti iz poslovnih enot, ki so prišli na delo okoli 7. ure, prav tako pa okoli te ure že polno dela 2. izmena zaposlenih v proizvodnih enotah, ki začnejo svoje težave na CPU prijavljati okoli 14. ure, ko se izmena začne. Očitno je, da se začne število neodgovorjenih klicev drastično povečevati že okoli 7. ure. Omenili smo, da ostali agenti pridejo na delo med 7. in 8. uro, ob prihodu na delo pa ne začnejo takoj odgovarjati na klice, ampak nekaj časa namenijo pripravi na nov delovni dan. Pregledajo elektronsko pošto, preverijo trenutno odprte naloge in naredijo načrt za tekoči dan. Tako lahko hitro izgubijo tudi do pol ure za pripravo, v tem času pa na telefone odgovarja le tisti agent, ki opravlja jutranje dežurstvo. Ko pa začnejo z odgovarjanjem na klice, pa se lahko hitro zgodi, da sporočena težava zahteva osebni obisk uporabnika, tako v CPU ostaneta samo dva agenta (glede na že omenjeni dogovor), ki sta na voljo za sprejemanje klicev uporabnikov.



Tabela 18: Primerjava klicev med posameznimi 15-minutnimi časovnimi intervali med 2011 in 2012.

Tabela 19 bolj natančno prikazuje, koliko zgrešenih klicev je imel CPU. To število smo zopet izračunali po sledeči enačbi: zgrešeni klici = vstopni klici – odgovorjeni klici – klici, prekinjeni v 10 sekundah – avtomatski odzivnik



Skupno število in odstotek zgrešenih klicev se zopet pokaže največji kar med 6. in 13. uro, večji je tudi med 15. uro in 16. uro, saj takrat, tako kot med 6. in 7. uro, večinoma dela samo en agent, ki opravlja dežurstvo. Tabela 19: Odstotek zgrešenih klicev po enournih intervalih v letih 2011 in 2012.

Čeprav se je število vstopnih klicev v letu 2012 glede na leto 2011 povečalo, je CPU uspel odgovoriti na več klicev, odstotek zgrešenih klicev je manjši (tabela 20). Tabela 20: Odstotek zgrešenih klicev v letih 2011 in 2012.



Zaradi dejstva, da se največje število klicev izgubi med 7. in 11. uro, smo preverili, kako obremenjen je CPU ne samo v teh urah, ampak skozi celoten dan. Sicer je ta izračun bolj teoretičen, vendar nam vseeno prikaže zanimivo sliko (tabela 21). Tabela 21: Zasedenost agentov po enournih intervalih v letih 2011 in 2012.

Zadevo smo zastavili takole: iz COCOS Call.Center smo dobili informacijo o povprečnem času trajanja pogovora, ki je recimo v letu 2011 trajal 202 sekundi. Vemo, da je bilo v letu 2011 v opazovani organizaciji 247 delovnih dni (zadnji dnevi po 25. 12. so kolektivni dopust, zato je številka malo manjša). Število vstopnih klicev je sicer izračunano za vse dni v letu (365 dni), saj nam aplikacija COCOS Call.Center ne omogoča izločiti dela prostih dni, vendar je to še bolje, ker smo s tem dobili večje povprečno število klicev v eni uri v enem delovnem dnevu. Tako smo recimo med 7. in 8. uro podelili 4.301 vstopnih klicev z 247 delovnimi dnevi in dobili, da se v tem časovnem intervalu zgodi povprečno 17,41 klicev v enem dnevu. Nato smo to število zmnožili z 202 sekundami in dobimo, da bi pogovori za te klice trajali 3.517 sekund. Trajanje pogovorov (3.517 sekund) v tej eni uri smo nato delili s skupnim številom sekund v eni uri (3.600 sekund) in dobili



smo zasedenost enega agenta. V tem primeru se izkaže, da je zasedenost agenta 97,71 %. Če bi med 7. in 8. uro na telefonske klice odgovarjala dva agenta, bi bil vsak zaseden 48,85 %, če bi pa na telefonske klice odgovarjali trije agenti, bi bil vsak zaseden 32,57 %, pri štirih agentih pa bi bil vsak zaseden 24,43 %. V izračun smo postavili pogoj, da posamezen agent ne sme biti zaseden (kritično obremenjen) več kot 60 % časa. Tako se v izračunu pokaže, da bi v primeru, če bi na vse telefonske klice odgovarjal le en agent, ta bil kritično obremenjen med 7. in 15. uro, se pravi cel delovnik (te številke so v tabeli 20 obarvane rdeče). Še huje pa je to, da bi bil med 8. in 15. uro obremenjen več kot 100 %, kar pomeni, da ne bi mogel odgovoriti na vse klice. Če bi na telefonske klice odgovarjala dva agenta, bi bila kritično obremenjena med 8. in 11. uro. V prejšnjih analizah smo prikazali, da se ravno v tem časovnem intervalu zgodi največ klicev, vrh dosežejo nekje med 8:30 in 9:00, posledično je tudi takrat največ klicev neodgovorjenih, kar je tudi prikazala analiza. V primeru, da bi skozi celoten delovni dan na klice odgovarjali trije agenti, ne bi bili nikoli kritično obremenjeni, najbolj obremenjen bi bil posameznik med 8. in 9. uro, in sicer 54 %. V primeru, da bi na klice odgovarjali 4 agenti, bi bil posameznik najbolj obremenjen malo nad 40 %. Ravno zaradi te analize in prejšnjih kazalcev smo se odločili za spremembo zasnove CPU. Kot smo že omenili, so prej vsi odgovarjali na klice in šli vsi reševat težave osebno k uporabnikom, le zaradi internega dogovora sta vedno v CPU ostala najmanj dva agenta. Zgornja analiza je pokazala, da se med 8. in 11. uro zgodi, da sta dva agenta preobremenjena (tudi do 81 %), kar lahko teoretično vodi v neodgovorjene klice. Zato smo postavili sledečo zasnovo CPU: trije agenti so dobili vlogo telefonista, eden pa vlogo »hands & feet« oz. terenskega agenta, ki rešuje težave ali zahteve osebno pri uporabnikih. Ti dve vlogi sta agentom dodeljeni za cel delovni teden, potem pa se rotirajo. Ker se porast vstopnih klicev začne že pred sedmo uro, smo določili prihod na delo za telefoniste ob 7. uri. Vloga telefonista pomeni, da se agent v tem tednu posveti izključno odgovarjanju na telefonske klice, v primeru, da naleti na prijavo, ki zahteva poseg na terenu, jo dodeli terenskemu agentu. V primeru, da naleti na hujši problem, ki zahteva časovno daljše reševanje, kar bi vodilo v njegovo daljšo nedosegljivost za preostale klice, ga sme dodeliti terenskemu agentu ali koordinatorju CPU. Koordinator CPU načeloma ne opravlja teh vlog, prevzame jih le v času dopustov, ko je ekipa številčno oslabljena. Vloga terenskega agenta je prvenstveno reševanje težav in zahtev osebno pri uporabnikih, v času, ko ni na terenu, pa odgovarja na klice ali rešuje bolj zahtevne primere, ki so mu jih dodelili ostali telefonisti. Ker je analiza pokazala, da se začne klice občutno izgubljati že pred 7. uro, je dogovor, da telefonisti začnejo s svojim delom že ob 7. uri. Z vpeljavo vlog telefonist in terenskega agenta ter s tem, da smo za telefoniste postavili tri agente, želimo doseči to, kar je pokazala analiza: pri tem številu naj



nobeden od posameznih agentov ne bi bil preobremenjen, hkrati pa smo po našem mnenju postavili optimalno število agentov, ki bi lahko polovili veliko večino vstopnih klicev. Delovni dan in razporeditev števila agentov in njihovih vlog v posameznih časovnih intervalih prikazuje slika 16:

Slika 15: Primerjava med starim (leva stran) in novim (desna stran) razporedom dežurstev in vlog agentov.

Opomba: ob 7. uri pridejo na delo 2 ali 3 telefonisti, saj ima lahko tisti agent, ki začne opravljati jutranje dežurstvo ob 6. uri, v tekočem tednu dodeljeno vlogo telefonista.

5.3 VPELJAVA NOVIH ORODIJ V letu 2013 so se začeli dogovori s podjetjem CDE nove tehnologije, d. o. o., o vpeljavi nove verzije rešitve COCOS Call.Center, saj je bila trenutna verzija implementirana leta 2004 in je že zastarela, ker je bila zasnovana za okolje Windows XP, tako da v okolju Windows 7 ne deluje popolnoma pravilno. Nova verzija COCOS Call.Center bo vpeljala predvsem dve ključni novosti:

avtomatski odzivnik ob izpadih pomembnih storitev in aplikacij — klici se štejejo kot odgovorjeni,

vmesnik med aplikacijo COCOS klient klicnega centra in aplikacijo BMC Remedy — hiter vpogled v zgodovino prejšnjih klicev določenega uporabnika in kdo je govoril z uporabnikom.

CPU bo z novo verzijo COCOS Call.Center veliko pridobil, prva ključna novost je avtomatski odzivnik. Avtomatski odzivnik predstavljajo vnaprej posneta sporočila,



ki se vklopijo ob izpadih pomembnih storitev in aplikacij. Ko pride do izpada pomembne storitve ali aplikacije, lahko vodja CPU ali koordinator CPU ali CPU agent v aplikaciji COCOS administrator klicnega centra vklopi predvajanje sporočila o izpadu. Če ustreznega sporočila ni na voljo, se to lahko na hitro posname in aktivira. Ko uporabnik pokliče CPU, mu COCOS Call.Center najprej predvaja sporočilo o izpadu, nato mu da možnost, da vseeno zahteva pogovor z agentom. Če uporabnik prekine klic ob poslušanju sporočila o izpadu, se ta klic šteje kot odgovorjen. V sedanji situaciji se je ob izpadu pomembne storitve ali aplikacije vsulo klicev, agenti jih niso uspeli obdelati vseh, zato veliko uporabnikov ni dobilo odgovora na klic, posledično je bilo veliko neodgovorjenih klicev. Druga novost, ki se pripravlja, je vmesnik med aplikacijo COCOS klient klicnega centra in BMC Remedy. Vmesnik bo agentu ob sprejemu na podlagi klicne številke odprl masko, kjer bodo podatki o uporabniku in hiter vpogled v zgodovino prejšnjih klicev tega uporabnika. Iz zgodovine se bo dalo razbrati: kdaj je uporabnik klical, kaj je bil razlog klica in kateri agent je z njim takrat govoril. Agent bo v masko vpisal opis težave in ostale ključne informacije ter s klikom na gumb odprl novo nalogo v BMC Remedy. Vmesnik bo tako omogočil, da se naloga v BMC Remedy odpre hitreje in enostavneje. Izgled maske (slika 16) novega COCOS klienta klicnega centra se je z leti posodobil, še vedno vsebuje ključne funkcije, na katere so agenti že navajeni, in nekaj novih funkcionalnosti.

Slika 16: Maska COCOS klienta klicnega centra.

CPU agenti pri svojem delu veliko uporabljajo info okno (slika 17), kjer se vidi zgodovina vstopnih in izhodnih klicev.

Slika 17: COCOS klient klicnega centra - Informativno okno.

Novost pri COCOS klientu klicnega centra je tudi stanje operaterjev (slika 18), kjer lahko vsak agent v vsakem trenutku vidi status svojih sodelavcev. V primeru, da



noben od agentov ni v statusu »sprejem«, se lahko hitro reagira in ponovno omogoči dosegljivost CPU.

Slika 18: COCOS klient klicnega centra - Stanje operaterjev.

Posodobljen je tudi COCOS administrator klicnega centra (slika 19), ki je pridobil nekaj novih funkcionalnosti, ki bodo prišle prav.

Slika 19: Osnovni izgled grafičnega vmesnika COCOS administratorja kontaktnega centra.



V sekciji statistika, poročila je kot novost diagram zasedenosti operaterjev (slika 20).

Slika 20: COCOS administrator kontaktnega centra — statistika in poročila.

V pregledu dnevne statistike (slika 21) se da za vsakega posameznega operaterja razbrati število klicev, na katere je agent odgovoril, število izhodnih klicev, število zavrnjenih klicev (klicev, ki jih agent namerno ni želel sprejeti), število ignoriranih klicev (klicev, ki jih agent ni pravočasno sprejel in so bili zaradi tega ponujeni drugemu agentu), skupni in povprečni čas pogovora med agentom in stranko, skupni in povprečni čas, ki ga je agent porabil za administrativna dela, skupni čas prijave v sistem itn.

Slika 21: COCOS administrator kontaktnega centra — dnevna statistika.

Čarovnik histogramov (slika 22) omogoča podrobnejše statistične podatke, in sicer omogoča avtomatizirano izdelavo poročil v obliki grafičnih poročil. Čarovnik ponuja nadzorniku možnost izdelave poročil glede na množico ponujenih parametrov (CDE, 2009).

Slika 22: COCOS administrator kontaktnega centra — čarovnik histogramov.



Čarovnik histogramov (slika 23) nam omogoča podatke, kot so: skupno število klicev, skupno število vstopnih in izhodnih klicev, skupno število uspešnih vstopnih in izhodnih klicev, skupno število neuspešnih vstopnih in izhodnih klicev, koliko klicev je bilo odgovorjenih ali neodgovorjenih v 5, 10, 30 ali 60 sekundah, povprečni čas čakanja uporabnika v čakalni vrsti, povprečni čas pogovora z uporabnikom itn.

Slika 23: COCOS administrator kontaktnega centra — poročilo čarovnika histogramov

Novost, ki jo prinaša nova verzija COCOS administrator kontaktnega centra, je analiza zasedenosti CPU (slika 24), iz katere lahko razberemo zasedenost posameznega agenta ali celotnega CPU, hkrati pa lahko razberemo, če je bil v določenem dnevu kakšen trenutek, ko je bil celoten CPU nedosegljiv.



Slika 24: COCOS administrator kontaktnega centra — diagram zasedenosti agentov

Posamezne barve v grafikonu pomenijo sledeči status:

roza: odmor

modra: čakanje na klic

temno modra: zvonjenje pri stranki, prevezava klica

zelena: pogovor

rumena: vnos podatkov

oranžna: administrativna dela V aplikaciji je na voljo že množica vnaprej pripravljenih poročil (slika 25), omogočeno je, da si prilagodiš svoja specifična poročila, ki temeljijo na analizi poljubnih podatkov iz tabele »opravljeni klici«, ki se jih lahko izvede s pomočjo SQL poizvedb v omenjeni tabeli (CDE, 2009).

Slika 25: COCOS administrator kontaktnega centra — splošno poročilo po akcijah.



5.4 MERITVE KLJUČNIH KAZALCEV SPREMENJENEGA PROCESA Iz slike 26 je razvidno, da je CPU v letu 2013 uspel odgovoriti na več klicev kot predhodno leto. Manj je bilo vstopnih klicev, saj so agenti »polovili« več klicev in uporabnikom ni bilo potrebno večkrat klicati, da bi dobili prostega agenta na telefon.

Slika 26: Primerjava med vstopnimi in odgovorjenimi klici med leti 2007 in 2013.

V tabeli 22 si lahko ogledamo število vstopnih, odgovorjenih in zgrešenih klicev po mesecih, pozitivna informacija je ta, da agentom uspeva iz leta v leto dvigniti število odgovorjenih klicev, hkrati pa so v letu 2013 zmanjšali število neodgovorjenih klicev za 3.500.



Tabela 22: Primerjava števila vstopnih klicev in odgovorjenih klicev med letoma 2012 in 2013.

V tabeli 23 je razvidno število klicev, kjer so uporabniki pustili sporočilo na avtomatskem odzivniku (stolpec avtomatski odzivnik), in koliko klicev so uporabniki prekinili že po 5 ali 10 sekundah, preden se jim je na telefon oglasil agent. Tabela 23: Primerjava števila sporočil, puščenih na avtomatskem odzivniku, in prekinjenih klicev v 5 in 10 sekundah med letoma 2012 in 2013.

Iz zgornje tabele je razvidno, da se je v letu 2013 število sporočil, puščenih na avtomatskem odzivniku, zmanjšalo skoraj za tretjino, kar je zelo dober kazalec. Ostale številke, ki prikazujejo, koliko uporabnikov je prekinilo klic po prvih petih ali desetih sekundah (v tem času slišijo pozdravno sporočilo in v primeru, da so vsi agenti zasedeni, slišijo sporočilo, da trenutno ni na voljo nobenega operaterja), so te številke skoraj enake kot predhodno leto.



V tabeli 24 je razvidno število klicev, kjer so uporabniki klice prekinili po 30 ali 60 sekundah, preden se jim je na telefon oglasil agent. Te številke so se v letu 2013 zmanjšale, tako da bi lahko sklepali, da agenti uspejo hitreje odgovoriti na klice uporabnikov in uporabnikom ni treba več tako dolgo čakati na prostega agenta in redkeje prekinejo klic v omenjenem časovnem intervalu. Tabela 24: Primerjava števila prekinjenih klicev v 30 in 60 sekundah med letoma 2012 in 2013.

Tabela 25 predstavlja dejansko število zgrešenih klicev in kolikšen je ta odstotek glede na vse vstopne klice. To število se izračuna po enačbi: zgrešeni klici = vstopni klici – odgovorjeni klici – klici, prekinjeni v 10 sekundah – avtomatski odzivnik Tabela 25: Primerjava števila zgrešenih klicev med letoma 2012 in 2013.



V spodnji tabeli (tabela 26) je razvidno, da se je v letu 2013 povprečni čas pogovora povečal za dobre tri sekunde, kar bi lahko pripisali dejstvu, da so se v letu 2012 CPU pridružili trije novi agenti. Novi agenti potrebujejo določen čas, da začnejo dosegati podobne rezultate kot »stari mački«, zato pogovori vsaj v uvajalnem obdobju trajajo dlje. Tabela 26: Primerjava povprečnega časa pogovora med leti 2012 in 2013.

V tabeli 27 lahko razberemo, da se je povprečni čas čakanja na pogovor zmanjšal za več kot 1,5 sekundo. Podoben rezultat smo lahko prebrali v sliki 27, kjer je razvidno, da je CPU uspel odgovoriti na večje število klicev, posledično so uporabniki čakali manj časa na prostega agenta. Tabela 27: Primerjava povprečnega časa čakanja na pogovor v letih 2012 in 2013.



Tabela 28 prikazuje, da se je povprečni čas čakanja zmanjšal skoraj za sekundo. CPU je uspel odgovoriti na večje število klicev, posledično so uporabniki manj časa čakali na prostega agenta. Tabela 28: Povprečni čas čakanja v vrsti med leti 2012 in 2013.

V letu 2013 se je stopnja uspešnosti CPU zelo popravila (tabela 29), saj se je v povprečju dvignila skoraj za 5 %. Odstotek bi bil še večji, če oktobra 2013 eden najuspešnejših agentov ne bi prešel na novo vlogo na 2. nivoju podpore. Tabela 29: Stopnja uspešnosti kontaktnega centra med leti 2012 in 2013.



Iz slike 27 je razvidno, da je bila tudi v letu 2013 razporeditev klicev po enournem časovnem intervalu skoraj enaka predhodnima letoma. Spodbuden pokazatelj je, da je zelena linija v času, ki predstavlja leto 2013, ko se zgodi največ vstopnih klicev (med 8. in 12. uro), pod obema linijama za leti 2011 in 2012, tako da bi zopet lahko sklepali, da agenti hitreje odgovorijo na več klicev in uporabnikom ni bilo potrebno večkrat klicati, da bi dobili prostega agenta na telefon.

Slika 27: Primerjava vstopnih klicev med leti 2011 in 2013.

Tabela 30 nam prikaže podobne rezultate kot predhodne analize in prejšnji kazalci, zaradi katerih smo se odločili za spremembo zasnove CPU: trije agenti so dobili vlogo telefonista, eden pa vlogo »hands & feet« oz. terenskega agenta, ki rešuje težave ali zahteve osebno pri uporabnikih. Tabela 30: Odstotek zgrešenih klicev po enournih intervalih v letu 2013.



Podobno kot v točki 5.2 smo izračunali zasedenost agentov po enournih intervalih v letu 2013 (tabela 31). Iz COCOS Call.Center smo dobili informacijo o povprečnem času trajanja pogovora, ki je 2013 trajal 201,7 sekunde. V letu 2013 je bilo v opazovani organizaciji 246 delovnih dni. Nato smo med 7. in 8. uro podelili 4.736 vstopnih klicev z 246 delovnimi dnevi in dobili, da se v tem časovnem intervalu zgodi povprečno 19,25 klicev v enem dnevu. Nato smo to število zmnožili z 201,7 sekundami in dobili, da bi pogovori za te klice trajali 3.883 sekund. Trajanje pogovorov (3.887 sekund) v tej eni uri smo nato delili s skupnim številom sekund v eni uri (3.600 sekund) in dobili smo zasedenost enega agenta. V tem primeru se izkaže, da je zasedenost agenta 107,86 %. Če bi med 7. in 8. uro na telefonske klice odgovarjala dva agenta, bi bil vsak zaseden 53,93 %, če bi na telefonske klice odgovarjali trije agenti, bi bil vsak zaseden 35,95 %, pri štirih agentih pa bi bil vsak zaseden 26,97 %.

Tabela 31: Zasedenost agentov po enournih intervalih v letu 2013.

V izračun smo postavili pogoj, da posamezen agent ne sme biti zaseden (kritično obremenjen) več kot 60 % časa. Tako se v izračunu pokaže, da bi v primeru, če bi na vse telefonske klice odgovarjal le en agent, ta bil kritično obremenjen med 7. in 15. uro, se pravi cel delovnik (te številke so v tabeli 20 obarvane rdeče). Še huje pa je to, da bi bil med 8. in 15. uro obremenjen več kot 100 %, kar pomeni, da ne bi mogel odgovoriti na vse klice. Če bi na telefonske klice odgovarjala dva agenta, bi bila kritično obremenjena med 8. in 10. uro. V prejšnjih analizah smo prikazali, da se ravno v tem časovnem intervalu zgodi največ klicev, vrh dosežejo nekje med 8:30 in 9:00, posledično je tudi takrat največ klicev neodgovorjenih. Ponovno se je izkazalo, da ker smo nastavili tri telefoniste skozi celoten delovni dan, ni bil nobeden kritično obremenjen, najbolj obremenjen je bil posameznik med 8. in 9. uro, in sicer 50,5 %. V primeru, da bi na klice stalno odgovarjali 4 agenti, bi bil posameznik najbolj obremenjen okoli 39 %.

Iz tabele 32 zopet lepo vidimo, kako je odločitev o vpeljavi treh telefonistov pozitivno vplivala na odstotek zgrešenih klicev, saj so se rezultati v vseh ključnih časovnih intervalih občutno popravili.



Tabela 32: Primerjava odstotka zgrešenih klicev po enournih intervalih med leti 2012 in 2013.

Tabela 33 prikazuje primerjavo rešenih nalog med posameznimi agenti. Iz tabele je razvidno, da imajo trije pri vrhu podobne absolutne številke. Agent 8 je prešel v januarju 2013 na 2. nivo podpore, agent 12 pa se je ekipi priključil v novembru 2013, zato se z njima ne bomo ukvarjali. Agent 10 prvenstveno skrbi za podporo v proizvodnji, zato ima občutno nižje številke, medtem ko agenta 9 in 11 dosegata občutno nižje rezultate. Kot smo že predhodno zapisali, bi bilo zanju treba opraviti podrobnejšo analizo glede njihove usposobljenosti in koliko časa jima vzamejo posebej dodeljene naloge. Tabela 33: Primerjava opravljenih delovnih dni in rešenih nalog po agentih v letu 2013.

Tabela 34 prikazuje število nalog, ki jih je odprl oz. zabeležil posamezen agent v orodju za upravljanje z incidenti BMC Remedy. V to so vštete naloge, ki jih je sam rešil ali naslovil v reševanje na druge agente na katerem koli nivoju podpore. Zopet občutno izstopajo trije agenti po absolutnih številkah, ostali agenti jim sledijo s kar veliko razliko.



Tabela 34: Primerjava odprtih nalog po agentih med letoma 2011 in 2012.

Tabela 35 prikazuje število odgovorjenih klicev po posameznih agentih. Vidno je, da izstopa agent 1, ki je stalno opravljal dežurstvo ob 6. uri zjutraj. Agenti 2, 3 in 5 imajo podobne povprečne rezultate, medtem ko agenta 9 in 11 kar precej zaostajata. Agent 12 je začel z delom in usposabljanjem v letu 2013, zato je normalno, da ima nižji rezultat. Agent 10 ima slabše rezultate zato, ker je njegova prvenstvena naloga podpora proizvodnji, šele na drugem mestu je odgovarjanje klicev.

Tabela 35: Primerjava odgovorjenih telefonov po agentih med letoma 2011 in 2012.

Tabela 36 prikazuje enega od kriterijev, po katerih se ocenjuje agente, in sicer razmerje med odprtimi oz. zabeleženimi nalogami v orodju za upravljanje z incidenti BMC Remedy in odgovorjenimi klici. Dogovor je, da mora biti ta odstotek nad 75 %. Iz tabele je razvidno, da kar nekaj agentov na letnem nivoju te številke ne dosega. Iz tega lahko zopet sklepamo, da se veliko število klicev še vedno ne



zabeleži v orodje. Zaradi tega celoten CPU in ostale podporne skupine ter oddelek informacijske varnosti ne morejo dobiti prave slike ob periodičnih pregledih, kaj se dogaja oz. s kakšnimi težavami ali zahtevami se srečujejo uporabniki. Dober rezultat je, da celoten CPU izpolnjuje kriterij, in sicer je razmerje 76,77 %, medtem ko je v letu 2012 ta odstotek znašal le 70,86 % Tabela 36: Primerjava razmerja med odprtimi nalogami in odgovorjenimi klici po agentih v letu 2013.

Tabela 37 prikazuje drugega od kriterijev, po katerih se ocenjuje agente, in sicer odstotek rešenih incidentov v istem dnevu, ki mora biti nad 85 %. Iz tabele je razvidno, da ga le agent 9 ne dosega na letnem nivoju. Iz analize smo izpustili agenta 8, ki je v januarju 2013 prešel na 2. nivo podpore, za agenta 10 pa smo že večkrat omenili, da prvenstveno rešuje naloge, vezane na proizvodnjo, ki lahko praviloma trajajo dlje časa. V navezavi s prejšnjo tabelo bi lahko ponovno rekli, da če bi se agenti potrudili pri vpisu vseh nalog, bi zlahka dosegali ta kriterij.



Tabela 37: Primerjava odstotka rešenih nalog v istem dnevu po agentih v letu 2013.

Tabela 38 kaže povprečni čas reševanja incidentov po agentih, ki se računa kot razlika med datumom in uro zaprtja incidenta in datumom in uro odprtja incidenta. V letu 2011 je bilo skupno povprečje CPU večje od enega dneva, v letu 2012 pa je znašalo nekaj več kot 1,5 delovnega dneva. V letu 2013 rezultati kažejo, da se incidenti večinoma zaključujejo v istem dnevu, kar je pokazala tudi tabela 36, in sicer da se okoli 91 % incidentov zaključi isti dan, ko so sporočeni s strani uporabnikov. Tabela 38: Povprečni čas reševanja incidentov po agentih v letu 2013.



6 DISKUSIJA 6.1 REZULTATI Glavni cilj diplomske naloge je bil zmanjšanje odstotka neodgovorjenih klicev, ki so v letu 2011 dosegali skoraj 25 %, na vsaj 15 %. Na podlagi spodnje primerjalne tabele (tabela 39) ugotavljamo, da smo skoraj dosegli ta cilj. Število vstopnih klicev je med leti 2011 in 2013 v povprečju ostalo enako, nekje okoli 53.000, medtem ko se je število odgovorjenih klicev dvignilo za več kot 7.000. Posledično je bilo zgrešenih klicev za dobrih 3.500 manj oz. smo odstotek zgrešenih klicev izboljšali iz 23,63 % na malo več kot 15 %. Tabela 39: Odstotek zgrešenih klicev med leti 2011 in 2013.

Iz kazalcev v zgornji tabeli lahko sklepamo, da je bila odločitev, da se za stalne telefoniste (vloga telefonista pomeni, da se agent v določenem tednu, ko mu je dodeljena ta vloga, posveti izključno odgovarjanju telefonskim klicem), izkazala za uspešno. Odstotek zgrešenih klicev se je zmanjšal za več kot 8 %, kar je dobra osnova za delo naprej. Podobno kot predhodna tabela nam prikaže tudi tabela 40, in sicer da se je s postavitvijo treh telefonistov povprečno število v primerjavi z letom 2011 dvignilo za 30 klicev na dan oz. 8 klicev v primerjavi z letom 2012. Tabela 40: Povprečje odgovorjenih klicev na dan med leti 2011 in 2013.

Odstotek rešenih incidentov v istem dnevu (tabela 41) se je dvignil v povprečju za 3 %, skupno pa jih je bilo v letu 2013 rešenih 91,09 %, kar je občutno več od dogovorjenih 85 %. Tabela 41: Odstotek rešenih incidentov v istem dnevu med leti 2011 in 2013.



Naslednji cilj diplomske naloge je bil skrajšanje časa reševanja zahtev uporabnikov v povprečju za vsaj 25 % (tabela 42). Na podlagi rezultatov v letu 2013 ugotavljamo, da imamo dokaj realne rezultate, saj se je v letu 2011 dogajalo, da agenti niso dosledno skrbeli za zaključevanje incidentov, tako da so jih veliko zaključevali naslednje delovne dni. V letih 2012 in 2013 je ta številka veliko bolj realna, in sicer so agenti čas reševanja v letu 2013 v primerjavi z letom 2012 razpolovili. Tabela 42: Povprečni čas reševanja incidenta med leti 2011 in 2013.

Naslednji cilj diplomske naloge je bil povečanje razmerja med zabeleženimi zahtevami uporabnikov in odgovorjenimi klici za vsaj 10 % (tabela 43). Žal moramo ugotoviti, da tega cilja nismo dosegli, saj se je razmerje med odprtimi nalogami in odgovorjenimi klici povečalo le za slabih 4,5 %. Tabela 43: Razmerje med odprtimi nalogami in odgovorjenih klici med leti 2011 in 2013.

Iz tabele 44 je razvidno, da se je število vpisanih nalog povečalo podobno kot razmerje med odprtimi nalogami in odgovorjenimi klici, in sicer le za slabih 4 %. Tabela 44: Primerjava skupnega števila rešenih nalog med leti 2011 in 2013.



6.2 PRIDOBLJENE IZKUŠNJE Večino zastavljenih ciljev smo dosegli z obstoječo ekipo, le vloge smo prerazporedili med agenti v CPU, in sicer da smo jih razdelili na vlogi telefonista in terenskega agenta, hkrati pa smo vpeljali koncept SuperUser. Z vlogama telefonist in terenski agent smo preprečili, da bi šla večina agentov opravljat terenska dela, v CPU pa bi ostala dva ali celo samo en agent, ki bi odgovarjal na telefonske klice. S to prerazporeditvijo vlog smo zagotovili, da so bili skoraj v vsakem trenutku na voljo vsaj trije agentje, ki so odgovarjali na telefonske klice. Zaradi enakomerne obremenjenosti smo ustrezno tedensko rotirali ti dve vlogi, in sicer tako, da je bil posamezen agent največ dva tedna zaporedoma telefonist in terenski agent na približno šest tednov. Kot smo že omenili, je na pozitivne rezultate vplivala tudi vpeljava koncepta SuperUser. Agenti so se izobrazili na ključnih področjih, za katera so bili zadolženi. S tem so prešli iz t.i. »generalistov« na strokovnjake določenega področja in pri specifičnih težavah uporabnikov pomagali sodelavcem ali celo prevzeli reševanje. V prerazporeditev vlog je bilo vloženega veliko časa in napora, da so agenti prevzeli odgovornost, razumeli koncept in ga prevzeli kot izboljšavo delovnega procesa in celotne storitve za uporabnike.

6.3 MOŽNOSTI NADALJNJEGA RAZVOJA

V prihodnosti bi se lahko v opazovani organizaciji posvetili okrepitvi ekipe CPU, in sicer bi lahko ekipo povečali še za enega člana, tako bi lahko število telefonistov povečali na štiri. S tem bi bili vsi telefonisti v tekočem tednu bolj enakomerno obremenjeni in bi lahko »polovili« še več vstopnih klicev. Dodatno je potrebno delati še na izobraževanju agentov, in sicer stalno izboljševati njihove komunikacijske veščine, saj bodo s tem pogovori krajši, vprašanja bolj natančna in rešitve podane hitreje. Prav tako je treba agente stalno izobraževati na področju tehnologije, poslovnih rešitev in procesov v opazovani organizaciji, ki jih podpirajo. Glede na to, da je CPU zastavljen predvsem reaktivno, se pravi, da poskuša poloviti čim več vstopnih klicev, bi bilo treba tudi kaj storiti za zmanjšanje vstopnih klicev. Zadnje čase se v strokovni literaturi in člankih veliko govori o t.i. »samopomoči« za uporabnike. CPU sicer že nekaj naredi v tej smeri, saj periodično objavlja članke in navodila za reševanje najbolj pogostih vprašanj, vendar jih te pozna in uporablja le majhno število uporabnikov. Zato bi bilo potrebno narediti več in bolj konkretne korake v tej smeri, da bi si uporabniki ob preprostih in najbolj pogostih napakah poskušali pomagati sami ali med seboj, šele nato bi klicali CPU. Mogoče bi bilo dobro organizirati predstavitve dela in vloge CPU predvsem v tistih enotah, ki najbolj pogosto kličejo za pomoč. Prav tako bi bilo potrebno pripraviti nekakšen »Self-help« portal, ki bi ponujal navodila in rešitve za lokalne probleme in usmerjal na globalne »Self-help« portale, ki nudijo navodila in pomoč za delo s standardnimi orodji.



Največje število klicev se izgubi v času izpadov ali nedelovanja pomembnih sistemov in poslovnih aplikacij, saj takrat tudi CPU z 20 telefonisti ne bi uspel odgovoriti na poplavo klicev. V tovrstnih primerih bi bilo potrebno razmišljati o nekakšnem obveščevalnem sistemu (lahko je avtomatski odzivnik), ki bi uporabnikom dal informacijo, da je prišlo do izpada ali omejenega delovanja pomembnejšega sistema ali poslovne aplikacije ter okvirni čas, potreben za odpravo težav. S tem bi se CPU posvetil samo reševanju ostalih težav uporabnikov, klici zaradi izpada pa sploh ne bi prišli do njih in bi se vodili kot odgovorjenih klici. V dosedanjem času se ni delalo dovolj na promociji CPU, temu bi lahko rekli, da je potreben prehod iz reaktivnega v proaktiven CPU. Določene aktivnosti so se sicer izvajale, lahko pa bi več energije in časa posvetili sledečemu: Predstavitve dela CPU v enotah, od koder prihaja največ prijav incidentov in zahtev — z detajlnejšo analizo incidentov in zahtev bi se lahko vodjem oddelkov v teh enotah pokazalo, za kakšne zadeve najpogosteje kličejo njihovi sodelavci, kje so potrebna dodatna izobraževanja, hkrati pa bi enote same pokazale ključne operacije, ki potrebujejo bolj aktivno vlogo s strani CPU. Predstavnik CPU bi se lahko periodično udeleževal kolegija teh enot, lahko pa bi se pripravila predstavitev za vse sodelavce teh enot, kjer bi uporabniki imeli možnost tudi konkretneje spoznati delo CPU in zastaviti vprašanja. Predstavitev dela CPU tajnicam enot in oddelkov — tajnice oz. poslovne sekretarke v veliki meri predstavljajo stično točko za uporabnike določene enote in oddelkov, od njih uporabniki pričakujejo odgovore na vprašanja z IT področja. V preteklosti se je že izvedla delavnica za tajnice, kjer se jim je predstavili proces zagotavljanja avtorizacij in strojne opreme in aplikacija Remedy, preko katere lahko odpirajo IT zahtevke. Dobro bi bilo tovrstno delavnico ponoviti in nadgraditi, in sicer tako, da od njih pridobimo informacije, s kakšnimi vprašanji k njim najpogosteje prihajajo uporabniki. Odprti dnevi CPU — občasno bi se lahko organiziralo t.i. »odprte dneve CPU«, uporabniki bi lahko prišli v CPU in dobili odgovore na IT vprašanja ne glede na to, če izvirajo iz poslovne ali domače rabe računalniške opreme in programov. Hkrati bi lahko videli CPU agente pri delu in dobili občutek, kaj se dejansko dogaja v CPU in kako teče delo. Posodobitev predstavitve IT okolja v opazovani organizaciji, ki se bo po novem namestila na namizje računalnika vsakega novo zaposlenega in na intranet strani CPU — ta predstavitev je sicer že izdelana v PowerPoint obliki in se uporablja samo za predstavitev IT okolja na uvajanju novo zaposlenih sodelavcev. Predstavitev bi se lahko dopolnila z rešitvami in navodili za najbolj pogosta vprašanja, ki jih uporabniki zastavijo CPU vsakodnevno, samo predstavitev bi se dalo na namizje vsakega računalnika, ki se pripravi na novo (ali v okviru dobave računalnika za novo zaposlenega ali v okviru periodične menjave strojne opreme), lahko bi se jo dalo tudi na spletne strani CPU.



7 ZAKLJUČEK Center za podporo uporabnikom je največkrat edini stik uporabnika z oddelkom informacijska tehnologija v neki organizaciji. Uporabniku mora CPU predstavljati centralizirano točko za rešitev njegovih težav, vprašanj in zahtev, zato mora biti njegovo delo zastavljeno tako, da je čim bolj uspešen in učinkovit. Uspešen in učinkovit CPU je skupek različnih sestavin, ki nudijo njegovim uporabnikom storitve na najvišji kvalitetni ravni. Začne se z orodji, ki jih ima CPU na voljo, kot so računalniška oprema, sistem za avtomatsko distribucijo klicev in aplikacija za vodenje incidentov in zahtev. Nadalje mora biti osebje CPU zelo fokusirano, zavedati se mora, komu služi in katere storitve nudi. Hkrati se morajo tudi uporabniki zavedati, kaj lahko pričakujejo od CPU in v kakšnih časovnih okvirih. Osebje CPU mora tudi razumeti prioritete in kritičnost posameznih storitev in poslovnih aplikacij. Skratka, dobro mora poznati posel in dobro mora poznati svoje uporabnike in njihove potrebe in probleme (Czegel, 1998). Vodstvo, ki bdi nad delovanjem CPU, mora stalno spremljati rezultate in osebje ter poskrbeti za čim bolj učinkovito sodelovanje z ostalimi oddelki znotraj IT in na splošno z vsemi področji znotraj celotne organizacije. Posel je bil vedno kot živ organizem, ki se stalno spreminja, razvija, prilagaja, takšna mora biti tudi celotna organizacija in vsi njeni deli do najmanjšega sestavnega člena. Takšen mora biti tudi CPU in njeni člani: pripravljen, da sprejme spremembe ali pa jih zavrača, dokler ga situacija sama ne prisili, da jih sprejme in obstane. CPU mora postati še bolj proaktiven, in sicer mora biti v koraku s spremembami, tako da ima pod kontrolo svoja operativna sredstva, zmožnosti ekipe in poslovne potrebe in zahteve. To pomeni razumevanje pomembnosti stalnih izboljšav znotraj posameznikove sfere vpliva in izvajanje konkretnih korakov v luči tega samozavedanja (Covey, 2005). S svojo še bolj proaktivno vlogo bo z vpeljavo promocije svojih storitev in portala za samopomoč dobil preventivno dimenzijo, saj v sedanji situaciji, kot kakšen gasilec požarov, v glavnem izvaja kurativo. Izboljšave procesa se bile v konkretnem primeru CPU dosežene z majhnimi odmiki od kvantitativno definiranih ciljev. Zmanjšanje števila neodgovorjenih klicev smo želeli popraviti s 25 % na vsaj 15 %, na koncu smo skoraj dosegli želeni rezultat s 15,42 % na letni ravni. Skrajšanje časa reševanja zahtev uporabnikov smo želeli zmanjšati v povprečju za vsaj 25 %, ob koncu leta 2013 smo ga zmanjšali za več kot 80 %. Povečanje razmerja med zabeleženimi zahtevami uporabnikov in odgovorjenimi klici smo želeli dvigniti za vsaj 10 %, vendar smo tukaj dosegli le izboljšavo za dobre 4 %. Kljub temu da nismo dosegli zadanih izboljšav na vseh področjih, se je motiviranost agentov povečala, saj so dobili nova orodja za delo in razbremenitev z vpeljavo novih vlog.



LITERATURA IN VIRI Knjige:

Czegel, B. (1998). Running an Effective Help Desk (2nd ed.). New York: John Wiley & Sons, Inc.

Čepin, T. (2009). Organiziranje oddelka IT po smernicah ogrodja ITIL. Diplomsko delo univerzitetnega študija, Fakulteta za organizacijo, Kranj, Slovenija.

Gorenc, M. (2008). Uporaba ITIL in IDEAL pri vzpostavitvi storitvenega centra. Diplomska naloga, Fakulteta za elektrotehniko, računalništvo in informatiko, Maribor, Slovenija.

Login, I. (2003). Upravljanje s storitvami IT: Obvladovanje problemov v storitvenem centru. Magistrska naloga, Fakulteta za računalništvo in informatiko, Ljubljana, Slovenija.

Wooten, B. (2001). Building & Managing a World Class IT Help Desk. Berkeley, California: Osborne/McGraw-Hill.

The Stationery Office. (2007). The Official Introduction to the ITIL Service Lifecycle. Norwich: The Stationery Office.

The Stationery Office. (2007). Service Operation. Norwich: The Stationery Office.

The Stationery Office. (2003). ITIL - The Key to Managing IT Services: Service Delivery. Norwich: The Stationery Office.

The Stationery Office. (2003). ITIL - The Key to Managing IT Services: Service Support. Norwich: The Stationery Office.

Spletne strani: BMC Software Inc. (2011). BMC Remedy Service Desk: Incident Management User

Guide. Dosegljivo na:

http://klslconsulting.com/blog/wp-content/uploads/2011/09/174271-IM-User-Guide.pdf (24.05.2014).

CDE nove tehnologije d.o.o. Produkti in rešitve: Blagovna znamka COCOS. Dosegljivo na:

http://www.cde.si/CDE_SI,,produkti_in_resitve,blagovna_znamka_cocos.htm (23.05.2014).

CDE nove tehnologije d.o.o. COCOS CC rešitve. Dosegljivo na: https://www.klic.si/left-menus/products-solutions-left-menu/call-

center (23.05.2014). Covey, S.R. (2005). Best practices - 7 Habits of Highly Effective Contact Centers

and Help Desks. Dosegljivo na: http://franklincoveyresearch.org/catalog/egain_whitepaper_7habits

_effective_contact_centers.pdf (24.05.2014). Gliedman, C. (2005). Best Practices, Thirty-One Best Practices For The Service

Desk. Dosegljivo na: http://www.noesisinc.com/links/Forrester_White_Paper.pdf

(24.05.2014) Vsebina spletne strani: http://www.securityprocedure.com/comparison-between-

cobit-itil-and-iso-27001 (05.10.2013)

http://www.securityprocedure.com/comparison-between-cobit-itil-and-iso-27001

http://www.securityprocedure.com/comparison-between-cobit-itil-and-iso-27001



KAZALO SLIK Slika 1: ITIL storitveni življenjski cikel (ITIL, 2007). .................................... 5 Slika 2: Vpetost izvajanja storitve v ostale procese (ITIL, 2007). ..................... 7 Slika 3: Organizacijska shema enote informacijska tehnologija. ..................... 21 Slika 4: Nivoji podpore v CPU. ............................................................. 22 Slika 5: Organiziranost CPU. ............................................................... 23 Slika 6: Razpored dežurstev in vlog agentov. ............................................ 25 Slika 7: Izgled začetne strani in modulov v BMC Remedy

(www.zdnet.com, 2014). ....................................................... 26 Slika 8: Izgled in ostale funkcije incidenta v BMC Remedy (www.grafixoft.com,

2014). ............................................................................. 26 Slika 9: Pogled na masko COCOS klienta kontaktnega centra (Opazovana

organizacija, 2014). ............................................................. 27 Slika 10: Pogled na masko in funkcionalnosti COCOS administratorja

klicnega centra (CDE, 2014). .................................................. 28 Slika 11: Povezava med upravljanjem z incidenti, upravljanjem s problemi

in upravljanjem s spremembami. ............................................. 29 Slika 12: Postopek reševanja incidentov (opazovana organizacija, 2014). .......... 30 Slika 13: Število vstopnih klicev in odgovorjenih klicev med leti 2007

in 2012. ........................................................................... 33 Slika 14: Porazdelitev klicev po enournih časovnih intervalih v letih 2011

in 2012. ........................................................................... 47 Slika 15: Primerjava med starim (leva stran) in novim (desna stran)

razporedom dežurstev in vlog agentov. ...................................... 52 Slika 16: Maska COCOS klienta klicnega centra. ........................................ 53 Slika 17: COCOS klient klicnega centra - Informativno okno. ......................... 53 Slika 18: COCOS klient klicnega centra - Stanje operaterjev. ........................ 54 Slika 19: Osnovni izgled grafičnega vmesnika COCOS administratorja

kontaktnega centra. ............................................................ 54 Slika 20: COCOS administrator kontaktnega centra — statistika in poročila. ....... 55 Slika 21: COCOS administrator kontaktnega centra — dnevna statistika. ........... 55 Slika 22: COCOS administrator kontaktnega centra — čarovnik histogramov. ...... 55 Slika 23: COCOS administrator kontaktnega centra — poročilo čarovnika

histogramov ...................................................................... 56 Slika 24: COCOS administrator kontaktnega centra — diagram zasedenosti

agentov ........................................................................... 57 Slika 25: COCOS administrator kontaktnega centra — splošno poročilo

po akcijah......................................................................... 57 Slika 26: Primerjava med vstopnimi in odgovorjenimi klici med leti 2007

in 2013. ........................................................................... 58 Slika 27: Primerjava vstopnih klicev med leti 2011 in 2013. .......................... 63



KAZALO TABEL Tabela 1: Prioritete incidentov in reakcijski časi. ...................................... 31 Tabela 2: Primerjava števila vstopnih klicev in odgovorjenih klicev med

letoma 2011 in 2012. ............................................................ 34 Tabela 3: Primerjava števila sporočil, puščenih na avtomatskem odzivniku,

in prekinjenih klicev v 5 in 10 sekundah med letoma 2011 in 2012. ..... 34 Tabela 4: Primerjava števila prekinjenih klicev v 30 in 60 sekundah med

letoma 2011 in 2012. ............................................................ 35 Tabela 5: Primerjava števila zgrešenih klicev med letoma 2011 in 2012. ........... 35 Tabela 6: Primerjava povprečnega časa pogovora v sekundah med letoma

2011 in 2012. ..................................................................... 36 Tabela 7: Primerjava povprečnega časa čakanja pogovora v sekundah med

letoma 2011 in 2012. ............................................................ 36 Tabela 8: Primerjava povprečnega časa čakanja v vrsti v sekundah med

letoma 2011 in 2012. ............................................................ 37 Tabela 9: Primerjava stopnje uspešnosti kontaktnega centra med letoma

2011 in 2012. ..................................................................... 37 Tabela 10: Primerjava opravljenih delovnih dni in rešenih nalog po agentih

med letoma 2011 in 2012. ...................................................... 38 Tabela 11: Primerjava odprtih nalog po agentih med letoma 2011 in 2012. ........ 39 Tabela 12: Primerjava odgovorjenih telefonov po agentih med letoma 2011

in 2012. ........................................................................... 40 Tabela 13: Primerjava razmerja med odprtimi nalogami in odgovorjenimi

klici po agentih med letoma 2011 in 2012. .................................. 41 Tabela 14: Primerjava odstotka rešenih nalog v istem dnevu po agentih med

letoma 2011 in 2012. ............................................................ 42 Tabela 15: Povprečni čas reševanja incidentov po agentih v letih 2011

in 2012. ........................................................................... 43 Tabela 16: »SuperUser« koncept v CPU, kjer so z zeleno barvo označena

»SuperUser« področja. .......................................................... 45 Tabela 17: Primerjava klicev med posameznimi enournimi časovnimi intervali

med 2011 in 2012. ............................................................... 46 Tabela 18: Primerjava klicev med posameznimi 15-minutnimi časovnimi

intervali med 2011 in 2012. .................................................... 48 Tabela 19: Odstotek zgrešenih klicev po enournih intervalih v letih 2011

in 2012. ........................................................................... 49 Tabela 20: Odstotek zgrešenih klicev v letih 2011 in 2012. ........................... 49 Tabela 21: Zasedenost agentov po enournih intervalih v letih 2011 in 2012. ....... 50 Tabela 22: Primerjava števila vstopnih klicev in odgovorjenih klicev med

letoma 2012 in 2013. ............................................................ 59 Tabela 23: Primerjava števila sporočil, puščenih na avtomatskem odzivniku,

in prekinjenih klicev v 5 in 10 sekundah med letoma 2012 in 2013. ..... 59 Tabela 24: Primerjava števila prekinjenih klicev v 30 in 60 sekundah med

letoma 2012 in 2013, ............................................................ 60 Tabela 25: Primerjava števila zgrešenih klicev med letoma 2012 in 2013. ......... 60 Tabela 26: Primerjava povprečnega časa pogovora med leti 2012 in 2013. ........ 61 Tabela 27: Primerjava povprečnega časa čakanja na pogovor v letih 2012

in 2013. ........................................................................... 61 Tabela 28: Povprečni čas čakanja v vrsti med leti 2012 in 2013. ..................... 62 Tabela 29: Stopnja uspešnosti kontaktnega centra med leti 2012 in 2013. ......... 62



Tabela 30: Odstotek zgrešenih klicev po enournih intervalih v letu 2013. .......... 63 Tabela 31: Zasedenost agentov po enournih intervalih v letu 2013. ................. 64 Tabela 32: Primerjava odstotka zgrešenih klicev po enournih intervalih med

leti 2012 in 2013. ................................................................ 65 Tabela 33: Primerjava opravljenih delovnih dni in rešenih nalog po agentih

v letu 2013. ....................................................................... 65 Tabela 34: Primerjava odprtih nalog po agentih med letoma 2011 in 2012. ........ 66 Tabela 35: Primerjava odgovorjenih telefonov po agentih med letoma 2011

in 2012. ........................................................................... 66 Tabela 36: Primerjava razmerja med odprtimi nalogami in odgovorjenimi

klici po agentih v letu 2013. ................................................... 67 Tabela 37: Primerjava odstotka rešenih nalog v istem dnevu po agentih v

letu 2013. ......................................................................... 68 Tabela 38: Povprečni čas reševanja incidentov po agentih v letu 2013. ............ 68 Tabela 39: Odstotek zgrešenih klicev med leti 2011 in 2013. ......................... 69 Tabela 40: Povprečje odgovorjenih klicev na dan med leti 2011 in 2013. .......... 69 Tabela 41: Odstotek rešenih incidentov v istem dnevu med leti 2011 in 2013. .... 69 Tabela 42: Povprečni čas reševanja incidenta med leti 2011 in 2013. ............... 70 Tabela 43: Razmerje med odprtimi nalogami in odgovorjenih klici med

leti 2011 in 2013. ................................................................ 70 Tabela 44: Primerjava skupnega števila rešenih nalog med leti 2011 in 2013. ..... 70

KRATICE IN AKRONIMI BSI: British Standards Institution CMS : Configuration Management System COBIT: Control Objective over Information and Related Technology CPU: Center za podporo uporabnikom ERP: Enterprise resource planning HIPAA: Health Insurance Portability & Accountability Act iz 1996 ISACA: Information System Control Standard ISO: International Organization for Standardization IT: Informacijska Tehnologija ITIL: Information Technology Infrastructure Library MS: MicroSoft OGC: Office of Government Commerce SD: Service Desk SLA: Service Level Agreement (Dogovor o stopnji storitev) SOX: Sarbanes-Oxley Act iz 2002 SQL: Structured Query Language VPN: Virtual Private Network

Documents

IZBOLJŠAVE PROCESA V CENTRU ZA PODPORO UPORABNIKOM · 2017. 11. 28. · Univerza v Mariboru ² Fakulteta za organizacijske vede Diplomsko delo visokoolsko strokovnega tudija Jožef