သာမန် Daily IT Operation System
company ဒါမှမဟုတ် organization မှာ user က service တစ်ခုခုလုပ်ဖို့ ( ဥပမာ...printer install လုပ်စေချင်တာလိုမျိုး....) request လာမယ်.....အဲဒီ request က verbally-နှုတ်နဲ့ ဖြစ်စေ...email နဲ့ ဖြစ် စေ...IT ဆီကိုရောက်ပါမယ်.... IT တွေမှာကလည်းတစ်ခြားအလုပ်တွေရှိမယ်...အဲဒီ request ရဲ့ priority ကဘယ်လောက်လည်းဆိုတာဘယ်သူမှမခန့်မှန်းနိုင်ဘူး ( urgency case လား....normal case လား...)
နောက်ပြီးတော့ IT တွေထဲကနေဘယ်သူတွေကိုဒီ service ကို assign လုပ်မယ်ဆိုရင် ပိုသင့်တော်မလဲ.... အချိန်တိုအတွင်းမှာ ဒီ service ကိုမြန်မြန်ဆန်ဆန်နဲ့ ဖြေရှင်းပေးနိုင်မယ့် engineer ကို ဘယ်သူက assgin လုပ်မလဲ.( သေချာကတော့ ဒီ issue ကိုသင်က Network Engineer ကို assign လုပ်လို့ မဖြစ်နိုင် ဘူး...သက်ဆိုင်ရာ field က လူကို assign လုပ်တာ correct way ပါ )..
အဲဒီ service monitoring track တွေကို သင်က အလုပ်လုပ်နေတဲ့ engineer အယောက်စီတိုင်းကိုလိုက် မေးပြီး Service Report ရေးရမယ်ဆိုရင်လည်းဒါကအလုပ်မဟုတ်ဘူး...ဒီလိုပဲ ပြီးခဲ့တဲ့ နှစ်လ..သုံးလက service desk issue တစ်ခုကိုသင်က engineer ကိုပြန်မေးမယ်.(အလုပ်လိုအပ်ချက်အရ)...သူလည်းလူ ပဲလေ.... သူအနေနဲ့ senior ကို report လုပ်ပြီးပြီဆိုတာနဲ ့သူလည်းဘယ်မှတ်ထားနိုင်တော့မလဲ....
နောက်တစ်ခုက performance KPI ကိုဘယ်လိုတိုင်းတာကြမလဲ...သာမန် service desk operation မှာ အဲဒီလိုအပ်ချက်တွေအားလုံးကိုပြည့်စုံစေဖို ့မဖြစ်နိုင်ပါဘူး...
Service Desk Ticketing System
အခုမိတ်ဆက်ပေးမယ့် service desk ticketing system ကတော့ ITIL standard အပေါ်မှာအခြေခံ ထားပြီးတော့ user service request ကို ticket ဖွင့်ခိုင်းပါတယ်.... admin user က ticket ဖွင့်ပါတယ်
 |
| User Service Request Ticket Creation |
ကဲ...အဲဒီ ticket သည် Service Desk Team & Leader ဆီရောက်သွားပါပြီ....
ကဲ...Service Desk Team Leader ဆီကိုရော...Service Desk Engineer တွေဆီကိုရော Alert တွေရောက်ပါပြီ...ညာဘက်ထောင့်စွန်းမှာ Activity Stream မှာလည်း Admin User က ticket ကို create လုပ်ထားတဲ့အကြောင်း...Ticket ရဲ့ subject -- Request for Printer installation ဆိုပြီး ticket ဖွင့်ထား တယ်ဆိုတာ..သိနိုင်ပါတယ်...
ကဲ..လောလောဆယ်တော့...ကျွန်တော့် engineer တွေကအကုန်လုံး busy နေလို ့ဒီကွျွန်တော်ကအဲဒီ user ticket ကို on-process အနေနဲ့ reply back လုပ်ပေးလိုက်ပါတယ်. 5-min အတွင်းမှာ service engineer တစ်ယောက်လာလုပ်ပါလိမ့်မယ်ပေါ့ ( * ပုံမှန်အားဖြင့် သက်ဆိုင်ရာ engineer တိုင်းဟာသူတို့ နဲ့ သက်ဆိုင်တဲ့ ticket တွေကို ကိုယ်တိုင် process လုပ်လေ့ရှိပါတယ်)
တကယ်လို့ service engineer က ဒီ ticket ကိုရလို ့သူကိုယ်တိုင်ပြန်မယ်ဆိုရင် လည်း service desk team leader ဆီမှာ သက်ဆိုင်ရာ engineer က process လုပ်နေပြီဆိုတဲ့ alert ပေါ်ပါတယ်... အခုကတော့ကျွန်တော့် engineer တွေက onsite သွားကြတယ်...နောက် ၃-မိနစ်နေရင် printer install လုပ်ပေးမယ့် engineer ကပြန်ရောက်ပြီး ဒီ ticket ကို process လုပ်နိုင်တဲ့အတွက် 5-min အတွင်းလာလုပ်ပေးပါလိမ့်မယ်ဆိုပြီး reply လုပ်ပေးလိုက်ပါတယ်....
Service Desk Team Leader ကပြန်ထားတဲ့ message ကလည်း engineer ဆီကိုရောက်နေပါတယ်... engineer ကပြန်ရောက်ပြီး 5-minutes အတွင်းလုပ်ပေးလိုက်ပါပြီ...ဒီတော့ case close ဖြစ်ပြီး ticket ကို engineer ကိုယ်တိုင်ပိတ်လိုက်ပါပြီ.....
Ticketing System သုံးတဲ့အတွက် evidence ရှိသွားပါတယ်....request user ဘက်ကလည်း ဘယ်အချိန် က service request လုပ်ထားပါတယ်...service desk ဘက်ကလည်း ဘယ်အချိန်ကစပြီး ဒီ case ticket ကို process လုပ်နေပါသလဲ....progress ဘယ်လောက်ရှိနေပြီလဲ....ဒါတွေကို web portal ကနေသိနိုင် သလို email တွေထဲကနေဒီအခြေအနေတွေကိုသိနိုင်ပါတယ်...
တကယ်လို့ engineer တစ်ယောက်မအားလို့ အခြားတစ်ယောက်ကို escalate လုပ်မယ်ဆိုရင်လည်း လုပ်လို့ ရပါတယ်....နောက်တစ်ခုကကိုယ့် engineer တွေ service တစ်ခုအတွက် အချိန်ဘယ်လောက်ယူ သလဲ ( ဥပမာ...printer installation ဆိုရင် 5-mins) ...တစ်နေ့ အလုပ်ချိန် ၈-နာရီမှာ service ticket ဘယ်နှခုလောက်ပြီးသလဲ....ဘယ်သူက ticket ဘယ်နှခုစာကို process လုပ်သွားနိုင်သလဲ...ဒါတွေကိုသိ နိုင်ပါပြီ...ဒီတော့ employee တစ်ယောက်ချင်းစီရဲ့ KPI ကိုသင်တွက်နိုင်ပြီပေါ့....
နောက်ကောင်းတာတစ်ခုက Engineer တစ်ယောက်က ticket တစ်ခုအတွက်အချိန်ကြာနေတယ်...သူက အဲဒီ case ကို closed မလုပ်နိုင်သေးဘူးဆိုရင် service desk team leader အနေနဲ့ သူ့မှာဘယ်လိုအခက် အခဲတွေဖြစ်နေလို့ ဒီ ticket ကို process မလုပ်နိုင်တာလဲ .ဘာကြောင့်လဲ ??...ဒါတွေကိုကျွန်တော်တို ့က သိနိုင်ပါတယ်.. (user ticket open စလုပ်တဲ့အချိန်ကစပြီး service desk system က time-count & measure စလုပ်နေပြီလေ.........)
နောက်တစ်ခုက audit tracking ပေါ့.....ဒါကတော့ service desk manager လုပ်နိုင်တဲ့အပိုင်းတွေဖြစ် သွားပါပြီ...တကယ်လို့ engineer တစ်ယောက်က လွန်ခဲ့တဲ့ နှစ်လ..သုံးလကလုပ်ခဲ့တဲ့ issue ကိုပြန်ကြည့် ချင်ရင်..အဲဒီ engineer ကိုမေးနေစရာမလို....ticket number--မှတ်မိရင်ပိုကောင်းတယ်...မမှတ်မိလည်း closed-ticket တွေထဲကနေသူဘယ်လို solved လုပ်ခဲ့လဲ....solution issue တွေကို refer လုပ်နိုင်ပါတယ်
လ..အလိုက်သာကမ..နှစ်အလိုက်လည်း audit track လုပ်နိုင်ပါတယ်....ဒါတွေကဘာကောင်းလဲဆိုတော့ တကယ်လို့ သင်က အခြား engineer တစ်ယောက်( ဥပမာ-network engineer )ကို အလုပ်လိုအပ်ချက် အရ..printer installation လုပ်ခိုင်းတော့မယ်..သူ့ field မဟုတ်တဲ့အတွက် သူကဒါကိုလုပ်ဖို့ ရှာရဖွေရ ..စမ်းသပ်ချက်..လုပ်နေရဦးမယ်...သင်က သူ့ ကို closed လုပ်ထားတဲ့ ticket number #91004 ကနေ reference လုပ်ကြည့်လိုက်ပါ...ဆိုပြီးပြောလိုက်ရင်...အဲဒါကိုသူက refer လုပ်ပြီးမြန်မြန်ဆန်ဆန် process လုပ်နိုင်တာပေါ့
My Expirences
အဲဒီလို Service Desk Ticketing System ကိုကျွန်တော်လည်းသုံးဖူးပါတယ်...တကယ်ကောင်းတဲ့ Service Desk Operation ပါ...နောက်တစ်ခု Symantec Co-operation ပါ...ကျွန်တော်က license renewal နဲ့ ပတ်သက်ပြီး ticket ဖွင့်မေးဖူးပါတယ်...သူတို့ ဘက်က ဖုန်းနဲ့ ရော...email နဲ့ ပါ customer စိတ်ကျေနေပ်အောင်ဖြေရှင်းပေးပါတယ်...ပြီးတော့သူတို့ ဖြေရှင်းပေးတဲ့ solution ကို စိတ်ကျေနပ်မှုရှိမရှိဆို တာကိုလည်း ticket close လုပ်တဲ့အချိန်မှာမေးပါတယ်... customer service နဲ့ ပတ်သက်ပြီးတကယ် ကောင်းတဲ့ Framework ပါပဲ....
ကဲ...Technical အရဆိုရင်ကျွန်တော်တို့ က Internet ရတဲ့ Linux Server တစ်လုံးနဲ့ တင် ( ပိုကောင်းချင် ရင်တော့ Linux server နှစ်လုံးကို load-balancing လုပ်ထားပေါ့) ဒီ service desk framework တစ်ခုကို တည်ဆောက်ပြီးပိုမိုထိရောက်တဲ့ Service Desk Operation Flow ကိုတည်ဆောက်နိုင်ပါတယ်....
အားလုံးပဲပညာဗဟုသုတကြွယ်ဝတိုးတက်ကြပါစေ...
လေးစားစွာဖြင့်
Phyo Sithu
B.Sc (Physics)
Diploma in IT
Red Hat - RHCSA
No comments:
Post a Comment