Incidentų priskyrimas yra viena iš svarbiausių „ServiceNow“ bilieto gyvavimo ciklo dalių. Jei incidentas pirmiausia pasiekia netinkamą komandą, sprendimas sulėtėja, padaugėja paskyrimų ir pridedama nereikalingų pastangų tiek aptarnavimo tarnybai, tiek palaikymo komandoms.
Daugelyje organizacijų taip nutinka, nes užduotys priklauso nuo rankinio sprendimo arba plačių taisyklių, pagrįstų kategorija ar subkategorija.
Patikimesnis būdas yra naudoti incidente pasirinktą konfigūracijos elementą (CI) ir patraukti palaikymo nuosavybės teisę iš ServiceNow CMDB. Jei CI jau yra apibrėžta palaikymo grupė, ServiceNow gali naudoti šią informaciją, kad automatiškai priskirtų incidentą.
Tai daro maršrutą tikslesnį ir užtikrina, kad incidentas būtų suderintas su faktine platformoje įrašyta nuosavybe. Šiame tinklaraštyje apžvelgsime šį dinamiškesnį požiūrį ServiceNow sprendimai. Logika išlieka ta pati, tačiau priskyrimas keičiasi priklausomai nuo įraše pasirinktos CI.
Kas yra „ServiceNow“ incidentų valdymas?
„ServiceNow“ incidentas yra bet koks neplanuotas pertraukimas, galintis sutrikdyti IT paslaugas. Šie trikdžiai gali būti bet kokie, pavyzdžiui, sugenda serveris arba vartotojas negali prisijungti. Nepriklausomai nuo jų kilmės, šie incidentai trukdo teikti IT paslaugas ir daro didelę įtaką klientų patirčiai.
ServiceNow leidžia įmonėms sistemingai valdyti ir spręsti incidentus. Pirmiausia juos registruoja, tada seka jų kilmę ir randa tinkamus sprendimus, kaip juos ištaisyti. Visas šis procesas vadinamas incidentų valdymu.
Šių incidentų vis iškyla, viskas kartais. Ir įmonės turi juos kuo greičiau išspręsti, kad išlaikytų aukštą paslaugų lygį ir veiklos tęstinumą.
Incidentų valdymas yra pagrindinė programa ServiceNow ITSM modulis. Tačiau jis dažnai veikia ir su kitais moduliais. Visų pirma, jis naudojamas CMDB susieti incidentus su KI ir nustatyti nuosavybės teisę.
Incidentų priskyrimo problemos
Incidentai turi būti paskirti tinkamai komandai, kad ji išspręstų. Jei tai su tinklu susijęs incidentas, jis turi būti priskirtas tinklo komandai. Dabar „ServiceNow“ turi integruotas taisykles, kad incidentų priskyrimas būtų greitas.
Taip pat bus keletas plačių kategorijų, pagal kurias bus nuspręsta, kuriai komandai priklauso incidentas. Tačiau šios kategorijos gali būti pernelyg bendros. Incidentai paprastai nėra juodi ir balti, jie puikiai tinka iš anksto nustatytoms taisyklėms ir kategorijoms.
Čia yra lentelė, kurioje rodomos įprastos ServiceNow incidentų kategorijos ir subkategorijos:
| Kategorija | Subkategorija |
| Užklausa | Antivirusinė el. pašto vidinė programa |
| Programinė įranga | Pašto operacinė sistema |
| Aparatūra | CPU diskinė klaviatūra, atminties monitorius, pelė |
| Tinklas | DHCP DNS IP adresas VPN belaidis ryšys |
| Duomenų bazė | DB2 SQL Server Oracle |
Kartais incidentas yra susijęs su keliomis kategorijomis arba subkategorijomis. Todėl įmonės arba rankiniu būdu priskiria incidentus, arba naudoja AI agentai. Bet kuriuo atveju procesas yra linkęs į klaidas ir sukelia neteisingas užduotis. Dėl to vėluojama ir daug kartų perskirstoma vienai problemai išspręsti.
CMDB kaip priskyrimo šaltinis
„ServiceNow“ CMDB yra ne tik techninių įrašų saugojimo vieta. Tai taip pat padeda apibrėžti nuosavybės teisę ir atsakomybę už konfigūracijos elementus, tokius kaip programos, serveriai, duomenų bazės ir kiti infrastruktūros komponentai.
Kiekvienas incidentas paprastai turi CI. Ir kiekviena CI CMDB jau turi apibrėžtą savininką. Taigi, kai incidentui pasirenkamas CI, tas įrašas pateikia kontekstą apie paveiktą sistemą.
Užuot paprašius agento nuspręsti, kuri komanda turėtų spręsti problemą, „ServiceNow“ gali peržiūrėti pasirinktą CI ir naudoti palaikymo grupę, kuri jau yra tame įraše. Tokiu būdu priskyrimą lemia CMDB duomenys, o ne spėlionės.
Diegimas ServiceNow
Tai galite įgyvendinti naudodami verslo taisyklę incidentų lentelėje. Taisyklė paprastai vykdoma prieš įterpiant, kad priskyrimo grupė būtų nustatyta iš karto, kai tik sukuriamas incidentas. Pirmiausia scenarijus patikrina, ar CI yra ir ar priskyrimo grupė jau užpildyta.
Jei kuri nors sąlyga netinka automatizavimui, scenarijus išjungiamas. Jei yra CI, GlideRecord naudojamas įrašui gauti iš CMDB. Kai randama CI, scenarijus nuskaito palaikymo grupę ir priskiria jai incidentą.
Verslo taisyklės scenarijus
(function executeRule(current, previous) {
if (!current.cmdb_ci || current.assignment_group) {
grąžinti;
}
var ciGR = new GlideRecord(‘cmdb_ci’);
if (ciGR.get(current.cmdb_ci)) {
if (ciGR.support_group) {
current.assignment_group = ciGR.support_group;
}
}
})(dabartinis, ankstesnis);
Pastaba: šis modelis geriausiai veikia, kai palaikymo grupės yra nuosekliai prižiūrimos CI įrašuose CMDB.
Privalumai
Taikant šį metodą pagerėja priskyrimo tikslumas, nes sprendimas grindžiamas CI nuosavybės teise, o ne vien vartotojo įvestimi. Tai taip pat sumažina paskyrimų skaičių, o tai padeda incidentams greičiau pasiekti reikiamą komandą. Kadangi palaikymo grupė palaikoma CI įraše, scenarijus išlieka paprastas ir jo nereikia dažnai keisti pasikeitus nuosavybės teisei. Atnaujinimas vyksta CMDB, o ne kode.
Kitas privalumas yra nuoseklumas. Skirtingi agentai incidentus gali klasifikuoti skirtingai, bet jei jie pasirenka tinkamą CI, platforma vis tiek gali priskirti bilietą standartiniu būdu. Tai daro „ServiceNow“ bilietų pardavimas procesas stabilesnis ir lengviau prižiūrimas.
Incidentų valdymo procesas „ServiceNow“.
„ServiceNow Incident Management“ seka incidento sprendimo gyvavimo ciklą. Incidentai ir jų sprendimo būdai gali skirtis, tačiau jie vyksta pagal tą patį procesą.
Pažvelkime į pagrindinius incidentų valdymo proceso etapus.
1. Aptikimas
Įvykis pirmiausia nustatomas ir užfiksuojamas. Apie tai vartotojai gali pranešti per portalą, telefonu, el. paštu, „walk-in“ arba automatiškai sukurti stebėjimo įrankiais ar kitomis sistemomis.
2. Eskalacija
Užregistravus įvykį, gali būti pranešta tinkamiems žmonėms. Jei problema pakankamai svarbi, ji eskaluojama, kad kažkas greitai imtųsi veiksmų. Ne kiekviena maža problema reikalauja įspėjimo.
3. Suskirstymas į kategorijas
Tada incidentas klasifikuojamas pagal tipą. Paprastai jis pagrįstas kategorija ir subkategorija. Tai padeda teisingai nukreipti ir panašias problemas lengviau išspręsti ateityje.
4. Prioritetų nustatymas
Tada komanda nusprendžia, ar incidentas yra skubus, atsižvelgdamas į poveikį ir skubumą, pvz., kiek vartotojų yra paveiktas arba ar yra finansinė rizika.
5. Užduotis
Priskyrimas apima incidento siuntimą į tinkamą užduočių grupę, o tada paprastai konkrečiam asmeniui, kuris tampa atsakingas už darbą.
6. Diagnozė
Paskirta komanda analizuoja, kad ieškotų priežasties, ir dirba pagal SLA. Jei reikia, jie gali įtraukti kitas komandas. Jei pasikeis prioritetas, SLA tvarkymas „ServiceNow“. taip pat gali pasikeisti.
7. Rezoliucija
Įvykis laikomas išspręstu, kai paslauga atkurta, taikant laikiną sprendimą arba nuolatinį pataisymą.
8. Uždarymas
Patvirtinus, kad problema išspręsta, bilietas uždaromas. Apie sprendimą pranešama suinteresuotosioms šalims, o naudingos pamokos fiksuojamos, kad vėliau būtų galima išvengti panašių incidentų arba juos būtų galima greičiau išspręsti.
Svarstymai
Šio sprendimo sėkmė priklauso nuo CMDB duomenų kokybės. Jei CI įrašuose nėra palaikymo grupių, automatizavimas neveiks nuosekliai. Tai reiškia, kad CMDB turi būti tinkamai prižiūrimas, kad šis dizainas būtų veiksmingas.
Taip pat svarbu nuspręsti, kada taisyklė turėtų būti taikoma. Daugeliu atvejų pakanka paleisti tik ant įdėklo. Tai neleidžia incidentui vėliau priskirti iš naujo, jei kas nors atnaujina CI arba jei priskyrimo grupė jau buvo nustatyta rankiniu būdu.
Kūrėjai taip pat turėtų būti atsargūs, kad be reikalo neperrašytų užduočių grupės. Jei incidentas jau buvo priskirtas pagal kokią nors kitą logiką, scenarijus turėtų į tai atsižvelgti.
Išvada
Dinaminis incidentų priskyrimas ServiceNow gali būti įgyvendintas labai praktiškai, naudojant palaikymo grupę, saugomą pasirinktame konfigūracijos elemente. Užuot pasikliaudama rankiniu maršruto parinkimu ar plačiomis priskyrimo taisyklėmis, platforma gali naudoti CMDB duomenis, kad priimtų tikslesnį sprendimą tuo metu, kai sukuriamas incidentas.
Šis metodas yra paprastas, prižiūrimas ir glaudžiai susijęs su tuo, kaip „ServiceNow“ sukurta naudoti konfigūracijos duomenis. Kūrėjams tai yra puikus pavyzdys, kaip naudoti CMDB ne tik kaip techninę saugyklą, bet ir kaip aktyvią ITSM automatizavimo dalį.
„Xavor’s ServiceNow“ ekspertai sukuria patikimą incidentų valdymo sprendimą, naudodami skirtingus platformos modulius. Užtikriname, kad jūsų IT bilietai visada būtų automatiškai priskiriami atitinkamoms komandoms ir išsprendžiami tiksliai.
Susisiekite su mumis adresu (apsaugotas el. paštu) užsisakyti nemokamą konsultaciją. Mūsų ServiceNow komanda išnagrinės jūsų poreikius ir esamas darbo eigas, kad pateiktų praktiškiausią įgyvendinimo planą.
Apie Autorius
Umair Tariq yra Xavor Enterprise Solutions architektas ir profesionalių paslaugų direktorius. Jis kuria debesų technologijomis pagrįstas, dirbtiniu intelektu pagrįstas platformas sveikatos priežiūros ir mažmeninės prekybos srityse, paversdamas sudėtingus verslo iššūkius keičiamo dydžio, gamybai paruoštais sprendimais. Jis specializuojasi didelio našumo inžinerijos vadovavimo ir HIPAA atitinkančios didelės apimties integracijose.
DUK
CMDB (konfigūracijos valdymo duomenų bazė) ServiceNow yra centralizuota saugykla, kurioje saugoma informacija apie organizacijos IT išteklius ir jų ryšius. Tai padeda komandoms suprasti, kaip sistemos yra sujungtos, o tai leidžia geriau valdyti incidentus, kontroliuoti pokyčius ir atlikti visas IT operacijas.
„ServiceNow“ incidentų valdymas yra procesas, padedantis organizacijoms greitai nustatyti, sekti ir išspręsti IT problemas, kurios sutrikdo normalią veiklą. Tai užtikrina, kad incidentai būtų tvarkomi efektyviai per darbo eigas, prioritetų nustatymą ir automatizavimą, kad paslaugos būtų atkurtos kuo greičiau.
Incidentų valdymo 5 C yra: Suskirstykite į kategorijas, kad nustatytumėte incidento tipą ir pobūdį. Patvirtinkite, kad incidentas yra tikras ir reikia imtis veiksmų. Sudėtyje yra poveikį ribojančių priemonių, kad jis neišplistų. Pataisymas išsprendžia problemą ir atkuria normalią paslaugą. Ir galiausiai, uždarymas – reiškia nutarimo dokumentavimą ir formalų incidento uždarymą.
