ITIL အသိပညာထက် ITIL အတွေ့အကြုံက ယခု ပိုအရေးကြီးလာရခြင်း၏ အကြောင်းရင်း

ITIL ကို စဉ်းစားခြင်းမရှိဘဲ လိုက်နာရန် ဘယ်တုန်းကမှ ရည်ရွယ်ထားခြင်း မရှိခဲ့ပါ။ ၎င်းသည် ညွှန်ကြားချက်မဟုတ်ဘဲ ဦးတည်ချက်ကို ပေးသည်။

IT ပညာရှင်အများစုသည် incident နှင့် problem ကြား ကွာခြားချက်ကို အလွတ်ရွတ်ပြနိုင်သည်။ သို့သော် စတိုးဆိုင်ကွန်ရက်တစ်ခုလုံး offline ဖြစ်နေသော မနက် 2 နာရီတွင် ထိုနှစ်ခုအနက် မည်သည့်တစ်ခုကို ယခုချက်ချင်း လုပ်ဆောင်သင့်သည်ကို ပြောနိုင်သူ အလွန်နည်းသည်။ မူဘောင်ကို သိခြင်းနှင့် အသုံးချခြင်းကြား ထိုကွာဟချက်သည် ဝန်ဆောင်မှု အရည်အသွေး အောင်မြင်ခြင်း သို့မဟုတ် ကျဆင်းခြင်းကို ဆုံးဖြတ်သော နေရာ ဖြစ်သည်။

"ယခု" ဟု အဘယ်ကြောင့် ဆိုသနည်း။

ITIL ၏ ယခင်ဗားရှင်းများကို သတ်မှတ်ထားသော လုပ်ငန်းစဉ်များ (processes) အပေါ် တည်ဆောက်ထားသည်။ သီအိုရီအရ ၎င်းတို့ကို အဆင့်ဆင့် လိုက်နာနိုင်သည်။

ITIL 4 သည် လုပ်ငန်းစဉ်များကို လုပ်ငန်းကျင့်စဉ်များ (practices)၊ လမ်းညွှန်မူများ (guiding principles) နှင့် တန်ဖိုးစီးကြောင်းများ (value streams) ဖြင့် အစားထိုးခဲ့သည်။ ITIL (Version 5) သည် ထို့ထက် ပိုသွားသည်: Transformation သည် ယခု အဆင့်အမည်တိုင်းတွင် ပါဝင်ပြီး အလေးပေးမှုသည် လုပ်ငန်းကျင့်စဉ်များကို ကောင်းစွာ လည်ပတ်ခြင်းမှ ၎င်းတို့မှတစ်ဆင့် ပြောင်းလဲမှုကို ဦးဆောင်ခြင်းသို့ ရွှေ့သွားသည်။

မူများပေါ်တွင် တည်ဆောက်ထားသော မူဘောင်ကို စစ်ဆေးစာရင်းကဲ့သို့ အကောင်အထည်ဖော်၍ မရပါ။ မူတစ်ခုစီသည် ဤ အဖွဲ့အစည်း၊ ဤ ဝန်ဆောင်မှုနှင့် ဤ အန္တရာယ်အပေါ် မည်သို့ သက်ဆိုင်သည်ကို တစ်စုံတစ်ယောက်က ဆုံးဖြတ်ရမည်။ ထိုဆုံးဖြတ်ချက်သည် ဆင်ခြင်ဆုံးဖြတ်နိုင်မှု (judgement) ဖြစ်ပြီး ဆင်ခြင်ဆုံးဖြတ်နိုင်မှုသည် အတွေ့အကြုံမှ လာသည်။

စစ်ဆေးစာရင်း မဟုတ်ဘဲ လမ်းညွှန်ချက်

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

လက်မှတ်က သင် လမ်းညွှန်ချက်ကို သိကြောင်း သက်သေပြသည်။ အတွေ့အကြုံဆိုသည်မှာ တစ်ခုခုသော အင်္ဂါနေ့တွင် ၎င်း၏ မည်သည့်အပိုင်းက အရေးအကြီးဆုံး ဖြစ်သည်ကို သိခြင်း ဖြစ်သည်။

ဝန်ဆောင်မှုတိုင်းတွင် Service Owner တစ်ဦး လိုအပ်သည်

"ဝန်ဆောင်မှုကို IT က ပိုင်ဆိုင်သည်" ဆိုသည်မှာ မည်သူမျှ မပိုင်ဆိုင်ဟု ဆိုလိုသည်။

ဝန်ဆောင်မှုတိုင်းတွင် Service Owner တစ်ဦးတည်း လိုအပ်သည်: အခြားအဖွဲ့များနှင့် ပံ့ပိုးသူများက ပေးပို့သော အစိတ်အပိုင်းများ အပါအဝင် ၎င်း၏ စွမ်းဆောင်ရည်အတွက် အစမှအဆုံး တာဝန်ခံသော အမည်ပါ ပုဂ္ဂိုလ်တစ်ဦး ဖြစ်သည်။ Service Owner သည် ချို့ယွင်းချက်တိုင်းကို ကိုယ်တိုင် မပြင်ပါ။ ချို့ယွင်းချက်များ ပြင်ဆင်ခံရရန်၊ တိုးတက်မှုများ ရန်ပုံငွေရရန်နှင့် ရလဒ်အတွက် တစ်စုံတစ်ယောက်က တာဝန်ခံဖြေရှင်းရန် သေချာစေသူ ဖြစ်သည်။

ဤသည်မှာ စမ်းသပ်ချက် ဖြစ်သည်။ ကွန်ရက်အဖွဲ့၏ firewall ပြောင်းလဲမှုတစ်ခု မအောင်မြင်သောကြောင့် လစာစနစ်သည် ၎င်း၏ SLA ကို လွဲချော်သည်။ CFO ထံ ထိုအကြောင်းကို မည်သူ ရှင်းပြမည်နည်း။ အဖွဲ့သုံးဖွဲ့က တစ်ဖွဲ့ကို တစ်ဖွဲ့ လက်ညှိုးထိုးနေပါက ထိုဝန်ဆောင်မှုတွင် ပိုင်ရှင် မရှိပါ။ Service Owner သည် ဖုန်းခေါ်ခံရသူ ဖြစ်ပြီး နောက်ထပ် firewall ပြောင်းလဲမှုက လစာစနစ်ကို ထပ်မထိခိုက်စေရန် သေချာစေသူ ဖြစ်သည်။

ဦးစွာ ပြန်လည်ထူထောင်ပါ၊ ထို့နောက် အကြောင်းရင်းကို ဖယ်ရှားပါ

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

အမှားမှာ ထိုနေရာတွင် ရပ်လိုက်ခြင်း ဖြစ်သည်။ အီးမေးလ်သည် တစ်ပတ်အတွင်း သုံးကြိမ် ပြတ်တောက်ပါက ၎င်းသည် ဆက်စပ်မှုမရှိသော incident သုံးခု မဟုတ်ပါ။ ၎င်းသည် problem တစ်ခုတည်းကို ညွှန်ပြနေသော incident သုံးခု ဖြစ်ပြီး တစ်စုံတစ်ယောက်က အရင်းခံအကြောင်းရင်းကို ရှာဖွေဖယ်ရှားသည်အထိ စတုတ္ထမြောက် ပြတ်တောက်မှုသည် အချိန်ဇယားဆွဲပြီးသား ဖြစ်နေသည်။

အဓိပ္ပာယ်ဖွင့်ဆိုချက်များကို သိရန် လွယ်ကူသည်။ အတွေ့အကြုံဆိုသည်မှာ ပုံစံကို စောစီးစွာ သတိပြုမိခြင်း၊ လူတိုင်း ရှေ့ဆက်လိုနေချိန်တွင် problem record တစ်ခု ဖွင့်ရန် စည်းကမ်းရှိခြင်းနှင့် အရင်းခံအကြောင်းရင်း ခွဲခြမ်းစိတ်ဖြာမှုကို ပိုင်ရှင်နှင့် ရက်စွဲပါသော လုပ်ဆောင်ချက်များအဖြစ် ပြောင်းလဲခြင်း ဖြစ်သည်။ စနစ်တကျ problem management သည် ကျွန်ုပ်၏အဖွဲ့များ ထပ်ခါထပ်ခါဖြစ်သော incident များကို 40% လျှော့ချနိုင်ခဲ့ပုံ ဖြစ်သည်: ပိုမြန်မြန် ပြင်ခြင်းဖြင့် မဟုတ်ဘဲ တူညီသော ချို့ယွင်းမှု နှစ်ကြိမ် မဖြစ်နိုင်အောင် သေချာစေခြင်းဖြင့် ဖြစ်သည်။

သင့်လျော်သော ထိန်းချုပ်မှုပမာဏဖြင့် ပြောင်းလဲမှု

ပြောင်းလဲမှုသည် ပုံမှန်ဖြစ်သည်။ ကျွမ်းကျင်မှုမှာ ထိန်းချုပ်မှုကို အန္တရာယ်နှင့် ကိုက်ညီအောင် ပြုလုပ်ခြင်း ဖြစ်သည်။

• Standard ပြောင်းလဲမှုများ သည် အန္တရာယ်နည်းပြီး ထပ်ခါလုပ်နိုင်ကာ ကြိုတင်ခွင့်ပြုထားသည်။ စမ်းသပ်ပြီးသော pipeline မှတစ်ဆင့် တင်ပို့သော ပုံမှန် patch တစ်ခုသည် ဘုတ်အဖွဲ့ကို စောင့်ရန် မလိုသင့်ပါ။
• Normal ပြောင်းလဲမှုများ သည် တကယ့်အန္တရာယ်ကို သယ်ဆောင်ပြီး ၎င်းနှင့် အချိုးကျသော အကဲဖြတ်မှုနှင့် ခွင့်ပြုချက် လိုအပ်သည်။
• Emergency ပြောင်းလဲမှုများ သည် မြန်မြန်ဆန်ဆန် လုပ်ဆောင်ရမည် ဖြစ်သော်လည်း မှတ်တမ်းတင်ခြင်းနှင့် သုံးသပ်ခြင်း ပြုလုပ်ရဆဲ ဖြစ်သည်။

ပြောင်းလဲမှုတိုင်းကို အန္တရာယ်မြင့်အဖြစ် သဘောထားပါက ပေးပို့မှု ရပ်တန့်သွားသည်။ ပြောင်းလဲမှုတိုင်းကို ပုံမှန်အဖြစ် သဘောထားပါက နောက်ဆုံးတွင် တစ်ခုက လုပ်ငန်းကို ရပ်ဆိုင်းသွားစေမည်။ ITIL 4 သည် ထိုအကြောင်းကြောင့်ပင် လုပ်ငန်းကျင့်စဉ်ကို change management မှ change enablement သို့ အမည်ပြောင်းခဲ့သည်: ရည်မှန်းချက်မှာ ပြောင်းလဲမှုကို ရပ်တန့်ရန် မဟုတ်ဘဲ ဘေးကင်းစွာ ဖြစ်ပေါ်စေရန် ကူညီခြင်း ဖြစ်သည်။

ပြောင်းလဲမှုတစ်ခု မည်သည့်အမျိုးအစားတွင် ပါဝင်သည်ကို ဆုံးဖြတ်ခြင်းသည် ဆင်ခြင်ဆုံးဖြတ်ရမည့်ကိစ္စ ဖြစ်သည်။ စည်းမျဉ်းတစ်ခုက "ဒေတာဘေ့စ် ပြောင်းလဲမှုများသည် Normal ဖြစ်သည်" ဟု ပြောနိုင်သည်။ သုံးလပတ်ကုန် စနေ၊ တနင်္ဂနွေတွင် ပြုလုပ်မည့် ဤ ဒေတာဘေ့စ် ပြောင်းလဲမှုကို ဒုတိယအကြိမ် ပြန်ကြည့်ထိုက်သည်ဟု အတွေ့အကြုံကသာ ပြောပြနိုင်သည်။

တိုးတက်မှုသည် နေ့တိုင်း ဖြစ်ပေါ်သည်

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

• ပြဿနာငယ်များကို incident များ မဖြစ်မီ စောစီးစွာ သတိပြုမိခြင်း
• ပြောင်းလဲရေး အစီအစဉ်ကြီးကို စောင့်မနေဘဲ လက်တွေ့ကျသော ပြင်ဆင်မှုများ ပြုလုပ်ခြင်း
• ရလဒ်များကို သုံးသပ်ပြီး ချိန်ညှိခြင်း

ကောင်းစွာ ထိန်းသိမ်းထားသော knowledge base တစ်ခုသည် ကောင်းသော ဥပမာ ဖြစ်သည်။ ၎င်းသည် မဟာဗျူဟာ slide တွင် ပေါ်လာမည် မဟုတ်သော်လည်း အလုပ်များသော ဆက်သွယ်ရေး ပံ့ပိုးမှုပတ်ဝန်းကျင်တစ်ခုတွင် ဖြေရှင်းချိန်များ 35% လျော့ကျလာရသည့် အဓိကအကြောင်းရင်းများထဲမှ တစ်ခု ဖြစ်ခဲ့သည်။

အတွေ့အကြုံက အမှန်တကယ် ဖြည့်စွက်ပေးသည့်အရာ

ITIL သဘောတရားများကို သိခြင်းသည် စတင်ရာနေရာ ဖြစ်သည်။ အတွေ့အကြုံရှိ လက်တွေ့လုပ်ကိုင်သူများသည် အောက်ပါတို့ကိုလည်း သိကြသည်:

• လမ်းညွှန်ချက်ကို မည်သည့်အခါ အနီးကပ် လိုက်နာရမည်၊ အန္တရာယ်မြင့်ပြီး လုပ်ငန်းစဉ်သည် အကြောင်းရင်းတစ်ခုကြောင့် ရှိနေသောကြောင့်
• မည်သည့်အခါ ၎င်းကို ပြုပြင်ညှိယူရမည်၊ စာလုံးအတိုင်း လိုက်နာခြင်းက မည်သည့်အရာကိုမျှ ပိုဘေးကင်းစေခြင်း မရှိဘဲ လုပ်ငန်းကို နှေးစေမည် ဖြစ်သောကြောင့်
• လုပ်ဆောင်မှုကို မဟုတ်ဘဲ ရလဒ်ကို မည်သို့ တိုင်းတာရမည်: ပိတ်ခဲ့သော ticket များကို မဟုတ်ဘဲ လုပ်ငန်းက လိုအပ်သည့်အချိန်တွင် ရရှိနိုင်ခဲ့သော ဝန်ဆောင်မှုများ

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

နိဂုံး

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

နောက်ဆုံးတွင် ITIL သည် လူများနှင့် တကယ့်တန်ဖိုးကို ပေးပို့ခြင်းအကြောင်း ဖြစ်သည်။

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