22 OPTIMIZACIJA REŠEV ANJA INCIDENTA V STORITVENEM CENTRU Avtor: Damjan Jarc B2 Visoka šola za poslovne vede, Managment in informatika (2. stopnja) Povzetek V podjetju je zaposlenih približno 6000 ljudi, kateri uporabljajo več različnih vrst informacijske tehnologije. To obsega uporabo osebnih računalnikov, tiskalnikov, mobilne telefonije, IP telefonije, radijskih naprav in tako naprej. Prej ali slej se uporabniki srečajo s težavo, ki je lahko tehnične narave, ali pa so enostavno sami premalo tehnično podkovani, da bi lahko sami odpravili napako. S tem namenom deluje v podjetju storitveni center, ki je na voljo uporabnikom od ponedeljka do petka ob 6.00 do 18.00 ure. Uporabniki različnih sistemov lahko incident prijavijo preko elektronske pošte ali pa enostavno preko telefonskega klica. Storitveni center odpravi težavo sam, ali pa jo posreduje naprej v kolikor je ne morejo odpraviti sami. V tej seminarski nalogi je predstavljeno, kako bi lahko izboljšali samo delovanje storitvenega sistema, da bi se napake odpravljale v najkrajšem možnem času. Predvsem bomo poskušali najti, kje in zakaj v postopku poslovnega procesa pride do napak, ter kako jih odpraviti. Ključne besede: podjetje, storitveni center, poslovni proces. Uvod Namen prispevka je ugotoviti, kje prihaja do težav, ter le te sistematično odpraviti. Na ta način bi od identifikaciji problema v poslovnem procesu lahko izboljšali sam proces, s čimer bi dosegli večje zadovoljstvo uporabnikov oziroma strank, ter seveda zagotavljali nemoteno delovanje vseh delujočih sistemov. Z razvojem tehnologije se predvsem zaradi nepoznavanja in neusposobljenosti uporabnikov žal pojavljajo tudi težave. V našem podjetju imamo vzpostavljen storitveni center, kateri je namenjen prijavi oziroma identifikaciji težave v informacijskem sistemu. Ta prijava se zabeleži v sistem kot incident in se v nadaljevanju seminarske naloge tako tudi imenuje. Incidenti so predvsem tehnične težave, za katere so večinoma recimo temu krivi uporabniki sami, predvsem zaradi tehničnega neznanja samih uporabnikov, v določenih primerih pa so seveda težave dejansko tudi s strani tehnike same. Kot že omenjeno je storitveni center prvi odzivnik, kateri sprejme določen incident, katerega poizkusijo odpraviti sami, v kolikor pa to presega njihove zmogljivosti, ta incident predajo naprej na ustrezen nivo, seveda z obzirom na tehnično zahtevnost. Težava ni v tem, da se incidenti ne uspejo odpraviti, temveč v tem, da incidenti ostanejo odprti dlje časa, kot je to predvideno za določen nivo oziroma stopnjo nujnosti. Kot že omenjeno težava ni ta, da se incident nebi odpravil, ampak v tem, da se incident odpravi, akterji, ki so incident odpravili ga enostavno ne zaprejo. To meče slabo luč na storitveni center, predvsem iz vidika statistike, kjer se beleži koliko časa je bilo porabljeno za odpravo incidenta, saj so za vse določene neke norme, katerih se je potrebno držati. Kar pa je najbolj pomembno 23 tukaj je, da težava ni v njihovem delu, temveč v delu končnih akterjev, kateri ne zaključijo svojega dela v celoti. Sama prijava incidenta, poteka tako, da uporabnik zazna težavo in jo preko telefonskega klica ali pa preko maila javi v storitveni center, ki incident zabeleži. Operater v klicnem centru se lahko na daljavo priklopi na delovno postajo (računalnik) in preveri če lahko odpravi napako. V kolikor ne more odpraviti te napake na daljavo, incident prenese na oddelek lokalne podpore, ki je najbližje lociran fizičnemu mestu prijave napake. Zaposleni v oddelku lokalne podpore nato gredo fizično preveriti, če lahko odpravijo napako na mestu. V kolikor je tudi oni ne morejo odpraviti, ali za to nimajo pristojnosti, ali pa nimajo rezervnih delov, se potem recimo v tem primeru delovno postajo odnese v ustrezno IT delavnico, kjer imajo vse od zgoraj naštetega. Oddelek lokalne podpore preda delovno postajo v tehnično delavnico oziroma tehnični podpori, kjer napako odpravijo. Nato delovno postajo iz delavnice predajo nazaj v lokalno podporo, katera delovno postajo preda nazaj od koder so jo dobili. Tekom vseh prenosov med ustreznimi oddelki je potrebno v sistem beležiti vse informacije, da imamo vedno na voljo sledljivost incidenta. V kolikor nekdo tega ne zabeleži se sled lahko izgubi, kar potem povzroča težavo pri gledanju statistike. T eoretska izhodišča Ker moramo vedno strmeti k izboljšavam je nujno, da tudi podjetja strmijo k sistematični identifikaciji ključnih pomanjkljivosti v delovanju poslovnih procesov. Sama identifikacija pomanjkljivosti še ni tako kompleksna, kot je kompleksno identificirane težave potem rešiti oziroma odpraviti. Definitivno tukaj ne gre brez ustrezne strategije. Samo z ustrezno nastavljeno strategijo lahko vodilni kader usmerja svoje podrejene na poti k izboljšavam (Norton, 2002, stran 1-5). Poslovni procesi večinoma prehajajo skozi različne organizacijske strukture, zato jih je potrebno opredeliti, zasledovati in ugotavljati, kje se začnejo in končajo, predvsem pa katere aktivnosti se vmes dogajajo, ter kdo pri njih sodeluje (Tkalec Goršek, 2008, stran 44). V današnjem času so povsod v ospredju kupci oziroma stranke. Vsako podjetje se zaveda, da je za podjetje ključno, da so stranke zadovoljne s storitvami, ki jih podjetje ponuja. Ravno zaradi tega se podjetja odločajo za procesni pristop reševanja poslovnih procesov. Vedno so na prvem mestu stranke. Podjetja so torej stalno pod vprašanjem, kako oblikovati svojo strukturo, da bi le ta omogočala ustrezno horizontalno in vertikalno povezanost s strankami (Karmen Verle, 2008, stran 237). Po drugi strani pa Spany (2006, stran 76) opozarja, da uvedba procesne organiziranosti zahteva temeljit razmislek, kaj sploh hočemo doseči s procesno strukturo. Seveda je ključno, da že v štartu pravilno zastavimo korake procesnega pristopa. Ko se namreč odločimo za izboljšavo nekega procesa je prvi korak najti idejo za njegovo oblikovanje. Naslednji korak je analiza morebitnih težav, ki bi lahko negativno vplivale na izvedbo procesa. Sledi določanje aktivnosti, ki so del posameznega procesa. Na koncu pa sledi še najpomembnejša faza, in sicer implementacija, kjer morajo sodelovati vsi vključeni akterji, seveda s končnim ciljem, to je zadovoljiti stranko oziroma uporabnika (Karmen Verle, 2009, stran 55). Glavne prednosti, ki se tu pokažejo so zmožnost prilagajanja podjetja, boljše izkoriščanje dane opreme in znanja ljudi, jasno začrtana smer razvoja podjetja, predvsem pa boljša komunikacija in izboljšan pretok informacij med posameznimi akterji. Vse zgoraj opisano lahko z eno besedo imenujemo torej modeliranje, katerega cilj je vzpostaviti nek model oziroma sliko iz recimo temu 24 realnega sveta, katere odražajo trenutno stanje. Da pa bi v celoti lahko uporabili modeliranje se moramo za vse omenjene izboljšave poslovnih procesov izbrati nek model, po katerem se bomo ravnali. Model nam torej prikazuje realno sliko ali stanje, ter v njem problem oziroma težavo, katero bi radi izboljšali ali odpravili. Če pogledamo realen primer potem se z uporabo modelov srečamo večkrat. Dober primer je izdelava modela oziroma načrta za gradnjo hiše. V tem modelu je točno določeno kako bo hiša izgledala, kakšne barve bo fasada, kakšno bo ogrevanje, kako bomo uredili okolico in tako naprej. Modele uporabljamo pri raziskovanju in reševanju problemov na najrazličnejših področjih (Kovačič in Vukšić, 2007, stran 177). Cilji teoretičnega dela Cilji teoretičnega dela so identificirati težave, ter jih nato kot rešitev implementirati v praktičnem delu. Predvsem ključnega pomena v samem procesu delovanja je sprejem prijave napake, kjer moramo v največji meri pobrati vse potrebne podatke, da lahko težavo čimprej odpravimo. Na koncu pa nas vedno zanima statistika trajanja odprtega incidenta, glede na stopnjo njegove zahtevnosti, kjer se poraja največ napak, saj se incidenti odpravijo, s samem sistemu pa se ne zaprejo. Raziskovalne trditve – hipoteze S pregledom poslovnih procesov lahko lociramo kje prihaja do pomanjkljivosti, ter kako jih odpraviti. Tukaj lahko zaradi preobremenjenosti operaterjev pride do pomanjkanja koncentracije in posledično ne pridobijo dovolj potrebnih informacij. Hipoteza 1. Operaterji v storitvenem centru dovolj natančno pridobijo čim več potrebnih informacij za uspešno nadaljnje reševanje incidenta. Hipoteza 2. Incident se ob dejanski odpravi napake zapre dovolj hitro. Omejitve naloge Omejitve same naloge so kratkega časovnega roka otežen v smislu, da bi lahko učinkovito razdrobili vse vmesne poslovne procese, ter jih čim bolj detajlno preučili. Prav tako je sama implementacija teoretične rešitve v sistem otežena, saj se take odločitve sprejemajo kar nekaj nivojev višje nad nami. Mi sicer lahko same izboljšave za bolj učinkovito opravljanje dela podamo, ni pa nujno da bodo le te upoštevane. 25 Metodologija dela Kot metodo dela za primerjavo obstoječega in željenega stanja smo uporabili metodo TAD (angl. Tabular Application Development), ki je že preizkušena in na njeni podlagi sloni več primerov dobrih praks. ZA izris procesov pa smo uporabili program Aris Express. Identifikacija ključnih procesov Ključni dejavnik v samem procesu reševanja incidentov je že v samem začetku, in sicer že pri sprejemu incidenta. Tu je ključnega pomena, da se od kličočega, torej osebe, ki incident prijavlja, izve in zabeleži čim več informacij, ki bi lahko bile koristne. Tukaj vidim težavo, da so operaterji pogosto preobremenjeni, ter tako posledično kakšno pomembno informacijo enostavno pozabijo zabeležiti, kar je lahko ključno pri nadaljnji obravnavi in odpravi incidenta. Naslednji pomemben dejavnik je identifikacija prijavljene napake. Tukaj pa težava ni v operaterjih v storitvenem centru, temveč pri osebah, ki incident prijavljajo, saj so le te po navadi nevešče uporabe informacijskih sredstev, vsaj pri tej situaciji, ko pride do težave. Tukaj je zelo pomembno, da v kolikor se lahko operater na daljavo poveže recimo na uporabnikov osebni računalnik sam preveri kakšna je napaka, seveda v kolikor je tukaj težava v programskem delu računalnika. V kolikor je težava v strojni opremi se najverjetneje napake ne bo dalo odpraviti na daljavo, temveč bo potrebno incident posredovati nivo višje – torej na oddelek lokalne podpore. Naslednji ključen proces je odpravljanje napake. Odpravljanje napake je seveda odvisno od same narave napake, kar ugotovijo tehniki v lokalni podpori ali pa kasneje v tehnični podpori. V spodnji tabeli 1 si lahko pogledamo poslovne procese. Poslovno področje Delovni proces 1 Sprejem incidenta (mail ali po telefonu) Delovni proces 2 Identificiranje težave Delovni proces 3 Odpravljanje težave Storitveni center X X X Oddelek lokalne podpore X X X Tehnična podpora X X X Tabela 1: Identifikacija obstoječih poslovnih/delovnih procesov. 26 Tabela lastnosti klasičnega - ročnega načina poslovanja za PROCES kataloške prodaje (AS-IS) Tabela lastnosti elektronskega poslovanja za PROCES kataloške prodaje (TO-BE) Aktivnost Čas (min) Stroški EUR Čas (min) Stroški EUR Sprejemanje strankinega klica 10 2,38 15 2,50 Poskušanje odprave incidenta v storitvenem centru na daljavo 10 1,67 10 1,67 Preusmerjanje incidenta na naslednjo stopnjo (oddelek lokalne podpore) 10 1,67 5 0,83 Sprejemanje incidenta oddelka za lokalno podporo 10 1,67 10 1,67 Odpravljanje incidenta s strani lokalne podpore 240 40,00 240 40,00 Preusmerjanje incidenta na višji nivo (tehnična podpora) 10 1,67 10 1,67 Odpravljanje težave s strani tehnične podpore 240 40,00 240 40,00 Zaključevanje incidenta 30 5,00 20 3,33 Tabela 2: Tabela aktivnosti obstoječega in prenovljenega poslovnega procesa. Model – bpmn grafična notacija obstoječega pop (as – is) Slika 1: Aris notacija poteka procesa. 27 Na zgornji sliki 1 lahko vidimo, potek procesa vse od sprejetja oziroma prijave napake pa do zaključevanja incidenta. V proces je v začetku vključen samo storitveni center, kateri se potem glede na kompleksnost incidenta odloči, komu ga preusmeri. Model – bpmn grafična notacija prenovljenega pop (to-be) V našem primeru se po natančnejšem pregledu procesov ne gre za dejansko spremembo samih procesov, temveč za bolj detajlni pristop k vsakemu od procesov, s ciljem zmanjšati reševalni čas. Učinki izboljšav Tabela lastnosti klasičnega - ročnega načina poslovanja za PROCES kataloške prodaje (AS-IS) Tabela lastnosti elektronskega poslovanja za PROCES kataloške prodaje (TO-BE) Spreme- mba ČAS Spreme- mba stroški EUR Spreme- mba stroškov v % (TO- BE) Aktivnost Čas (min) Strošk i EUR Čas (min) Stroški EUR Sprejemanje strankinega klica 10 2,38 15 2,50 5,00 0,12 5,00% Poskušanje odprave incidenta v storitvenem centru na daljavo 10 1,67 10 1,67 0,00 0,00 0,00% Preusmerjanje incidenta na naslednjo stopnjo (oddelek lokalne podpore) 10 1,67 5 0,83 -5,00 -0,83 -50,00% Sprejemanje incidenta oddelka za lokalno podporo 10 1,67 10 1,67 0,00 0,00 0,00% Odpravljanje incidenta s strani lokalne podpore 240 40,00 240 40,00 0,00 0,00 0,00% Preusmerjanje incidenta na višji nivo (tehnična podpora) 10 1,67 10 1,67 0,00 0,00 0,00% Odpravljanje težave s strani tehnične podpore 240 40,00 240 40,00 0,00 0,00 0,00% Zaključevanje incidenta 30 5,00 20 3,33 -10,00 -1,67 -33,33% 560 94,05 300 50,00 0 -44,05 -46,84% Tabela 3: Ponazoritev preteklega in izboljšanega procesa z izračunom. 28 Če pogledamo primerjavo oziroma izboljšavo procesov, vidimo, da se pri več aktivnostih da doseči časovno izboljšanje. Edino pri prvi aktivnosti, ki je sprejemanje strankinega klica, smo dali večji poudarek temu, da se pridobi čim več informacij zaradi lažjega reševanja v nadaljnjem delu. Kar pomeni, da imajo tukaj operaterji na voljo več časa, kar se na koncu izkaže kot bolj učinkovito. Poleg tega, glede na to da se okoli 60% incidentov zaključi s strani tehnične podpore bi bila ključna presoja operaterjev v storitvenem centru, da identificirajo stopnjo incidenta in ga že v začetku posredujejo direktno na tehnično podporo. Na ta način bi lahko prihranili okoli 50% časa in stroškov. Zaključek Na začetku zastavljen cilj smo tekom seminarske naloge uspešno identificirali in izboljšali. Dejanskih korakov oziroma aktivnosti nismo zmanjšali kot takih, ampak smo določene aktivnosti skrajšali, saj so vzele preveč časa. Eno izmed aktivnosti pa smo celo podaljšali, saj je le ta ključnega pomena, kar se tudi v praksi izkaže tako. Sprejem in beleženje čim več podatkov od klicatelja je namreč ključno za nadaljnjo obravnavo, zato smo kot že omenjeno tukaj dali operaterjem na voljo celo še več časa. S tem lahko ovržemo hipotezo 1, ki pravi, da ob klicatelja prejmemo dovolj podatkov. Ugotovljeno je, da zaradi preobremenjenosti operaterjev namreč prihaja do pomankanja koncentracije, kar privede do pomanjkljivih nujno potrebnih informacij. Seveda je za odpravo takih anomalij v poslovnih procesih potrebno predvsem več časa, da bi lahko z gotovostjo trdili, da so le te res odpravljene. Smiselno bi bilo torej opazovati poslovne procese dalj časa, da bi dobili še bolj relevantne podatke. Kar se tiče hipoteze 2 je bilo ugotovljeno tudi, da se po odpravi napake velikokrat incidente pozabi zaključiti, kar kazi statistiko. Tukaj je definitivno potrebno dati večji poudarek na doslednost vseh vpletenih, predvsem pa da končni reševalec res zaključi incident, sploh ker mu ne vzame toliko časa. Če potegnemo črto bi ob pravilni presoji storitvenega centra in ob direktnem posredovanju incidenta takoj na tehnično podporo lahko prihranili 50% časa in stroškov. TAD metoda se je izkazala kot preprosta in koristna metoda, saj lahko na podlagi nekaj aktivnosti hitro vidimo do kakšnih sprememb lahko pridemo z optimizacijo procesov, za kar porabimo res malo časa. Aktivnosti iz TAD metode smo umestili tudi v program Aris Express, kar ni predstavljalo večjega problema, sploh glede na to, da smo se s tem programom srečali prvič. Program je zelo enostaven za uporabo, hkrati pa nam da dober vpogled v poslovne proces in morebitne rešitve oziroma odpravo pomanjkljivosti. Seveda obstaja mnogo načinov, kako izboljšati sam proces odpravljanja napake, veliko pa je tukaj na operaterjih samih kako vestno opravljajo svoje delo. Vsi smo že bili kdaj soočeni s prijavo napake, na koncu pa smo samo naleteli na operaterje, ki so naš zahtevek samo posredovali naprej in nas s tem spravljali v še slabšo voljo. Na temo izboljšav je bilo napisanih kar nekaj diplomskih nalog in člankov, eden izmed zanimivejših je opisan v bistvu v že sami izgradnji storitvenega centra, kjer se že v štartu postavi dobre temelje, na katerih se potem lahko 29 uspešno gradi naprej (Uporaba ITIL in IDEAL pri vzpostavitvi storitvenega centra, 2008, Matjaž Gorenc). Literatura in viri Norton, D. (2002) Strategy Maps. U.S.A. Harvard business school publishing. Tkalec Goršek, N. (2008). Ocenjevanje operativnega tveganja pri poslovnih procesih v banki. Bančni vestnik, 57(7-8), 42-51. Karmen Verle (2008). Procesni pristop kot dejavnik povečanja zadovoljstva odjemalcev. Karmen Verle (2009). Procesni pristop za povečanje uspešnosti in učinkovitosti podjetja v industriji brusov. Kovačič in Vukšić (2005). Managment poslovnih procesov. GV založba.