Programska oprema za vodenje servisnih zahtevkov v podjetju

Kaj je programska oprema za vodenje servisnih zahtevkov?#

Programska oprema za vodenje servisnih zahtevkov je sistem, ki zajame vsako prijavo napake, motnje ali zahteve za spremembo, jo razvrsti po nujnosti in pristojnosti ter dodeli odgovorni osebi ali ekipi. Namesto da zahtevek obtiči v e-poštnem predalu posameznika, je viden vodji oddelka, odgovorni osebi in po potrebi tudi vodstvu, ki spremlja obremenjenost ekip in čas reševanja. Tako postane vsak zahtevek sledljiv od prijave do zaprtja, kar v večjem podjetju bistveno zmanjša število izgubljenih ali pozabljenih primerov.

Tak sistem ni zgolj orodje za IT-oddelek. V podjetju z več kot milijon evrov letnih prihodkov servisne zahtevke pogosto sprožajo tudi proizvodnja, kadrovska služba, nabava ali finance, zato rešitev deluje kot skupen delovni tok, ki povezuje različne oddelke znotraj enega administracijskega sistema. Vsak oddelek vidi samo svoje zahtevke in njihovo stanje, vodstvo pa pregled čez celotno obremenitev in zastoje.

Obseg take rešitve sega od preprostega seznama zahtevkov do celovitega administracijskega sistema s poročanjem, revizijsko sledjo in povezavo na druge sisteme podjetja, kot so ERP, CRM ali dokumentni sistem. To, kako širok naj bo sistem in katere podatke mora prikazovati posamezni oddelek, je eno od prvih vprašanj, ki jih mora podjetje razrešiti, preden izbere izvajalca ali začne z razvojem lastne rešitve.

Kdaj podjetje potrebuje sistem za vodenje servisnih zahtevkov?#

Podjetje potrebuje namenski sistem za vodenje servisnih zahtevkov takrat, ko zahtevki prihajajo po več kanalih - po e-pošti, telefonu ali osebno - in jih nihče ne beleži na enem mestu, zaradi česar se izgubljajo odzivni čas, odgovornost in pregled nad tem, kaj je še nerešeno. Če vodja oddelka ne more v nekaj minutah povedati, koliko odprtih zahtevkov ima njegova ekipa, je to znak, da obstoječ način dela ni več zadosten.

Potreba se običajno pokaže, ko podjetje raste in se poveča število oddelkov, lokacij ali sistemov, ki jih je treba vzdrževati. Enak vzorec se pojavi po združitvi dveh organizacij, uvedbi novega proizvodnega obrata ali razširitvi na novo lokacijo, ko se podvoji število naprav, zaposlenih in zahtevkov, obstoječ način sledenja v preglednicah ali e-poštnih nitih pa tega obsega ne zdrži več.

V javnem sektorju in reguliranih panogah je razlog pogosto drugačen: potrebna je revizijska sled, ki dokazuje, kdaj je bil zahtevek prijavljen, kdo ga je obravnaval in kdaj je bil zaprt. Brez take sledi je težko utemeljiti porabo časa, dokazati odzivnost ali odgovoriti na vprašanje nadzornega organa, zato postane sistem za vodenje zahtevkov del širše zahteve po dokumentiranem in sledljivem poslovanju.

Katere oddelke in sisteme mora rešitev povezati#

Preden se podjetje odloči za sistem, mora določiti, kateri oddelki bodo zahtevke prijavljali in kateri jih bodo reševali, ker ta odločitev določa strukturo pravic, obrazcev in kategorij znotraj sistema. V večjem podjetju to običajno niso le informatiki, temveč tudi vzdrževanje v proizvodnji, kadrovska služba pri zahtevkih zaposlenih, nabava pri naročilih opreme in finance pri odobritvah stroškov, zato mora rešitev podpirati različne kategorije zahtevkov in različne lastnike posameznih kategorij.

Drugo vprašanje je, s katerimi obstoječimi sistemi se mora rešitev povezati prek API-ja, da ne nastanejo podatki, ki obstajajo samo na enem mestu. Zahtevek, povezan z okvaro stroja, je smiselno povezati z evidenco opreme v proizvodnem sistemu, zahtevek za novo opremo zaposlenega pa s kadrovsko evidenco ali nabavnim sistemom, da se izognemo dvojnemu vnosu podatkov in neskladjem med evidencami.

Ko so oddelki in povezave določeni, je treba odločiti še, ali bo sistem samostojna rešitev z integracijami v ERP in CRM ali modul znotraj obstoječega administracijskega sistema podjetja. Obe poti sta izvedljivi, izbira pa vpliva na to, koliko podatkov se podvaja, kako hitro se sistem uvede in koliko vzdrževanja bo zahteval v naslednjih letih, ko se bodo oddelki in procesi spreminjali.

• IT in infrastruktura (strojna in programska oprema, dostopi)
• proizvodnja in vzdrževanje opreme
• kadrovska služba (zahtevki zaposlenih, opremljenost delovnih mest)
• nabava in dobavitelji (naročila, popravila, reklamacije)
• finance (odobritve, stroški vzdrževanja)
• dokumentni sistemi za hrambo poročil in navodil

Kako poteka servisni zahtevek od prijave do zaprtja?#

Servisni zahtevek gre skozi štiri korake: prijavo, razvrstitev po nujnosti, dodelitev odgovorni osebi ali ekipi in reševanje, ki se zaključi z zaprtjem in zapisom o tem, kaj je bilo narejeno. Vsak korak mora biti v sistemu časovno zaznamovan, da je pozneje mogoče preveriti, koliko časa je zahtevek čakal na posamezni stopnji in kje v procesu nastajajo največji zamiki, kar je osnova za izboljšave v naslednjem obdobju.

Razvrstitev po nujnosti je ključna, ker določa, kateri zahtevki se obravnavajo takoj in kateri lahko počakajo na naslednjo redno objavo sprememb. V praksi se uveljavijo razredi od izpada celotnega sistema do manjše napake, ki ne vpliva na poslovanje, in zahteve za novo funkcionalnost, ki se uvrsti v naslednji razvojni cikel. Taka razvrstitev je del dogovora o ravni storitve (SLA), ki ga podjetje sklene z izvajalcem ali notranjo ekipo za podporo.

Odzivni čas za posamezen razred ni enak za vsa podjetja, zato ga določi pogodba o podpori glede na kritičnost poslovanja in dogovor med naročnikom in izvajalcem. Pomembnejše od enotne številke je, da je razvrstitev jasna vsem, ki zahtevke prijavljajo, in da vodstvo ob koncu obdobja vidi, koliko zahtevkov je bilo rešenih znotraj dogovorjenega razreda in koliko jih je zamujalo, saj to kaže, ali je raven podpore še ustrezna glede na rast podjetja.

• Razred 1 - izpad: sistem ali ključni del ne deluje, obravnava ima najvišjo prednost
• Razred 2 - motnja: sistem deluje, posamezna funkcija pa ne, obravnava poteka po dogovorjeni prednosti
• Razred 3 - napaka: manjša napaka brez vpliva na poslovanje, uvrsti se v naslednjo objavo
• Razred 4 - zahteva: sprememba ali nadgradnja, obseg se oceni in termin uskladi

Lasten razvoj ali prevzem obstoječega sistema#

Podjetje, ki še nima sistema za vodenje zahtevkov, se odloča med razvojem nove rešitve in prevzemom ali nadgradnjo obstoječega, pogosto nedokončanega sistema, ki ga je zapustil prejšnji izvajalec ali notranja ekipa. Obe poti sta mogoči: prevzem obstoječega sistema poteka po pregledu izvorne kode, arhitekture, infrastrukture in podatkov, da se ugotovi, kaj je mogoče obdržati in kaj je treba zamenjati, preden se nadaljuje z razvojem novih funkcionalnosti.

Pri obeh poteh je smiselno, da projekt vodi določen projektni vodja, ki je odgovoren za roke, način komunikacije in poročanje med naročnikom in izvajalno ekipo. Pri večjih projektih se poleg vodje določijo tudi odgovornosti posameznih ekip, kar je pomembno, kadar sistem hkrati razvija več ljudi ali kadar se povezuje z več oddelki in obstoječimi sistemi podjetja, od proizvodnje do kadrovske evidence.

Projekt je mogoče naročiti v celoti - od analize zahtev do uvedbe in podpore - ali po posameznih sklopih, na primer najprej modul za IT-zahtevke in pozneje razširitev na proizvodnjo ali kadrovsko službo. Taka postopna uvedba zmanjša tveganje, ker podjetje preveri delovanje enega sklopa, preden vanj vključi preostale oddelke in poveča obseg podatkov in uporabnikov v sistemu.

Kako je zagotovljena varnost podatkov pri vodenju servisnih zahtevkov?#

Varnost pri vodenju servisnih zahtevkov je zagotovljena z ločenimi razvojnim, testnim in produkcijskim okoljem, nadzorovanimi dostopi do podatkov in jasno določenim lastništvom izvorne kode in podatkov, ki vedno ostanejo pri naročniku. V testnem okolju se ne uporabljajo resnični osebni podatki, kar zmanjša tveganje, da bi se občutljivi podatki o zaposlenih ali strankah znašli zunaj nadzorovanega okolja med razvojem ali testiranjem novih funkcionalnosti.

Vsaka sprememba na sistemu gre pred objavo v produkcijsko okolje skozi pregled in testiranje, kar preprečuje, da bi nepreverjena koda vplivala na delujoč sistem, v katerem zaposleni dnevno prijavljajo in rešujejo zahtevke. Ob primopredaji sistema so dokumentacija, dostopi in gesla del dogovorjene predaje naročniku, ki tako ohrani popoln nadzor nad tem, kdo lahko dostopa do podatkov in jih spreminja, tudi po zaključku sodelovanja z izvajalcem.

Znotraj delivery strukture Epixa in njegove specialistične partnerske mreže se pri takih projektih upoštevajo standardi za upravljanje informacijske varnosti in zasebnosti podatkov, kot sta ISO 27001 in ISO 27701, kar je pomembno predvsem pri zahtevkih, ki vsebujejo osebne podatke zaposlenih, strank ali poslovne skrivnosti podjetja. Za podjetje to pomeni, da varnostne zahteve niso prepuščene naključju, ampak so del dogovorjenega načina dela.

• ločena razvojna, testna in produkcijska okolja
• izvorna koda in podatki ostanejo v lasti naročnika
• dokumentacija, dostopi in gesla so del primopredaje
• brez pravih osebnih podatkov v testnem okolju
• pregled in testiranje vsake spremembe pred objavo
• nadzor dostopov glede na vlogo uporabnika

Kakšen je vpliv na zaposlene in obstoječe delovne procese?#

Uvedba sistema za vodenje servisnih zahtevkov najbolj spremeni to, da zaposleni zahtevka ne pošljejo več po e-pošti ali osebno sodelavcu, temveč ga prijavijo v skupnem sistemu, kjer je viden status, odgovorna oseba in zgodovina reševanja. Za marsikaterega zaposlenega je to sprememba navade, zato je smiselno vnaprej pojasniti, zakaj je nov način dela potreben in kaj posamezni oddelek pridobi s tem, da ima pregled nad svojimi odprtimi zahtevki.

Pri uvedbi je treba določiti tudi, kdo znotraj posameznega oddelka prevzame vlogo reševalca zahtevkov in kdo ima pravico zahtevke potrjevati ali jih preusmerjati na drug oddelek. Jasno določene vloge preprečujejo, da bi zahtevek obtičal med dvema oddelkoma, ker nihče ni formalno odgovoren zanj, kar je pogost vzrok za nezadovoljstvo zaposlenih in strank s starim, neformalnim načinom reševanja.

Dolgoročno sistem zaposlenim prinese manj prekinitev, ker se zahtevki ne rešujejo več sproti prek klicev in sporočil, temveč po vrstnem redu in nujnosti, ki je vidna vsem vpletenim. Vodje oddelkov dobijo pregled nad obremenjenostjo svojih ekip, kar jim omogoča, da pravočasno prerazporedijo delo ali utemeljijo potrebo po dodatnih kadrih glede na dejansko število, vrsto in nujnost prejetih zahtevkov v posameznem obdobju.

Testiranje in kakovost pred uvedbo#

Preden se sistem za vodenje zahtevkov uvede v produkcijsko okolje, je treba pripraviti testne scenarije, ki pokrijejo prijavo zahtevka, razvrstitev, dodelitev, reševanje in zaprtje za vsako vlogo uporabnika posebej. Testiranje poteka ročno in avtomatizirano, pri čemer avtomatizirani testi preverjajo, da sprememba v enem delu sistema ne pokvari delovanja drugega, kar je pomembno, kadar je sistem povezan z več obstoječimi sistemi podjetja.

Poseben del testiranja je preverjanje povezav prek API-ja z drugimi sistemi podjetja, na primer s kadrovsko evidenco ali nabavnim sistemom, da se zagotovi, da podatki med sistemi ostanejo skladni. Pred objavo v produkcijo se izvede tudi regresijsko testiranje, ki preveri, da prejšnje funkcionalnosti še delujejo, potem ko je bila dodana nova funkcionalnost ali popravljena napaka.

Zadnji korak pred uvedbo je prevzemno testiranje, pri katerem naročnik preveri delovanje sistema po vnaprej dogovorjenih merilih, preden ga potrdi za uporabo v vsakdanjem delu. Pri večjih ali bolj zahtevnih projektih je smiselno, da prevzemno testiranje in del avtomatiziranega testiranja izvaja neodvisen QA, ločen od razvojne ekipe, kar zmanjša tveganje, da bi napake, ki jih je spregledal razvijalec, ostale neopažene do uvedbe.

• priprava testnih scenarijev za vsako vlogo uporabnika
• ročno testiranje ključnih poti skozi sistem
• avtomatizirano testiranje za preverjanje vpliva sprememb
• testiranje povezav z drugimi sistemi prek API-ja
• regresijsko testiranje pred vsako objavo
• prevzemno testiranje po dogovorjenih merilih
• neodvisen QA, ločen od razvojne ekipe

Vzdrževanje in podpora po uvedbi#

Po uvedbi sistema za vodenje servisnih zahtevkov se lahko izvajalec, ki ga je razvil, prevzame tudi nadzor nad njegovim delovanjem, odpravo napak in nadaljnji razvoj, kar podjetju omogoča, da se osredotoči na svoje delo, ne pa na vzdrževanje informacijskega sistema. Obseg podpore se določi po projektu, odvisno od tega, kako kritičen je sistem za vsakodnevno poslovanje podjetja in koliko oddelkov je od njegovega delovanja odvisnih.

Podpora po uvedbi običajno vključuje dogovorjene odzivne čase glede na razred nujnosti, tehnične in varnostne posodobitve sistema ter obravnavo novih zahtev za spremembe, ki jih prinesejo spremembe v poslovanju podjetja. Odzivni časi niso enaki za vsa podjetja, ker je kritičnost sistema za vodenje zahtevkov odvisna od tega, koliko oddelkov in procesov se nanj dnevno zanaša, zato jih določi pogodba o podpori, ne splošno pravilo.

Varnostne posodobitve so pri sistemu, ki hrani podatke o zaposlenih, strankah ali dobaviteljih, posebej pomembne, ker se z njim sčasoma povezuje vse več drugih sistemov podjetja. Redno vzdrževanje zmanjšuje tveganje, da bi postal sistem s časom ranljiva točka, mimo katere nihče ne skrbi, kdo ima vanj dostop in kakšne podatke lahko vidi ali spreminja.

Kako izbrati izvajalca za sistem vodenja servisnih zahtevkov?#

Pri izbiri izvajalca za programsko opremo za vodenje servisnih zahtevkov morate preveriti, ali lahko prevzame projekt v celoti ali po posameznih sklopih, ali ima izkušnje s prevzemom obstoječih, nedokončanih sistemov in kako ureja odgovornost, dokumentacijo in podporo po uvedbi. Izvajalec, ki ponuja samo razvoj brez jasno določenega načina dela po uvedbi, podjetje dolgoročno izpostavi tveganju, da ostane s sistemom brez podpore.

Pri večjih projektih je smiselno, da izvajalec določi projektnega vodjo in sestavi ekipo glede na potrebe projekta - od poslovnih analitikov, ki zahteve posameznih oddelkov prevedejo v specifikacijo, do razvijalcev, arhitektov in strokovnjakov za varnost, ki poskrbijo, da je sistem varno povezan z obstoječimi sistemi podjetja. Epix in njegova specialistična partnerska mreža tako lahko sestavita ekipo, prilagojeno obsegu posameznega projekta.

Ker podjetja, ki potrebujejo sistem za vodenje servisnih zahtevkov, delujejo v različnih panogah - od proizvodnje do javnega sektorja - je koristno, da ima izvajalec izkušnje z delom v regulirani ali revizijsko zahtevni panogi, ne le s splošnimi poslovnimi aplikacijami. To je pomembno predvsem takrat, kadar morajo zahtevki in njihovo reševanje ostati dokumentirani za potrebe nadzora ali revizije, ki jo izvaja nadzorni organ ali notranja revizija podjetja.

Cene take rešitve podjetje ne more primerjati samo po funkcionalnostih, ker je odvisna tudi od tega, koliko obstoječih sistemov je treba povezati, kakšne so zahteve glede varnosti in revizijske sledi, ali je potreben mobilni del in kakšna raven podpore se dogovori po uvedbi. Zato se cena določi šele po pregledu zahtev in obsega, pred tem pa je smiselna krajša analiza, ki obseg razčleni na sklope, tako da je vsak sklop ocenljiv in izvedljiv ločeno.

• preverite referenc in izkušnje izvajalca po panogah, v katerih deluje vaše podjetje
• preverite, ali lahko prevzame obstoječ ali nedokončan sistem
• preverite, kako določa projektno vodenje in odgovornost
• preverite varnostne procese in ločena razvojna, testna in produkcijska okolja
• preverite dogovorjeno podporo in odzivne čase po uvedbi
• preverite prilagodljivost glede obsega - celoten projekt ali posamezen sklop