IT PASLAUGŲ VALDYMAS
Kai incidentai kartojasi, SLA nutolsta nuo verslo lūkesčių, o atsakomybė pasimeta tarp komandų ir tiekėjų, problema retai būna įrankyje. Išgryniname, kas iš tiesų matuojama, kur dingsta atsakomybė ir kokį sprendimą reikia priimti.
KADA VERTA ĮTRAUKTI
Ne kiekvienai problemai reikia naujos sistemos. Dažniausiai reikia aiškumo, kas kam atsakingas.
01
Simptomai gesinami greitai, tačiau problemų valdymo praktikos nėra, todėl tas pats gedimas grįžta po mėnesio.
02
Rodikliai skaičiuojami, bet nesusieti su sprendimais: neaišku, kas reaguoja, kai riba pažeidžiama, ir ką tai keičia.
03
Kai vieno inžinieriaus nėra, procesas sustoja. Žinios laikomos galvose, o ne aprašuose.
04
Kiekvienas tiekėjas atlieka savo dalį, tačiau paslaugos visuma lieka be savininko.
KĄ GAUNATE
Galima pradėti nuo vieno etapo ir sustoti — kiekvienas duoda savarankišką rezultatą.
01
Fiksuotos apimties peržiūra: ITSM praktika, incidentų ir problemų eiga, SLA, eskalavimo keliai, prioritetų logika ir tai, kas realiai už ką atsako.
Rezultatas: prioritetizuotas gerinimo planas su atsakingais, darbo apimtimi ir laukiamu poveikiu.
02
Išgryniname, kas matuojama ir kodėl, suderiname rodiklius su verslo lūkesčiais ir susiejame juos su konkrečiais sprendimais bei eskalavimu.
Rezultatas: SLA rinkinys, kurį supranta ir IT, ir verslas, su aiškia reagavimo tvarka.
03
Einu paslaugų teikimo vadovo pareigas organizacijoms, kurioms funkcijos reikia, bet etato — ne. Praktika patikrinta valdant kelių klientų paslaugas.
Rezultatas: funkcija veikia kasdien, praktika sukurta ir perduota jūsų komandai.
KAIP DIRBAME
A
Verslo tikslas, paslaugų sąrašas, komandos, tiekėjai, rizikos ir realūs apribojimai — be prielaidų.
B
Prioritetai, atsakomybės, eskalavimo tvarka, rodikliai ir atgalinio kelio planas.
C
Praktika patikrinama realiais incidentais, o ne lentelėje: matuojame, ar sprendimo laikas ir kokybė iš tikrųjų keičiasi.
D
Dokumentacija, veiksmų aprašai ir žinios, kurių komandai reikia dirbti savarankiškai.
DUK
ITSM (IT paslaugų valdymas) yra būdas IT traktuoti kaip paslaugas su aiškiais savininkais, rodikliais ir tvarka, o ne kaip gedimų srautą. Formalaus ITSM reikia ne visiems, bet atsakomybės ir eskalavimo aiškumo reikia kiekvienai organizacijai, kurios veikla priklauso nuo IT.
Dažniausiai ne. Didžioji dalis problemų kyla ne iš įrankio, o iš neaiškių atsakomybių, prioritetų ir eskalavimo. Pirmiausia sutvarkome praktiką; tik tada matyti, ar esamos sistemos tikrai nepakanka.
Incidentų valdymas atkuria paslaugą kuo greičiau. Problemų valdymas ieško priežasties, kad incidentas nesikartotų. Organizacijos, kurios turi tik pirmąjį, gesina tuos pačius gaisrus metų metus.
Prasmingas SLA susietas su verslo pasekme ir turi savininką, kuris reaguoja, kai riba pažeidžiama. Jei rodiklis matuojamas, bet niekas nekeičia elgesio jį pažeidus, tai ataskaita, ne susitarimas.
Fiksuotos apimties vertinimas paprastai užtrunka kelias savaites — priklauso nuo paslaugų skaičiaus ir nuo to, kaip greitai pasiekiami žmonės bei duomenys. Pabaigoje gaunate prioritetizuotą planą, o ne bendrą auditą.
Taip. Patirtis apima paslaugų teikimą pagal formalius viešuosius pirkimus ir apimties bei biudžeto valdymą tokiomis sąlygomis.
KITOS PASLAUGOS
PAVYZDŽIAI
Konkretūs pavyzdžiai: nuo kokios situacijos pradedama, kas daroma ir pagal ką vertinama, ar suveikė.
PRADĖKIME
Naudingiausias pirmas pokalbis — apie tai, kas iš tikrųjų negerai: pasikartojantys incidentai, nutolę SLA arba atsakomybė, kurios niekas neprisiima.