Uživatelská podpora

Celý IT svět bychom moh­li roz­dě­lit na dvě základ­ní čás­ti:

1. BUILD (s cílem aby to bylo zít­ra lep­ší)
2. RUN (s cílem aby to fun­go­va­lo dnes)

Vidí­te, že obě čás­ti se dopl­ňu­jí – pomo­cí buil­du budu­je­me nová IT řeše­ní, ino­vu­je­me, mění­me stá­va­jí­cí řeše­ní, zvy­šu­je­me či udr­žu­je­me kon­ku­ren­ce­schop­nost. Jakmi­le však něja­ké řeše­ní nasa­dí­me, je potře­ba zajis­tit jeho hlad­ký běh – a o to se sta­rá run. Jeho cílem je zajis­tit sta­bi­li­tu, dostup­nost IT řeše­ní, spo­leh­li­vost.

Zla­té pra­vi­dlo zní: Pokud se Run zane­dbá, není čas na Build. Pokud se Build igno­ru­je, fir­ma zasta­rá a zanik­ne.

Obě čás­ti mají své vlast­ní klí­čo­vé met­ri­ky, kte­rým se říká KPI (Key Per­for­man­ce Indi­ca­tor):

• RUN
  • upti­me (jako dlou­ho je sys­tém dostup­ný) s cílem napří­klad 99,98 % defi­no­va­né­ho času
  • reacti­on time (za jak dlou­ho po ode­slá­ní žádosti o pod­po­ru se uži­va­tel dočká prv­ní odpo­vě­di) s cílem napří­klad 15 minut
  • solu­ti­on time (za jak dlou­ho se uži­va­tel­ská žádost vyře­ší) s cílem napří­klad 8 hodin
• BUILD
  • ROI (return of invest­ment = návrat­nost inves­ti­ce) s cílem napří­klad do 5 let
  • time-to-mar­ket (doba trvá­ní vývo­je až po nasa­ze­ní) s cílem napří­klad 6 měsí­ců

Obě čás­ti mají exten­ziv­ně popsa­né pro­ce­sy ve svých stan­dar­dech – napří­klad pro RUN se hoj­ně vyu­ží­vá ITIL™️ a pro BUILD se vyu­ží­vá PRINCE2™️, obě meto­di­ky jsou původ­ně od Bri­tish Gover­n­ment Offi­ce, dnes spo­leč­nost AXELOS®️.

Uživatelská podpora

Uži­va­tel­ská pod­po­ra je jaký­si komu­ni­kač­ní uzel (Sin­gle Point of Con­tact), kam uži­va­te­lé hlá­sí své potře­by a pro­blémy. Nejed­ná se o pou­hou “oprav­nu”, je to správ­ce vzta­hu mezi uži­va­te­li a IT. Pro běž­né uži­va­te­le je prá­vě napří­klad Ser­vi­ce Desk (1. úro­veň uži­va­tel­ské pod­po­ry) jedi­ným vidi­tel­ným IT pra­cov­ní­kem, tudíž i jakousi tvá­ří IT.

V rám­ci uži­va­tel­ské pod­po­ry stan­dard­ně hovo­ří­me o násle­du­jí­cích úrov­ních pod­po­ry:

• Tier 0: self-ser­vi­ce = uži­va­tel si pomů­že sám (manu­á­ly, FAQ)
• Tier 1: ser­vi­ce desk = sbí­ra­jí uži­va­tel­ské poža­dav­ky a řeší základ­ní poža­dav­ky, zby­tek pře­dá­va­jí dále
• Tier 2: tech­ni­cal sup­port = spe­ci­a­lis­té na danou oblast / řeše­ní / apli­ka­ci
• Tier 3: expert sup­port / dev team = samot­ní vývo­já­ři apli­ka­ce či doda­va­te­lé

Service Desk jako Single Point of Contact

Cílem Ser­vi­ce Des­ku je, aby v orga­ni­za­ci (fir­mě, spo­leč­nos­ti) exis­to­val cen­t­rál­ní bod, přes kte­rý pro­jdou všech­ny poža­dav­ky uži­va­te­lů týka­jí­cí se IT. To má něko­lik výhod (jak z pohle­du uži­va­te­lů, tak z pohle­du IT):

• exis­tu­je jen jed­no tele­fon­ní čís­lo / jeden for­mu­lář / jeden email, kam se všich­ni obra­cí se svý­mi poža­dav­ky (jed­no­du­chost a pře­hled­nost)
• poža­da­vek neza­pad­ne – když zavo­lám kama­rá­do­vi = vývo­já­ři kon­krét­ní apli­ka­ce, může se stát, že zapo­me­ne, neu­dě­lá správ­nou věc nebo nedá mému poža­dav­ku správ­nou pri­o­ri­tu, takhle je vše evi­do­vá­no (kon­zis­tent­nost, spo­leh­li­vost)
• efek­tiv­něj­ší prá­ce spe­ci­a­lis­tů – jed­no­du­ché dota­zy a poža­dav­ky vyře­ší SD, na tech­nic­kou pod­po­ru jde pou­ze to, co SD nevy­ře­ší (efek­ti­vi­ta)
• exis­tu­je cen­t­rál­ní obraz o sta­vu IT apli­ka­cí, sys­té­mů (spo­leh­li­vost)

Postup Service Desku

1. sluš­né před­sta­ve­ní, naslou­chá­ní uži­va­te­li
2. zalo­že­ní ticke­tu do ticke­to­va­cí­ho nástro­je
3. ini­ci­ál­ní roz­po­zná­ní typu ticke­tu
   • jed­ná se o chy­bu? –> inci­dent
   • jed­ná se o více­krát hlá­še­nou chy­bu? –> pro­blem
   • jed­ná se o poža­da­vek na změ­nu, kte­rá je v kata­lo­gu? –> ser­vi­ce request
   • jed­ná se o poža­da­vek na změ­nu, kte­rá není v kata­lo­gu? –> chan­ge request

Ser­vi­ce desk jako tako­vý má za úkol ticket zalo­žit, pokud se jed­ná o inci­dent, jehož řeše­ní zná (nebo najde), pomů­že uži­va­te­li, vyře­ší jej a inci­dent uza­vře. Pokud řeše­ní inci­den­tu ser­vi­ce desk nezná, pře­smě­ru­je ticket na 2. úro­veň uži­va­tel­ské pod­po­ry (tech­ni­cal sup­port). Stej­ně tak má ser­vi­ce desk k dis­po­zi­ci kata­log stan­dard­ních poža­dav­ků, kte­ré může vyře­šit (napří­klad insta­la­ce SW, při­po­je­ní tis­kár­ny, reset hes­la, apod.) – to ovšem nejsou inci­den­ty, nýbrž ser­vi­ce reques­ty.

Jak vidí­me již výše, roz­li­šu­je­me něko­lik stan­dard­ních typů ticke­tů:

• Inci­dent – neplá­no­va­né pře­ru­še­ní služ­by, sní­že­ní kva­li­ty služ­by
• Ser­vi­ce Request – poža­da­vek uži­va­te­le na poskyt­nu­tí kata­lo­gi­zo­va­né služ­by (není poru­cha)
• Pro­blem – pří­či­na jed­no­ho nebo více inci­den­tů. Cílem je najít root cause a zabrá­nit opa­ko­vá­ní inci­den­tů.
• Chan­ge Request – poža­da­vek na změ­nu služ­by, jde ke schvá­le­ní na Chan­ge Advi­so­ry Board (CAB)

Kulturní a lidský rozměr

IT pod­po­ra je pou­ze zčás­ti o tech­ni­ce, stej­ně vel­kou část tvo­ří soft-skills:

• empa­tie – uži­va­tel, kte­ré­mu nejde ode­slat objed­náv­ku poté, co dvě hodi­ny vybí­ral zbo­ží do koší­ku, je ve stre­su. Tech­nik musí být klid­ný a komu­ni­ko­vat pro­fe­si­o­nál­ně.
• komu­ni­ka­ce – zaměst­nan­ci Ser­vi­ce Des­ku muse­jí mít schop­nost pře­lo­žit “IT mlu­vu” do sro­zu­mi­tel­né řeči pro běž­né­ho zaměst­nan­ce. Infor­ma­ce, že pro­blém bude vyře­šen až po pora­dě CABu a poté, co trans­port do SA1 schvá­lí Geko, pro­to­že Job­de­sign to udě­lat nemů­že, uži­va­te­li mno­ho nepo­slou­ží.
• doku­men­ta­ce – pokud není záznam v ticke­to­va­cím nástro­ji, jako by se nic nesta­lo. Zákla­dem prá­ce IT jsou data, a ticke­ty v sys­té­mu mají slou­žit pro postup­né zlep­šo­vá­ní.

Rady pod­le ITILu™️, jak se cho­vat v pra­xi: