Tehnička podrška u modernoj softverskoj industriji

(Autor karikature: Peđa Milićević)

Profesionalni korisnici komercijalnih softverskih paketa obično nemaju dovoljno vremena da sami prolaze kroz lavirinte raznih tehničkih problema koji prate moderni softver. Zbog toga je jedan od najbitnijih uslova prilikom donošenja odluke o kupovini nekog softverskog paketa upravo kvalitet tehničke podrške koju taj paket ima.

Kod nas je ova logika do sada bila potpuno drugačija. Na kupovinu softvera se još uvek ne gleda kao na srednjoročnu/dugoročnu investiciju, već pre kao na neobavezni/sporadični trošak koji treba minimizovati. Oni koji donose ovakve odluke najčešće nisu svesni koliko će ih takav stav kasnije koštati u eksploataciji tog softvera kada projekti stoje zbog nekog trivijalnog softverskog problema čije rešenje bi, da imaju ugovor o tehničkoj podršci ili održavanju, bilo svega jedan telefonski poziv ili jedan email daleko.

Uloga

Uloga tehničke podrške u modernoj softverskoj industriji je višestruka. Sem direktne tehničke pomoći korisnicima, tehnička podrška, zbog svog specifičnog položaja i uloge, ima ogroman značaj za poslovne jedinice koje obavljaju istraživanje i razvoj, kao i za one koje se bave proverom kvaliteta proizvoda. S obzirom na to da tehnička podrška kroz upite dobija direktnu povratnu informaciju o kvalitetu proizvoda, statistička analiza upita je od vitalnog značaja za funkcionisanje pomenutih odeljenja, pa samim tim i za softverske kompanije uopšte.

Sem toga, softverske kompanije sve češće uviđaju da su odeljenja tehničke podrške zapravo poslovne jedinice koje imaju najintenzivniju komunikaciju s korisnicima. To im donosi značajnu marketinšku moć i potencijal za koji bi se inače plaćale pozamašne sume novca.

Zbog toga što se tehničkoj podršci ne javljaju samo postojeći korisnici, već često i oni koji evaluiraju proizvod, prodajna odeljenja će takođe očekuju vredne informacije o konkretnim firmama i pojedincima koji treba da budu cilj njihovih aktivnosti. Tehnička podrška ima ključnu ulogu i u prodajnom procesu prilikom potpisivanja velikih ugovora, kada se sa partnerima razmatraju mogućnosti softvera i njegove primene te adaptacija softverskih rešenja u postojećem okruženju.

Konačno, odeljenja tehničke podrške mogu biti uključena i u razne druge aktivnosti poput organizovanja prezentacija i predavanja, učestvovanja na konferencijama, sajmovima i forumima, kao i učestvovanja u većim projektima i/ili na tenderima u formi podrške značajnijim mušterijama i poslovnim partnerima. Većina ovih aktivnosti se vodi kao obrazovne aktivnosti, a one, tradicionalno, naročito u srednjim i manjim kompanijama, spadaju u domen aktivnosti koje najčešće izvodi tehnička podrška.

Organizacija

Zbog značaja i kompleksnosti uloge koju tehnička podrška ima, jasno je da njena organizacija nije trivijalan zadatak. To svakako ne znači da su jedino skupe konsultantske firme sposobne da ostvare taj zadatak, ali znači da će biti potrebna posebna pažnja prilikom dodele resursa jer rad praktično svih drugih odeljenja umnogome zavisi upravo od odeljenja tehničke podrške.

Jedna od osnovnih odluka prilikom organizacije tehničke podrške jeste da li ćete imati centralizovanu tehničku podršku ili će to biti lokalizovane jedinice distribuirane uz prodajne centre i predstavništva. Obe varijante imaju prednosti i mane.

Ukoliko se odlučite za centralizovanu tehničku podršku, imaćete uniformne mehanizme tretiranja upita, mogućnost za optimalnu upotrebu resursa tehničke podrške i ujednačen nivo kvaliteta usluge koju pružate korisnicima. S druge strane, realno je očekivati da će vreme odziva na upite biti promenljivo s obzirom na to da vaši korisnici mogu biti rasuti po vremenskim zonama širom sveta. To samo po sebi ne mora biti veliki nedostatak ovog modela, a zavisi pre svega od tipa softverskog proizvoda i industrije u kojoj se koristi.

Ovaj model je posebno zanimljiv u situaciji u kojoj vaša prodajna mreža i partneri koji distribuiraju vaš proizvod u isto vreme rade i prvi nivo tehničke podrške. Tada se mane ovog modela znatno smanjuju tako da praktično ne postoji prava alternativa ovom modelu.

Lokalne jedinice tehničke podrške od velike su pomoći distribuiranim prodajnim centrima, naročito u pretprodajnoj fazi životnog ciklusa proizvoda na koju prodajna odeljenja tradicionalno stavljaju najveći akcenat. S druge strane, nivo kvaliteta usluge uglavnom zavisi od iskustva i motivacije lokalnih odeljenja, a često i od samog stila menadžmenta pod čijim se nadzorom ova odeljenja nalaze.

Ovaj model je prvi izbor u situacijama u kojima postoje lokalizovane verzije softverskog proizvoda ili u kojima je premošćavanje jezičke barijere u komunikaciji sa korisnicima suviše skupo i nepraktično za centralizovani model. U konkretne prednosti ovog modela spada i kompatibilnost na nivou kulture i mentaliteta osoblja i korisnika, što može pozitivno da utiče na nivo poverenja i ukupnu efikasnost u komunikaciji sa korisnicima. Posebnu pažnju treba posvetiti održavanju centralne baze znanja i komunikaciji među lokalnim centrima tehničke podrške.

Osnovni pristupi

Kada se resursima tehničke podrške upravlja racionalno, njena dejstva se fokusiraju prevashodno na dve ravni: rešavanje incidenata i prevenciju problema. Rešavanje incidenata se najčešće slikovito opisuje kao „gašenje požara”. Aktivnosti u ovoj ravni započinju klasičnim korisničkim upitom sa opisom tehničkog problema sa kojim se korisnik suočava. Ako je tehnička podrška propisno organizovana, korisnički upit će pokrenuti otvaranje novog slučaja i njegovo evidentiranje u sistemu za praćenje upita. Sledi dodela predmeta konkretnom analitičaru tehničke podrške koji će biti zadužen za komunikaciju s korisnikom, vođenje slučaja do njegovog zatvaranja (to jest pronalaženja rešenja tehničkog problema) i ažuriranja svih informacija u vezi sa konkretnim slučajem u sistemu za praćenje upita. Komunikacija s korisnikom najčešće ima dve faze: fazu prikupljanja informacija o problemu i savetodavnu fazu u kojoj analitičar predlaže rešenje za konkretan problem. Kada se od korisnika dobije potvrda o rešenju problema, upit (tj. slučaj) treba zatvoriti u sistemu za praćenje.

Prevencija problema je nešto složeniji proces i zbog toga ga najčešće izvodi menadžer tehničke podrške. Sistemi za praćenje upita najčešće imaju zaseban interfejs namenjen menadžerima tehničke podrške. Ovaj interfejs omogućava da se rade statističke analize upita i da se uz pomoć njih detektuju najčešći i najozbiljniji problemi s kojima se suočavaju korisnici. Zatim se od datih upita prave novi zapisi za baze znanja ili/i izveštaji za razvojni tim ukoliko nije moguće pronaći zadovoljavajuće rešenje za dati problem. Kada se rešenje pronađe, baza znanja se ažurira tako da reflektuje dato rešenje i obaveštavaju se korisnici koji su tražili pomoć u vezi sa datim problemom.

U prevenciji problema, sem statističke analize upita, jako je bitno i iskustvo menadžera tehničke podrške koje će mu omogućiti da na vreme prepozna potencijalno opasne probleme i pre nego što postanu akutni. U tom procesu od vitalnog je značaja komunikacija sa odeljenjem za proveru kvaliteta i koordinacija aktivnosti sa razvojnim timom. Glavni cilj ovih aktivnosti je rešenje novih problema koji će potencijalno pogoditi veliki broj korisnika, u što kraćem roku. Na taj način se resursi tehničke podrške oslobađaju za brojne teže, nepredvidive i nesistemske probleme.

Alat

Softverski alat koji se koristi u tehničkoj podršci brojan je i zavisi pre svega od tipa proizvoda koji podržavate. Alatke za dijagnozu problema najčešće se smatraju najbitnijim jer direktno utiču na brzinu pronalaženja rešenja, a samim tim i na zadovoljstvo i poverenje korisnika. Međutim, često se previđa da je softver za praćenje i evidenciju upita zapravo prva tačka gde se započinje put ka rešenju. Zbog toga je logično da se u toj tački problem prvi put i „napadne” jednostavnom pretragom upita po simptomima. Isti simptomi ne znače uvek i isti problem, ali vam ta prva pretraga upita može skratiti broj opcija koje treba proveriti, što opet može znatno skratiti put do konačnog rešenja problema.

Iz toga se vidi da je izbor softverskog alata za praćenje i evidenciju upita još jedan kritičan momenat u organizaciji tehničke podrške. Hoćete li se odlučiti za specijalno razvijani („custom”) alat ili za neko od postojećih komercijalnih rešenja, zavisi pre svega od toga koliko je složen i specifičan softver koji podržavate. Custom alatke su fleksibilnije, ali zahtevaju veliki trud i investicije, bilo da ih razvijate sami ili to poveravate nekom drugom. S druge strane, komercijalna rešenja su jeftinija i potrebno je manje vremena da ih stavite u pogon. Održavanje ovakvih sistema je i jeftinije od custom rešenja, međutim postoji i druga strana medalje: na komercijalna rešenja imate vrlo ograničen uticaj po pitanju budućeg razvoja i ovo može biti najubedljiviji razlog zbog kojeg ne treba odabrati komercijalno rešenje. Sem toga, prelazak na drugi sistem, ukoliko se dato komercijalno rešenje pokaže kao neadekvatno, može predstavljati komplikovan i skup proces.

Sigurnost podataka je takođe jedna od najčešćih briga za tehničku podršku jer se svi podaci o sigurnosnim mehanizmima najčešće čuvaju kao poslovna tajna. Zbog toga je najsigurnije odabrati proizvod koji ima dužu i poznatu istoriju, čak i ako je nešto skuplji od konkurencije.

I custom i komercijalna rešenja mogu biti lokalna i hostovana (udaljena, engl. remote). Lokalna rešenja se smatraju nešto sigurnijom opcijom jer ćete na nivo sigurnosti moći i sami da utičete. S druge strane, održavanje lokalnih rešenja je nešto komplikovanije i skuplje. Zbog toga su sve popularniji komercijalni hostovani sistemi za praćenje i evidenciju upita. Firme koje izrađuju ove sisteme visoko su specijalizovane, nude dodatnu sigurnost posebnim klauzulama u ugovorima koje potpisuju sa svojim klijentima, a i pouzdanost im je na vrlo visokom nivou jer je interakcija sa korisnicima zasnovana na zrelim Web tehnologijama koje su već izdržale test vremena.

Kao vrlo interesantna opcija pojavljuju se i open source rešenja, naročito u situaciji kada imate sopstveni razvojni tim sposoban da za kratko vreme prilagodi postojeći sistem vašim specifičnim potrebama. Ova rešenja su vrlo funkcionalna, početna ulaganja su minimalna, a mogu biti odličan izbor kada znate u kom pravcu će se razvijati vaša firma i kakve će vam biti potrebe u narednih nekoliko godina.

Praksa

Najbitnija stvar u svakoj tehničkoj podršci, bez obzira na to da li pružate podršku za veš-mašine ili industrijski softver najnovije generacije, jeste komunikacija sa korisnicima. Održati visok, profesionalni nivo komunikacije u često „zapaljivim” situacijama nije jednostavno. Zbog toga morate neprestano imati u vidu šta vam je cilj. Pre svega želite da pomognete korisniku. To neće biti lako, naročito onda kada korisnik nema poverenja u vas i vaš proizvod, a ne zaboravite da vas korisnik neće zvati kada je sve u redu, već samo onda kada je suočen sa problemom. Zbog toga je neophodno da zadržite prijateljski ton u komunikaciji i da pokažete da želite da pomognete. Pre nego što počnete da radite na nekom tehničkom upitu, morate proveriti da li korisnik ima prava na tehničku podršku. Ovo ne sme biti samo filter za odbijanje i smanjenje broja upita jer je ta provera pre svega prilika da korisnika podsetite da treba da obnovi ugovor o tehničkoj podršci ili održavanju softvera ukoliko je istekao. Dobra praksa je da svojim korisnicima ne odbijate prvi zahtev za tehničkom podrškom posle isteka ugovora. Ovakva politika će učvrstiti poverenje koje imate kod korisnika i pojačati njihov osećaj za vrednost usluge koju pružate.

Sledeća kritična tačka u komunikaciji jeste da postavite očekivanje korisnika na odgovarajući nivo. Korisnički zahtevi nisu uvek racionalni, korisnici nisu uvek precizno obavešteni o tome šta mogu da očekuju od tehničke podrške i vašeg proizvoda, mnogi od njih nisu čak ni spremni da rade sa vama na pronalaženju rešenja. Zato je važno da korisniku jasno izložite šta softver može, koliko vi možete da učinite za njega i koje su mu sve opcije na raspolaganju. Ukoliko vaš softver ne može da odgovori na korisnički zahtev, nemojte izbegavati da preporučite drugi softver. Jedna Google pretraga na tu temu košta vas nekoliko sekundi, a često predstavlja razliku između razočaranog i zahvalnog korisnika.

Pošto ste postavili očekivanje korisnika na odgovarajući nivo, da biste krenuli u istraživanje problema, morate da saznate što više o simptomima. Pitanja moraju da budu vrlo konkretna, jednoznačna i da pokriju sve verovatne scenarije. Ukoliko sa svojim korisnicima komunicirate preko emaila (danas preovlađujući metod), treba znati da imate šest do osam email poruka da problem rešite. Dakle, nemate ni vremena ni prostora za nepreciznosti ili lične probleme u komunikaciji.

Kada utvrdite šta se tačno događa kod korisnika, obavezno pokušajte da ponovite problem na sopstvenom računaru – danas to ne bi trebalo da bude problem uz VMWare ili Virtual PC. To će vam omogućiti da problem direktno istražujete i da sva eventualna rešenja proverite pre nego što ih predložite korisniku. Proverena rešenja je najbolje izložiti kao niz jasno definisanih i numerisanih koraka u kojima se ništa ne podrazumeva. Ukoliko je neophodno instalirati neki drajver ili resetovati računar u određenom trenutku, onda to morate jasno reći da biste izbegli nesporazume. Jedna od najčešćih grešaka koje analitičari tehničke podrške čine jeste da naprave bilo kakvu vrstu pretpostavke o tehničkim sposobnostima i obrazovanju korisnika. Ovakva pretpostavka je gotovo uvek pogrešna, znatno otežava već komplikovan posao i zato učinite sebi uslugu i ne upuštajte se u procene sposobnosti korisnika – zdravije je i za vas i za njih.

Biti menadžer tehničke podrške

Tehnička podrška u softverskoj industriji je „pipava” rabota – zahteva sistematičnost, taktičnost, upornost i preciznost. Znatno je drugačija od drugih IT delatnosti jer obuhvata direktnu komunikaciju s korisnicima, što može biti i blagoslov i kazna.

Korisnici najčešće ne znaju da vi ne pravite softver, već ga samo podržavate – zbog toga ćete biti okrivljeni za sve, od pada traljavo instaliranog sistema do pogrešnog naziva nekog menija ili dugmeta.

U pretprodajnim upitima ćete „roditi mečku” da neko od postojećih rešenja adaptirate za potrebe potencijalnog korisnika i posle mesec dana prolivanja znoja pojaviće se neko nalickan s kravatom iz prodaje i pokupiti svu slavu jer je na „vašoj grbači” napravio dil godine.

Ipak, posao je interesantan, broj dnevnih glavolomki je ogroman i one pokrivaju najširi mogući dijapazon. U isto vreme oštrite svoje sposobnosti u komunikaciji i svoja znanja iz IT-a generalno, imate širok pogled na funkcionisanje cele kompanije i na korisničku populaciju koja će vas često „častiti” nekom od novih, neispričanih urbanih legendi iz tehničke podrške. Radićete sa ljudima koji će vas zbog jedne (izgovorene ili napisane) reči kovati u zvezde i sa onima koji će vas, pošto im izložite koncept rada računara, operativnih sistema i kompjuterske grafike u dopisnom kursu od mesec dana, oceniti kao nestručne i bez želje da im pomognete.

I ništa od svega ovog nije pravi razlog zbog kojeg radite posao. Razlog je e-mail koji stiže u pola šest uveče sa samo dve reči: „Hvala, radi!”

Stevan JOSIMOVIĆ