Seniai, kai dar tik mokiausi vieno iš gerųjų praktikų rinkinių – tokios ITIL metodologijos, skirtos IT valdymui, man kilo vienas elementarus klausimas – kodėl problemas ir incidentus reikia spręsti visiškai atskirai, ir tą turi daryti netgi skirtingi žmonės? Ir kodėl viskas taip sudėtingai ir kompleksiškai?
Kai viskas dega ir dega, nėra laiko, kada stabtelti ir pasiaiškinti, kodėl išvis tie gaisrai kyla.
Incidentai ITIL metodologijoje – tai visokie gedimai ir degantys sutrikimai, kai kažkas neveikia čia ir dabar.
Problemos ITIL metodologijoje – tai visokios nežinomos tų incidentų priežastys, dėl kurių tie incidentai kyla ir kartojasi.
Mano klausimas buvo apie tai, kodėl negalima spręsti tų priežasčių kartu su incidentais. Kodėl reikia tą atskyrinėti kaip du paskirus procesus? Juk tik sudėtingiau viskas bus, ir neaišku, ar tos problemos bus išvis išspręstos.
Kiek vėliau, kai pats diegiau tuos procesus didelėje IT įmonėje, pradėjo lįsti įvairios bėdos: žmonės iš padalinio, kuris buvo atsakingas būtent už problemų taisymą, atsisakydavo gilintis į tas problemas, aiškindami aplinkiniams maždaug taip: „čia prisigalvojote patys, tai patys ir taisykite, jei norite, o mums ir taip gedimų per daug, mes ir taip nespėjame„.
Klientų aptarnavimo padalinys, kuris koordinuodavo incidentų sprendimą, ėmė patys daryti problemų paieškas statistikoje – atrasti dažniausiai gendančius taškus. Tačiau netgi suradus ir bakstelėjus į problemą, adminai neretai ilgokai ją ignoruodavo, sakydami, kad ir taip pilna kitų, skubesnių bėdų.
Viso proceso strigimo priežastis buvo paprasta: adminai užsiimdinėjo incidentų valdymu, todėl jiems nuolat degdavo koks nors gaisras, kurį staigiai reikia gesinti. Todėl nebuvo kada aiškintis tų problemų. Netgi kai jų tarpe buvo išskirtas žmogus problemų valdymui, tas žmogus neieškojo tų „nežinomų priežasčių”, nes nuolat būdavo darbo taisyti eilinius gedimus, o gedimai jam atrodė svarbesni. Taigi adminai gesindavo gaisrus, o laiko toms gaisrų priežastims nerasdavo. Ir tai tęsėsi ir tęsėsi.
Vieną kartą visai kitas žmogus, adminų koordinatorius, peržiūrinėdamas ryšio mazgų istoriją, pats ėmė ir atrado krūvas susikaupusių kadaise išspręstų incidentų. Ir jis buvo tiesiog šokiruotas – kai kuriuose mazguose buvo fiksuotos dešimtys gedimų. Koordinatorius suprato, kad pakeitus įrangą, galima staigiai ir pigiai pagerinti gyvenimą visiems, sau pačiam – irgi. Nes jei nėra incidentų, tai nėra ką koordinuoti, vadinasi lengviau yra gyventi. Galima tiesiog ilsėtis. Ir jis ėmė organizuoti tų ryšio mazgų atnaujinimus.
Taip visai netyčia incidentų koordinatorius tapo problemų vadovu, o procesai galų gale bent jau kažkaip atsiskyrė.
Visam tam sprendimui reikėjo, kad darbuotojai vaizdžiai pamatytų savo blogąją praktiką. Tik tada atėjo supratimas, kodėl yra gera ta geroji, bet tam prireikė daugiau kaip metų.
Žvelgiant giliau, problemų valdymas visada yra proakyvus procesas. O incidentų valdymas – visada reaktyvus. Reaktyvūs procesai visada nužudo proaktyvius, jei tik persimaišo. Gera praktika – nemaišyti reaktyvių ir proaktyvių veiklų tarpusavyje. Bet norint suprasti geriausią praktiką ir jos naudą, būtina labai gerai suvokti blogiausią praktiką. Tik tada pasimato gerosios praktikos nauda.
Pratura teikia procesų gerinimo paslaugas įvairiose srityse - projektų valdymo, tiekimo, pardavimų, gamybos, klientų aptarnavimo ir kt..
Susisiekite su mumis ir mes jums padėsime pagerinti procesus jūsų įmonėje:
Parašykite komentarą