P1 ဝန်ဆောင်မှု ရပ်ဆိုင်းမှုသည် နည်းပညာဆိုင်ရာ ဖြစ်ရပ် မဟုတ်ပါ။ ယုံကြည်မှုဆိုင်ရာ ဖြစ်ရပ် ဖြစ်သည်။

ဦးစားပေး အဆင့်တစ် incident ဖြစ်ပွားသည့်အခါ IT အဖွဲ့အများစုက ယင်းကို အင်ဂျင်နီယာဆိုင်ရာ ပြဿနာအဖြစ် အလိုလို သဘောထားကြသည်။ ချို့ယွင်းချက်ကို ရှာ၊ ချို့ယွင်းချက်ကို ပြင်၊ ticket ကို ပိတ်။

ထိုသဘောထားကို နားလည်နိုင်ပါသည်။ ထို့အပြင် အဖွဲ့အစည်း အများအပြားသည် P1 တစ်ခုမှ ဝန်ဆောင်မှု ပြန်ရရှိသော်လည်း ဆက်ဆံရေး ထိခိုက်ပျက်စီးလျက် ထွက်လာရခြင်း၏ အကြောင်းရင်းလည်း ဖြစ်သည်။

လုပ်ငန်းဘက်မှ ကြည့်လျှင် ဝန်ဆောင်မှု ရပ်ဆိုင်းမှုသည် stack trace တစ်ခု မဟုတ်ပါ။ ၎င်းသည် ငွေပေးချေမှု လက်မခံနိုင်သော စတိုးဆိုင်၊ ကမ်းပေါ်ရှိ စနစ်များနှင့် ဆက်သွယ်၍ မရသော သင်္ဘောအဖွဲ့သားများ၊ IT ထံမှ မကြားရမီ ဖောက်သည်ထံမှ ဦးစွာ သိရသော ခေါင်းဆောင်အဖွဲ့ ဖြစ်သည်။ နောက်ပိုင်းတွင် ၎င်းတို့ မှတ်မိနေသည့်အရာမှာ အရင်းခံ အကြောင်းရင်း ဖြစ်ခဲသည်။ IT က အခြေအနေကို ထိန်းချုပ်ထားပုံ ပေါ်ခဲ့သလား ဆိုသည်ပင် ဖြစ်သည်။

ကျွန်ုပ်သည် P1 နှင့် P2 incident များအတွက် အဆင့်မြှင့် တင်ပြရာ ဆုံမှတ် (escalation point) အဖြစ် နှစ်ပေါင်းများစွာ တာဝန်ထမ်းဆောင်ခဲ့သည် — မကြာသေးမီက brand အများအပြား ပါဝင်သော လက်လီလုပ်ငန်း ပတ်ဝန်းကျင်တစ်ခုတွင် C-suite escalation ခေါင်းဆောင်အဖြစ် ဖြစ်သည်။ နည်းပညာဆိုင်ရာ ပြင်ဆင်မှုသည် အရေးကြီးသည်။ သို့သော် ယုံကြည်မှုကို တည်ဆောက်ခြင်း သို့မဟုတ် ဖျက်ဆီးခြင်း ပြုသော incident များကို အခြားအရာ သုံးခုက ဆုံးဖြတ်သည်။

1. ပထမ ဆယ့်ငါးမိနစ်က ဇာတ်လမ်းကို သတ်မှတ်သည်

အကြောင်းရင်းကို မည်သူမျှ မသိရသေးမီ လုပ်ငန်းဘက်က အရာသုံးခုကို သိရန် လိုအပ်သည်- IT က သိရှိထားကြောင်း၊ မည်သူ တာဝန်ယူထားကြောင်းနှင့် နောက်တစ်ကြိမ် မည်သည့်အချိန် ကြားရမည် ဖြစ်ကြောင်း။

နောက်ကျပြီး ပြည့်စုံသော စာထက် တိုတောင်းသော ပထမ စာက ပိုကောင်းသည်-

• ထိခိုက်နေသည့်အရာကို စနစ်အမည်များဖြင့် မဟုတ်ဘဲ လုပ်ငန်းဝေါဟာရဖြင့် (“UAE စတိုးဆိုင်များရှိ ကတ်ငွေပေးချေမှုများ”)။
• Incident ကို မည်သူ ပိုင်ဆိုင်သည် — ဖြန့်ဝေစာရင်း (distribution list) မဟုတ်ဘဲ အမည်ဖော်ပြထားသော incident ခေါင်းဆောင် တစ်ဦး။
• နောက် အသိပေးချက် မည်သည့်အချိန် လာမည်၊ ထို့နောက် ပြောစရာ အသစ်မရှိလျှင်ပင် ထိုကတိကို တည်ပါ။

အဓိက incident တစ်ခုတွင် အကုန်ကျဆုံးအရာမှာ တိတ်ဆိတ်နေခြင်း ဖြစ်သည်။ လူများက ယင်းကို အဆိုးဆုံး ယူဆချက်များဖြင့် ဖြည့်ကြပြီး အပြိုင် escalation များ ဖွင့်ကာ အင်ဂျင်နီယာများကို တိုက်ရိုက် စတင် ဖုန်းဆက်ကြသည် — ယင်းက ပြင်ဆင်မှုကို နှေးကွေးစေသည်။

2. ပြင်ဆင်သူများနှင့် ဆက်သွယ်ပြောဆိုသူများကို ခွဲခြားပါ

ဝန်ဆောင်မှုကို ပြန်လည်ရရှိအောင် လုပ်နေသော အင်ဂျင်နီယာများသည် CFO ၏ မက်ဆေ့ချ်များကိုပါ မဖြေသင့်ပါ။

ကောင်းမွန်စွာ စီမံထားသော P1 bridge တစ်ခုတွင် တာဝန်များကို ရှင်းလင်းစွာ သတ်မှတ်ထားသည်-

• Incident ခေါင်းဆောင် — ဆုံးဖြတ်ချက်များ၊ ဦးစားပေးမှုများနှင့် အချိန်ဇယားကို ပိုင်ဆိုင်သည်။
• နည်းပညာ ခေါင်းဆောင်(များ) — ချို့ယွင်းချက်ကို ရှာဖွေ စစ်ဆေးပြီး ပြန်လည်ရရှိစေသည်။
• ဆက်သွယ်ရေး ခေါင်းဆောင် — တိုးတက်မှုကို သတ်မှတ်ထားသော အချိန်ကာလအလိုက် လုပ်ငန်းဆိုင်ရာ အသိပေးချက်များအဖြစ် ဘာသာပြန်ပေးသည်။
• Vendor ခေါင်းဆောင် — ပြင်ပအဖွဲ့များကို ၎င်းတို့၏ စာချုပ်ပါ တုံ့ပြန်ချိန်များအတိုင်း တာဝန်ယူစေသည်။

ယင်းသည် ဗျူရိုကရေစီ မဟုတ်ပါ။ လုပ်ငန်းဘက်က သတင်းရနေစဉ် နည်းပညာအဖွဲ့ကို ရှင်းရှင်းလင်းလင်း တွေးတောနိုင်စေသည့်အရာ ဖြစ်သည်။ ITIL က ဤ practice များကို ဖော်ပြသည်။ စည်းကမ်းမှာ ၎င်းတို့ကို မနက် 2 နာရီတွင် အမှန်တကယ် လုပ်ဆောင်ခြင်း ဖြစ်သည်။

3. ဝန်ဆောင်မှု ပြန်လည်ရရှိစေခြင်းသည် တာဝန်၏ တစ်ဝက်သာ ဖြစ်သည်

ဝန်ဆောင်မှု ပြန်ရသည်နှင့် P1 ကို ပိတ်လိုက်ခြင်းသည် နောက်လတွင် incident တစ်ခုတည်း ပြန်ဖြစ်လာစေသည့် နည်းလမ်း ဖြစ်သည်။

ယုံကြည်မှုကို နောက်ဆက်တွဲ လုပ်ဆောင်မှုတွင် ပြန်လည်တည်ဆောက်သည်- ရှင်းလင်းသော incident ပြီးနောက် သုံးသပ်ချက်၊ လုပ်ငန်းဘက်က နားလည်နိုင်သော အရင်းခံ အကြောင်းရင်းနှင့် ပိုင်ရှင်များ၊ ရက်စွဲများ ပါဝင်သော လုပ်ဆောင်ချက်များ။ ဤနေရာတွင် problem စီမံခန့်ခွဲမှုက ၎င်း၏ တန်ဖိုးကို ပြသည်။ စနစ်တကျ အရင်းခံ အကြောင်းရင်း ခွဲခြမ်းစိတ်ဖြာမှုနှင့် problem စီမံခန့်ခွဲမှုကို ဦးဆောင်ခြင်းဖြင့် ကျွန်ုပ်၏ အဖွဲ့များ ထပ်ခါထပ်ခါ ဖြစ်ပွားသော incident များကို 40% လျှော့ချနိုင်ခဲ့သည် — ပိုမြန်မြန် ပြင်ခြင်းဖြင့် မဟုတ်ဘဲ တူညီသော ချို့ယွင်းမှု နှစ်ကြိမ် မဖြစ်နိုင်အောင် သေချာစေခြင်းဖြင့် ဖြစ်သည်။

အမှုဆောင်အရာရှိများအတွက် ကောင်းမွန်သော incident ပြီးနောက် အနှစ်ချုပ်သည် မေးခွန်း ငါးခုကို စာမျက်နှာ တစ်မျက်နှာတည်းတွင် ဖြေဆိုသည်-

1. ဘာဖြစ်ခဲ့သနည်း၊ လုပ်ငန်းအပေါ် ထိခိုက်မှုမှာ အဘယ်နည်း။
2. မည်မျှ မြန်မြန် ရှာဖွေတွေ့ရှိ၊ တုံ့ပြန်ပြီး ပြန်လည်ရရှိစေခဲ့သနည်း။
3. အရင်းခံ အကြောင်းရင်းမှာ အဘယ်နည်း။
4. မည်သည်ကို ပြောင်းလဲမည်နည်း၊ မည်သူ ပိုင်ဆိုင်မည်နည်း၊ မည်သည့်အချိန်အထိနည်း။
5. ယင်း အလုပ်ဖြစ်ကြောင်း မည်သို့ သိမည်နည်း။

တိုင်းတာရမည့်အရာ

P1 များသည် ယုံကြည်မှုဆိုင်ရာ ဖြစ်ရပ်များ ဖြစ်ပါက ထိုသို့ပင် တိုင်းတာပါ။ ပြန်လည်ရရှိရန် ပျမ်းမျှအချိန် (mean time to restore) နှင့်အတူ အောက်ပါတို့ကို ခြေရာခံပါ-

• Incident ကို ကြေညာသည့်အချိန်မှစ၍ ပထမ လုပ်ငန်းဆိုင်ရာ အသိပေးချက်အထိ ကြာချိန်။
• အသိပေးချက် ကာလ လိုက်နာမှု — ကတိပြုထားသော အသိပေးချက်တိုင်း အချိန်မီ ထွက်ခဲ့သလား။
• ထပ်ဖြစ်သော incident များ — ယခင်က တွေ့ဖူးသော အကြောင်းရင်းရှိသည့် P1 များ၏ အချိုး။
• Incident ပြီးနောက် သုံးသပ်ချက်များမှ အချိန်မီ ပိတ်သိမ်းသော လုပ်ဆောင်ချက်များ။

နောက်ထပ် ဝန်ဆောင်မှု ရပ်ဆိုင်းမှုအတွင်း လုပ်ငန်းဘက်က IT ကို ယုံကြည်မည်လားဆိုသည်ကို ပြောပြသော ကိန်းဂဏန်းများမှာ ဤအရာများ ဖြစ်သည်။

အဆင့် မည်မျှမြင့်မြင့် စံနှုန်း မပြောင်းလဲပါ

ကျွန်ုပ် အတူလုပ်ခဲ့ဖူးသော အကောင်းဆုံး အဓိက incident ခေါင်းဆောင်များသည် တည်ငြိမ်၊ စနစ်ကျပြီး အစဉ်တစိုက် ရှင်းလင်းကြသည်။ ၎င်းတို့သည် တိုတောင်းသော စာများကို ရေးကြသည်။ ပိုင်ရှင်များကို အမည်တပ်ကြသည်။ ၎င်းတို့ လုပ်မည်ဟု ပြောခဲ့သည့်အရာကို ပြောခဲ့သည့်အချိန်တွင် လုပ်ကြသည်။

ယင်းသည် နည်းပညာဆိုင်ရာ ကျွမ်းကျင်မှု မဟုတ်ပါ။ ခေါင်းဆောင်မှုဆိုင်ရာ ကျွမ်းကျင်မှု ဖြစ်သည် — ထို့ပြင် P1 ကို အကျပ်အတည်းမှ IT ကို အားကိုးနိုင်ကြောင်း သက်သေအဖြစ် ပြောင်းလဲပေးသည့်အရာ ဖြစ်သည်။