စွမ်းအားထက် စနစ်ကို ယုံကြည်ခြင်း
နမော တဿ ဘဂဝတော အရဟတော သမ္မာသမ္ဗုဒ္ဓဿ။
ဗုဒ္ဓဿ ဒန္တဓာတုယော မဟာသရီရဓာတုယော ဝန္ဒနံ ကရောမိ ၊ ဗုဒ္ဓဿ ဒန္တဓာတုယော ဥဘတော ဟတ္ထေ ဓာရေန္တော ပသန္နစိတ္တော၊သက္ကစ္စံ ပူဇံ ကရောမိ၊ ဂရုကရောန္တော နမာမိ။ ဣမာ ဗုဒ္ဓဿ ဒန္တဓာတုယော သဒ္ဓါ-ပသာဒေန ပူဇေမိ၊ အဓိဋ္ဌာန-ပရမိယာ လဒ္ဓါ၊မယာ ရက္ခိတာ သုပ္ပတိဋ္ဌိတာ။ ဣမာ ဓာတုယော ဣဓ ပတိဋ္ဌိတာ သွာဂတ နာမ ဝိဟာရေ၊ တာသံ ရက္ခဏ-ဂေါပန-ပရိဟာရ-ကရဏံ ၊ မယာ ဘိက္ခု ဓမ္မသာမိ သိရိဒန္တမဟပါလက နာမ သက္ကစ္စံ ပဝတ္တတိ။
ယာ ဒိသာ လောကဓာတူသု ၊ ဗုဒ္ဓါနုဘာဝေန ဇောတန္တိ၊ တာဒိသေန အနုဘာဝေန ဣမာ ဓာတုယော သုပ္ပရိဂ္ဂဟိတာ။ ဗုဒ္ဓဿ ဓမ္မဿ သံဃဿ အနုဘာဝေန၊ မာတာပိတု အာစရိယဂုဏေန စ၊ သဗ္ဗေ သတ္တာ သုခိတာ ဟောန္တု၊ သဗ္ဗေ ဘယာ ဝိမုစ္စန္တု၊ သဗ္ဗေ သောကာ တရန္တု စ။
နမော ဗုဒ္ဓဿ၊ နမော ဓမ္မဿ၊ နမော သံဃဿ၊ နမော မာတာပိတုဿ၊ နမော အာစရိယဿ။
စွယ်တော်မြတ်များကို ထိန်းသိမ်းစောင့်ရှောက်လျက်ရှိသော တပည့်တော် အရှင်ဓမ္မသာမိသည် မြတ်စွာဘုရားအား ရှိခိုးပါ၏။ တရားတော်မြတ်အား ရှိခိုးပါ၏။ သံဃာတော်မြတ်အား ရှိခိုးပါ၏။ မိဘနှစ်ပါးအား ရှိခိုးပါ၏။ ဆရာသမားတို့အား ရှိခိုးပါ၏။
ဒကာ ဒကာမတို့…
ဒီနေ့ ဦးဇင်းတို့ ဆွေးနွေးနာယူကြမယ့်အကြောင်းက Founder တစ်ယောက်၊ Leader တစ်ယောက်၊ လုပ်ငန်းတစ်ခုကို စတင်တည်ဆောက်နေသူတစ်ယောက်အတွက် အလွန်အရေးကြီးတဲ့ မေးခွန်းတစ်ခုပါ။
လုပ်ငန်းတစ်ခုဟာ လူတစ်ယောက်ရဲ့ စွမ်းအားပေါ်မှာ အမြဲတည်နေရမလား။
ဒါမှမဟုတ်—
လူတွေ ပြောင်းလဲသွားလည်း မှန်ကန်တဲ့လုပ်ငန်းစဉ် ဆက်သွားနိုင်တဲ့ စနစ်တစ်ခု တည်ဆောက်သင့်သလား။
အစပိုင်းမှာတော့ လူတစ်ယောက်ရဲ့ စွမ်းအားက အလွန်အရေးကြီးတယ်။
Founder ကိုယ်တိုင် ရှေ့ကပြေးရတယ်။
ကိုယ်တိုင် Customer ရှာရတယ်။
ကိုယ်တိုင် Product ကြည့်ရတယ်။
ကိုယ်တိုင် Accounting ကြည့်ရတယ်။
ကိုယ်တိုင် Marketing လုပ်ရတယ်။
ကိုယ်တိုင် ပစ္စည်းတင်တယ်။
ကိုယ်တိုင် Customer Complaint ဖြေတယ်။
ကိုယ်တိုင် Team ကို သင်တယ်။
ပြဿနာပေါ်လာရင်—
Founder ကိုပဲ ခေါ်တယ်။
ဆုံးဖြတ်ချက်ချမယ်—
Founder ကို မေးတယ်။
Customer အကြီးတစ်ယောက် ဝင်လာတယ်—
Founder ကို ခေါ်တယ်။
Staff နှစ်ယောက် မညီဘူး—
Founder ဆီလာတယ်။
ငွေမကိုက်ဘူး—
Founder ကြည့်တယ်။
ဒီလိုနဲ့ အစပိုင်းမှာ—
“ငါရှိလို့ ဒီလုပ်ငန်းရှိတာ”
ဆိုတဲ့ပုံစံ ဖြစ်နိုင်တယ်။
ဒါ မမှားသေးဘူး။
စတင်ကာလမှာ အဲဒီလိုလိုအပ်နိုင်တယ်။
ဒါပေမယ့် Company ကြီးလာပြီး၊ ဝန်ထမ်းများလာပြီး၊ Customer များလာပြီး၊ Branch များလာပြီး၊ Founder က အရာအားလုံးကို အရင်ပုံစံအတိုင်း ကိုယ်တိုင်ဆက်ထမ်းနေရင်—
အားသာချက်ဟာ အားနည်းချက် ဖြစ်လာနိုင်တယ်။
အစတုန်းက Founder ရဲ့ စွမ်းအားက Company ကို ကယ်တင်တယ်။
နောက်ပိုင်းမှာ Founder ရဲ့ စွမ်းအားကို အရာအားလုံးမှီခိုနေတာက Company ကို ကန့်သတ်လာတယ်။
ကဲ… စဉ်းစားကြည့်။
Founder ဖျားသွားရင် ဘာဖြစ်မလဲ။
တစ်ပတ် ခရီးသွားရင် ဘာဖြစ်မလဲ။
ဖုန်းမကိုင်နိုင်ရင် ဘာဖြစ်မလဲ။
တစ်လလောက် တခြားတာဝန်ကြောင့် မရောက်နိုင်ရင် ဘာဖြစ်မလဲ။
အလုပ်တွေအားလုံး ရပ်သွားမလား။
အဖွဲ့က ဆုံးဖြတ်လို့မရတော့ဘူးလား။
ဘယ်သူဘယ်အလုပ်လုပ်ရမလဲ မသိတော့ဘူးလား။
Customer ဖြေရှင်းပုံ မသိတော့ဘူးလား။
Payment လုပ်လို့မရတော့ဘူးလား။
Quality ကျသွားမလား။
စနစ်တစ်ခုက လူတစ်ယောက် မရှိတာနဲ့ ပြိုသွားတယ်ဆိုရင်—
လူတစ်ယောက် အရမ်းတော်လို့ပဲ မကြည့်နဲ့။
စနစ်အရမ်းအားနည်းနေလို့လည်း ဖြစ်နိုင်တယ်။
ဒီဟာ ဒီနေ့ ဦးဇင်းတို့ အဓိကစဉ်းစားမယ့်အချက်ပဲ။
စွမ်းအားကို မဖျက်ပါနဲ့။
ဒါပေမယ့် စွမ်းအားတစ်ခုတည်းပေါ် မမှီပါနဲ့။
လူတော်လိုတယ်။
ကြိုးစားသူလိုတယ်။
တာဝန်ယူသူလိုတယ်။
Founder ရဲ့ Vision လိုတယ်။
ဒါပေမယ့်—
အဖွဲ့တစ်ခုရဲ့ အနာဂတ်ကို လူတစ်ယောက်ရဲ့ ကိုယ်အား၊ စိတ်အား၊ မှတ်ဉာဏ်၊ ဆုံးဖြတ်ချက်နဲ့ အမြဲချည်ထားရင် ရေရှည်တည်ငြိမ်ဖို့ ခက်တယ်။
ဒီနေရာမှာ မြတ်စွာဘုရားရှင် ဟောကြားထားတဲ့ အလွန်အရေးကြီးတဲ့ ဥပမာတစ်ခုကို ဦးဇင်းတို့ သတိရနိုင်တယ်။
ဒီဃနိကာယ်၊ မဟာပရိနိဗ္ဗာနသုတ်မှာ ဝဇ္ဇီတို့ မဆုတ်ယုတ်နိုင်စေမယ့် အခြေအနေတွေကို ဖော်ပြရာမှာ လူတစ်ယောက် အားအကြီးဆုံးဖြစ်ရမယ်၊ ခေါင်းဆောင်တစ်ယောက် အားလုံးကို ကိုင်တွယ်ရမယ်ဆိုတာ မဟုတ်ဘူး။ မကြာခဏ စည်းဝေးခြင်း၊ ညီညွတ်စွာ စည်းဝေးခြင်း၊ ညီညွတ်စွာ ဆောင်ရွက်ခြင်း၊ အတည်ပြုထားတဲ့ မူဘောင်တွေကို လေးစားလိုက်နာခြင်း၊ အကြီးအကဲများရဲ့ အတွေ့အကြုံကို အလေးထားခြင်းတို့လို အဖွဲ့အစည်းဆိုင်ရာ အခြေအနေတွေကို ဖော်ပြထားတယ်။ ထို့နောက် သံဃာတော်များအတွက်လည်း မကြာခဏစုဝေးခြင်း၊ ညီညွတ်စွာကိစ္စဆောင်ရွက်ခြင်း၊ သတ်မှတ်ထားတဲ့ သင်ကြားစည်းကမ်းများကို ထိန်းသိမ်းခြင်းတို့ကို မဆုတ်ယုတ်ရေးအခြေအနေများအဖြစ် ဆက်လက်ဖော်ပြထားတယ်။
ဒီတရားတော်ကို—
“မြတ်စွာဘုရားက Modern Management System ဟောခဲ့တယ်”
လို့တော့ မပြောရဘူး။
ဒီလိုပြောတာ အလွန်အကျွံဖြစ်သွားမယ်။
ဒါပေမယ့် ဓမ္မထဲက အဓိကအမြင်တစ်ခုကိုတော့ မြင်နိုင်တယ်။
တည်တံ့မှုဟာ လူတစ်ယောက်ရဲ့ စွမ်းအားတစ်ခုတည်းက မလာဘူး။ ကောင်းမွန်တဲ့အခြေအနေတွေ အတူတကွရှိနေခြင်းက လာတယ်။
ဒီအချက် အလွန်နက်တယ်။
ဒကာကြီးတို့ Company မှာလည်း မေးကြည့်။
တစ်ယောက်တော်လို့ အလုပ်ဖြစ်နေတာလား။
ဒါမှမဟုတ် လူတော်မရှိတဲ့နေ့မှာတောင် အဖွဲ့က အနည်းဆုံး လမ်းမပျောက်အောင် စနစ်ရှိသလား။
တစ်ယောက်မှတ်ဉာဏ်ကောင်းလို့ အလုပ်ဖြစ်နေတာလား။
ဒါမှမဟုတ် လုပ်ငန်းစဉ်ကို ရေးထားသလား။
Founder က Customer အားလုံးရဲ့အကြောင်း မှတ်ထားလို့ အလုပ်ဖြစ်နေတာလား။
ဒါမှမဟုတ် Customer Information စနစ်တကျရှိသလား။
Accounting Staff တစ်ယောက်အကုန်သိလို့ ငွေစာရင်းလည်နေတာလား။
ဒါမှမဟုတ် တစ်ယောက်မရှိရင် တခြားသူက အနည်းဆုံး ဖိုင်တွေရှာနိုင်၊ စာရင်းတွေ နားလည်နိုင်အောင် စနစ်ရှိသလား။
Manager တစ်ယောက်အရမ်းတော်လို့ Team အလုပ်ဖြစ်နေတာလား။
ဒါမှမဟုတ် Manager ပြောင်းရင်လည်း အခြေခံစည်းမျဉ်း၊ Role၊ Responsibility၊ Decision Boundary တွေ ဆက်ရှိသလား။
ဒီဟာတွေက—
လူကို မယုံတော့ဘူး ဆိုတာ မဟုတ်ဘူး။
တကယ်တော့ ကောင်းတဲ့စနစ်က လူကို ပိုယုံလို့ တည်ဆောက်တာ။
ဘာကြောင့်လဲ။
လူတစ်ယောက်ကို လုပ်ငန်းအားလုံး မှတ်ခိုင်းထားတာက ယုံကြည်မှုမဟုတ်ဘူး။
ဝန်ပိစေတာ။
လူတစ်ယောက်ကို အမှားမဖြစ်အောင် အရာအားလုံးကို သူ့ခေါင်းထဲပဲ ထည့်ထားရတာက အားပေးတာမဟုတ်ဘူး။
Risk တည်ဆောက်တာ။
ကောင်းတဲ့စနစ်က—
လူတစ်ယောက် မှားနိုင်တယ်ဆိုတာ လက်ခံတယ်။
မေ့နိုင်တယ်ဆိုတာ လက်ခံတယ်။
ပင်ပန်းနိုင်တယ်ဆိုတာ လက်ခံတယ်။
ဖျားနိုင်တယ်ဆိုတာ လက်ခံတယ်။
အလုပ်ပြောင်းနိုင်တယ်ဆိုတာ လက်ခံတယ်။
ဒီလိုလက်ခံပြီး—
“လူကို မစွမ်းနိုင်တဲ့စက်ဖြစ်အောင် မတောင်းဆိုဘဲ၊ လူဖြစ်နေတာကို သိတဲ့စနစ် တည်ဆောက်မယ်”
လို့ စဉ်းစားတာ။
ဒါ သဘောတရားကြီး။
တစ်ခါတလေ Founder တွေပြောတယ်—
“ဒီအလုပ် သူများကို မပေးနိုင်ဘူး၊ ကျွန်တော်ပဲ လုပ်တတ်တယ်။”
မေးရမယ်။
ဒါ ဘယ်လောက်ကြာပြီလဲ။
သုံးလလား။
တစ်နှစ်လား။
ငါးနှစ်လား။
Company စကတည်းက—
“ငါပဲလုပ်တတ်တယ်”
ဆိုပြီး ဆက်လာတာလား။
ဒါဆို နောက်မေးခွန်းက—
“ဘယ်သူ့ကို သင်ပေးဖူးသလဲ”
“ဘယ်သူမှ မလုပ်တတ်ဘူး”
ဆိုပေမယ့်—
လုပ်တတ်အောင် ဘယ်သူ့ကို Training ပေးဖူးသလဲ။
Process ရေးထားသလား။
Checklist ရှိသလား။
Sample ရှိသလား။
Quality Standard ရှိသလား။
Error ဖြစ်ရင် ဘယ်အဆင့်မှာ ပြန်စစ်မလဲ ရှိသလား။
လူတစ်ယောက် အလုပ်မတတ်တာနဲ့—
စနစ်က သင်မပေးနိုင်တာကို ခွဲကြည့်ရမယ်။
အဲဒီတော့ Founder Leadership မှာ မေးခွန်းက—
“ငါဘယ်လောက်တော်လဲ”
တစ်ခုတည်း မဟုတ်တော့ဘူး။
“ငါ့တော်မှုကို အဖွဲ့ရဲ့ စွမ်းရည်အဖြစ် ဘယ်လောက်ပြောင်းပေးနိုင်ပြီလဲ”
ဖြစ်လာတယ်။
ကိုယ်သိတာကို ကိုယ်တစ်ယောက်ထဲ သိနေရင်—
Knowledge ဖြစ်တယ်။
ကိုယ်သိတာကို လုပ်ငန်းစဉ်၊ Training၊ Checklist၊ Principle၊ Culture အဖြစ် အဖွဲ့ထဲ ဖြန့်နိုင်ရင်—
အဖွဲ့ရဲ့ Capacity ဖြစ်လာတယ်။
ဒီနှစ်ခု ကွာတယ်။
အင်္ဂုတ္တရနိကာယ် ၈.၅၅ မှာ အိမ်ရှင်တစ်ယောက်ရဲ့ လက်ရှိဘဝအကျိုးချမ်းသာနဲ့ပတ်သက်ပြီး အားထုတ်တတ်ခြင်းကို ရှင်းပြတဲ့အခါ အလုပ်ကြိုးစားရုံကိုသာ မဆိုဘဲ မိမိအသက်မွေးမှုဆိုင်ရာ လုပ်ငန်းကို ဘယ်လိုဆောင်ရွက်ရမလဲ သိရှိပြီး အလုပ်ကို ပြီးမြောက်အောင် စီမံနိုင်စွမ်းရှိခြင်းကို ထည့်သွင်းဖော်ပြထားတယ်။ ထို့ပြင် ရရှိထားသည့်အရာကို ထိန်းသိမ်းခြင်း၊ မိတ်ဆွေကောင်းရှိခြင်းနဲ့ ဝင်ငွေထွက်ငွေကို အချိုးညီစွာ စီမံခြင်းတို့ကိုလည်း အတူဖော်ပြထားတယ်။
ဒါကြောင့်—
ကြိုးစားမှု + စီမံနိုင်မှု
နှစ်ခုလုံး လိုတယ်။
အားပဲရှိပြီး စီမံမထားရင်—
လူတွေ ပင်ပန်းလာတယ်။
စနစ်ပဲရှိပြီး ဘယ်သူမှ အားမထုတ်ရင်—
စာရွက်ပေါ်က စနစ်ပဲ ဖြစ်သွားတယ်။
နှစ်ခုကို ဆန့်ကျင်ဘက်မလုပ်နဲ့။
ဒီနေ့ခေါင်းစဉ်က “စွမ်းအားထက် စနစ်ကို ယုံကြည်ခြင်း” ဆိုတာ—
“လူ့စွမ်းအား မလိုဘူး”
လို့ မဆိုလိုဘူး။
ဆိုလိုတာက—
တည်တံ့မှုအတွက် ကိုယ်စွမ်းအားတစ်ခုတည်းကို မယုံနဲ့။
စွမ်းအားကို စနစ်ထဲ ထည့်။
အတွေ့အကြုံကို စနစ်ထဲ ထည့်။
အမှားကနေ သင်ယူတာကို စနစ်ထဲ ထည့်။
သိထားတာကို စနစ်ထဲ ထည့်။
ဒါမှ မနက်ဖြန် ကိုယ်မရှိလည်း အကျိုးဆက်က ကျန်နိုင်မယ်။
ကဲ… အလွန်ရိုးရှင်းတဲ့ စိတ်ကူးယဉ်ဥပမာတစ်ခုထားကြည့်။
လုပ်ငန်းရှင်တစ်ယောက်ရှိတယ်။
ဒီဥပမာက သမိုင်းမှာ ဖြစ်ခဲ့တယ်လို့ မဆိုဘူး။
တရားရှင်းလင်းဖို့ စိတ်ကူးယဉ်ထားတဲ့ ဥပမာပါ။
သူ့ဆိုင်မှာ Customer Complaint လာတယ်ဆိုရင် Owner ကိုပဲ ခေါ်ရတယ်။
Customer က—
“ပစ္စည်းမှားသွားတယ်”
ဆိုရင် Staff က—
“ဆရာလာမှ ပြောလို့ရမယ်”
ဆိုတယ်။
Refund မေးတယ်။
“ဆရာလာမှ”
Exchange မေးတယ်။
“ဆရာလာမှ”
Discount ကိစ္စ။
“ဆရာလာမှ”
Delivery Error။
“ဆရာလာမှ”
ဆရာက တစ်ရက်ခရီးသွားရင်—
ပြဿနာတွေ စုနေတယ်။
ပြန်လာတာနဲ့ Owner က အကုန်ဖြေရှင်းတယ်။
Customer တွေကလည်း—
“ဒီဆိုင်မှာ Owner ပြောမှ အလုပ်ဖြစ်တယ်”
လို့ သိလာတယ်။
Owner ကတော့ တစ်ဖက်မှာ ဂုဏ်ယူတယ်။
“ငါမရှိရင် မဖြစ်ဘူး”
ဒါပေမယ့် ဦးဇင်းတို့ ပြန်မေးကြည့်။
ဒါ အောင်မြင်မှုလား။
ဒါမှမဟုတ်—
လုပ်ငန်းဟာ လူတစ်ယောက်ကို အလွန်အကျွံ မှီခိုနေတဲ့ လက္ခဏာလား။
အခု Owner က စနစ်ပြောင်းမယ်ဆိုပါစို့။
Customer Complaint ကို အမျိုးအစားခွဲတယ်။
ဘယ်အခြေအနေမှာ Staff က တိုက်ရိုက်ပြန်လဲပေးနိုင်တယ်။
ဘယ်အခြေအနေမှာ Supervisor ကိုတက်ရမယ်။
ဘယ်ပမာဏအထိ Refund လုပ်နိုင်တယ်။
ဘယ်ပြဿနာကို Owner အထိတက်ရမယ်။
ဘယ်အချက်အလက် မှတ်ရမယ်။
နေ့ကုန်ရင် Report ဘယ်လိုပြန်တင်မယ်။
Customer ကို ဘယ်လိုစကားပြောမယ်။
ဒီလိုရှင်းထားတယ်။
အခု Owner ခရီးသွားတယ်။
Customer လာတယ်။
Staff က စည်းမျဉ်းအတိုင်း ဖြေရှင်းတယ်။
အရေးကြီးတာကို Supervisor တက်တယ်။
ထူးခြားတဲ့ကိစ္စကို Owner ဆီပို့တယ်။
ဒါဆို Owner ရဲ့ တန်ဖိုးကျသွားသလား။
မကျဘူး။
တကယ်တော့ Owner ရဲ့ Leadership တန်ဖိုး မြင့်လာတယ်။
ဘာကြောင့်လဲ။
အရင်က—
သူလုပ်မှ အလုပ်ဖြစ်တယ်။
အခု—
သူတည်ဆောက်ထားလို့ အလုပ်ဖြစ်တယ်။
ဒီနှစ်ခုက အဆင့်မတူဘူး။
Founder တစ်ယောက်အတွက် အလွန်နက်တဲ့ ပြောင်းလဲမှု။
ပထမအဆင့်မှာ—
ကိုယ်လုပ်နိုင်ခြင်း။
နောက်အဆင့်မှာ—
သူများကို လုပ်နိုင်အောင် သင်ပေးခြင်း။
နောက်အဆင့်မှာ—
လူများစွာက မှန်မှန်လုပ်နိုင်တဲ့ စနစ်တည်ဆောက်ခြင်း။
နောက်အဆင့်မှာ—
စနစ်မှားလာရင် ပြန်လည်စစ်ဆေး ပြင်ဆင်နိုင်တဲ့ယဉ်ကျေးမှု တည်ဆောက်ခြင်း။
ဒါတွေဟာ Leadership ရဲ့ တိုးတက်မှုဖြစ်နိုင်တယ်။
ဒီနေရာမှာ ဒီဃနိကာယ် ၃၁ ကိုလည်း သတိရသင့်တယ်။
အလုပ်ရှင်တစ်ယောက်က အလုပ်သမား၊ ဝန်ထမ်းများနဲ့ ဆက်ဆံရာမှာ သူတို့ရဲ့ စွမ်းနိုင်မှုနဲ့ ကိုက်ညီတဲ့ အလုပ်ခွဲဝေပေးခြင်း၊ အစားအသောက်နဲ့ အခကြေးငွေကို စီမံပေးခြင်း၊ ဖျားနာသည့်အခါ ပြုစုခြင်း၊ သင့်လျော်သည့်အရာများ မျှဝေခြင်း၊ အချိန်တန် အားလပ်ခွင့်ပေးခြင်းတို့ကို ဖော်ပြထားတယ်။
ဒီမှာ သတိထားကြည့်။
အလုပ်ခွဲဝေပေးခြင်း ပါတယ်။
လူအားလုံးကို—
“ငါလိုလုပ်”
လို့ တောင်းတာ မဟုတ်ဘူး။
သူ့စွမ်းရည်နဲ့ ကိုက်ညီအောင် တာဝန်ခွဲတယ်။
ဒါဟာ ကောင်းတဲ့စနစ်တစ်ခုရဲ့ အခြေခံလည်း ဖြစ်နိုင်တယ်။
System ဆိုတာ—
Software မဟုတ်ဘူး။
စာရွက်မဟုတ်ဘူး။
Rule Book ကြီးပဲ မဟုတ်ဘူး။
ဘယ်သူက ဘာတာဝန်ယူမလဲဆိုတာ ရှင်းခြင်းလည်း စနစ်။
ဘယ်အခြေအနေမှာ ဘယ်သူဆုံးဖြတ်မလဲဆိုတာ ရှင်းခြင်းလည်း စနစ်။
အမှားဖြစ်ရင် ဘယ်လိုပြန်သင်ယူမလဲဆိုတာ ရှင်းခြင်းလည်း စနစ်။
တာဝန်နဲ့ အာဏာ ကိုက်ညီအောင်ပေးထားခြင်းလည်း စနစ်။
တချို့ Company တွေမှာ တာဝန်ပေးထားတယ်။
ဒါပေမယ့် ဆုံးဖြတ်ခွင့် မပေးဘူး။
Manager ကို—
“ဒီ Department မင်းတာဝန်”
လို့ပြောတယ်။
ဒါပေမယ့် အသေးဆုံးကိစ္စ Founder ဆီပြန်မေးရတယ်။
ဒီဟာက တာဝန်ပေးတာ မပြည့်စုံသေးဘူး။
Accountability ပေးတယ်။
Authority မပေးဘူး။
နောက်ဆုံး—
အမှားဖြစ်ရင် Manager ကိုပြောတယ်။
ဆုံးဖြတ်မယ်ဆို Founder ခွင့်မပြုဘူး။
ဒီစနစ်က လူတွေကို ကြီးလာခွင့်မပေးဘူး။
ဒါကြောင့် System တည်ဆောက်ချင်ရင်—
တာဝန်ပေးရုံ မလုံလောက်ဘူး။ ဆုံးဖြတ်နိုင်တဲ့နယ်နိမိတ်ပါ ရှင်းရမယ်။
ကဲ… ဒီနေရာမှာ မေး။
Founder ဘာကြောင့် မလွှဲနိုင်တာလဲ။
Staff မကောင်းလို့လား။
တစ်ခါတလေ ဟုတ်တယ်။
Skill မလုံလောက်နိုင်တယ်။
Experience မရှိနိုင်တယ်။
Training မရသေးနိုင်တယ်။
ဒါပေမယ့် အမြဲတမ်း Staff ဘက်တစ်ဖက်တည်း မကြည့်နဲ့။
တစ်ခါတလေ Founder ရဲ့ စိတ်ထဲမှာ—
“ငါမပါရင် ငါ့ကို မလိုတော့ဘူး”
ဆိုတဲ့ စိုးရိမ်မှု ရှိတတ်တယ်။
အလုပ်လိုအပ်ခံရခြင်းနဲ့—
ကိုယ့်တန်ဖိုးကို ချိတ်ထားတယ်။
အားလုံးက ကိုယ့်ကိုလာမေးနေမှ—
“ငါအရေးကြီးတယ်”
လို့ခံစားရတယ်။
ဒီလိုဆို—
System တည်ဆောက်ဖို့ စိတ်ထဲက မလိုချင်တော့ဘူး။
ဘာကြောင့်လဲ။
System ကောင်းလာလေ—
အသေးအဖွဲကိစ္စတွေအတွက် ကိုယ့်ကို မလိုတော့လေ။
Ego က အဲဒါကို မကြိုက်နိုင်ဘူး။
ဒါကြောင့် System Building က Technical Skill တင်မဟုတ်ဘူး။
Ego Training လည်း ဖြစ်တယ်။
ကိုယ်မပါဘဲ သူများက ကောင်းကောင်းလုပ်သွားတာကို ဝမ်းသာနိုင်မလား။
ကိုယ်သင်ပေးထားတဲ့ Staff က ကိုယ်ထက်တောင် အပိုင်းတစ်ခုမှာ ကောင်းသွားရင် ဝမ်းသာနိုင်မလား။
“ဒီကိစ္စကို ကျွန်တော်မသိတော့ဘူး၊ သူက ကျွန်တော့်ထက်ပိုသိတယ်”
လို့ ရိုးရိုးသားသား ပြောနိုင်မလား။
ဒီဟာ Leadership ရဲ့ စမ်းသပ်ချက်တစ်ခု။
လူတွေ မတော်အောင် ထိန်းထားပြီး—
ကိုယ်တော်နေတယ်လို့ ခံစားရတာ Leadership မဟုတ်ဘူး။
လူတွေတော်လာအောင်လုပ်ပြီး ကိုယ်မလိုတော့တဲ့အလုပ်တွေ များလာတာကို လက်ခံနိုင်ခြင်း က Leadership ဖြစ်နိုင်တယ်။
အင်္ဂုတ္တရနိကာယ် ၁၁.၂ မှာလည်း အကြောင်းအခြေအနေတစ်ခုက နောက်အကျိုးတစ်ခုကို ပံ့ပိုးသွားတဲ့ ဆက်စပ်မှုတစ်ခုကို တွေ့ရတယ်။ သီလပြည့်စုံခြင်းရှိရင် မနောင်တရခြင်းကို အတင်းဆန္ဒပြုစရာ မလိုဘဲ သဘာဝကျစွာ ဖြစ်လာနိုင်တယ်။ မနောင်တရခြင်းမှ ဝမ်းမြောက်မှု၊ ထိုမှတစ်ဆင့် စိတ်နှလုံးပိုမိုငြိမ်သက်မှုနဲ့ ဆက်လက်တိုးတက်သွားတဲ့ အခြေအနေဆက်စပ်မှုကို ဖော်ပြထားတယ်။
ဒီတရားကို Business Process လို့ မခေါ်ရဘူး။
ဒါဟာ ဓမ္မလေ့ကျင့်မှုဆိုင်ရာ အကြောင်းအခြေအနေဆက်စပ်မှု။
ဒါပေမယ့် စဉ်းစားစရာတစ်ခုရှိတယ်။
အကျိုးကောင်းလိုချင်ရင် အခြေအနေကောင်း တည်ဆောက်ဖို့လိုတယ်။
လူတွေက ရလဒ်ကို တိုက်ရိုက်အမိန့်ပေးချင်တယ်။
“Team က တာဝန်ယူပါစေ”
လို့ပြောတယ်။
ဒါပေမယ့် တာဝန်ယူနိုင်မယ့် Information ပေးထားသလား။
ဆုံးဖြတ်ခွင့်ပေးထားသလား။
အမှားသေးသေး ဖြစ်ရင် သင်ယူခွင့်ပေးသလား။
မေးရင် ဆူလား။
မမေးရင် ဆူလား။
ပြဿနာပြောလာရင်—
“ဘာလို့ပြဿနာလာပြောတာလဲ”
လို့ပြောပြီး နောက်တော့—
“ဘာလို့အရင်မပြောတာလဲ”
လို့ ပြောနေလား။
ဒီလို Environment ထဲမှာ—
“တာဝန်ယူ”
လို့အမိန့်ပေးရုံနဲ့ လူက တာဝန်ယူလာမလား။
ခက်တယ်။
ဒါကြောင့် System Thinking မှာ—
ရလဒ်ကို ကြည့်ရုံနဲ့ မပြီးဘူး။
ရလဒ်ဖြစ်လာစေတဲ့ အခြေအနေတွေကို ကြည့်ရမယ်။
Customer Service မကောင်းဘူး။
Staff ကို ဆူတာတင် မလုပ်နဲ့။
Training ရှိသလား။
Script ရှိသလား။
Authority ရှိသလား။
Response Time ရှင်းသလား။
Complaint Record ရှိသလား။
Common Problem တွေ စုထားသလား။
Manager က Review လုပ်သလား။
ဒီအခြေအနေတွေကို ကြည့်။
Quality ပျက်တယ်။
Worker ကို ပြစ်တင်တာတင် မလုပ်နဲ့။
Raw Material Standard ရှိသလား။
Inspection Point ရှိသလား။
Checklist ရှိသလား။
Measurement Tool ရှိသလား။
Training ရှိသလား။
Production Time လုံလောက်သလား။
Target မတန်တဆ ဖြစ်နေသလား။
ဒါကိုကြည့်။
Sales မကောင်းဘူး။
Salesperson ကို—
“ပိုကြိုးစား”
တစ်ခုပဲ မပြောနဲ့။
Product Position ရှင်းသလား။
Customer ဘယ်သူလဲ သိသလား။
Price မှန်သလား။
Message ရှင်းသလား။
Lead Quality ဘယ်လိုလဲ။
Follow-up Process ရှိသလား။
ဒါတွေ ကြည့်။
ကဲ… ဒကာ ဒကာမတို့။
ဒီနေရာမှာ Systems Thinking ကို Engineering နဲ့ နှိုင်းယှဉ်ပြီး ရိုးရိုးကြည့်နိုင်တယ်။
ဒီဟာ ဓမ္မသက်သေ မဟုတ်ဘူး။
နားလည်ရလွယ်အောင် နှိုင်းယှဉ်တာပဲ။
တံတားတစ်စင်းကို တည်ဆောက်ထားတယ်ဆိုပါစို့။
ကားတစ်စီးဖြတ်တိုင်း Engineer တစ်ယောက်က တံတားအောက်ကနေ လက်နဲ့ ထမ်းထားပေးရမယ်ဆိုရင်—
တံတားက တကယ်အလုပ်ဖြစ်သလား။
မဖြစ်သေးဘူး။
တံတားက သူ့ဖွဲ့စည်းပုံအရ Load ကို ထမ်းနိုင်ရမယ်။
Company လည်း ဒီလို။
Customer တစ်ယောက်ဝင်တိုင်း Founder က လက်နဲ့ ထမ်း။
ဝန်ထမ်းတစ်ယောက်ပြဿနာဖြစ်တိုင်း Founder က လက်နဲ့ထမ်း။
Invoice တစ်ခုထွက်တိုင်း Founder က လက်နဲ့ထမ်း။
Quality တစ်ခါစစ်တိုင်း Founder က လက်နဲ့ထမ်း။
ဒီလိုဆို—
Founder အားကောင်းလို့ တစ်ချိန်တာ ဖြတ်သန်းနိုင်တယ်။
ဒါပေမယ့် Structure က မတည်ဆောက်သေးဘူး။
အလုပ်တစ်ခုကို—
“လူတော်တစ်ယောက်ရှိရင် ဖြစ်တယ်”
ဆိုတာက အဆင့်တစ်ခု။
“လူကောင်းများ၊ စည်းကမ်းကောင်းများ၊ စစ်ဆေးပုံကောင်းများ၊ Information ကောင်းများနဲ့ အပြန်အလှန် ထိန်းထားလို့ ဖြစ်တယ်”
ဆိုတာက နောက်အဆင့်။
မဟာပရိနိဗ္ဗာနသုတ်ထဲက မဆုတ်ယုတ်ရေးအခြေအနေတွေကို ပြန်ကြည့်ရင်လည်း စည်းဝေးမှု၊ ညီညွတ်မှု၊ အတည်ပြုထားတဲ့ စည်းမျဉ်းကို ထိန်းသိမ်းမှု၊ အတွေ့အကြုံရှိသူကို လေးစားနားထောင်မှုတို့လို အချက်တွေကို တွေ့ရတယ်။ လူတစ်ဦး၏ ကာယအား၊ ဩဇာ၊ ပြောဆိုစွမ်းအားတစ်ခုတည်းပေါ် မတည်ထားတာကို သတိပြုနိုင်တယ်။
ဒီမှာ အရေးကြီးတာ—
စနစ်ဆိုတာ လူ့ဆက်ဆံရေးကို အစားထိုးတာ မဟုတ်ဘူး။
တချို့လုပ်ငန်းမှာ System ဆိုပြီး Rule များလွန်းတယ်။
Form အများကြီးဖြည့်ရတယ်။
Approval ငါးဆင့်။
Signature ရှစ်ခု။
အသေးအဖွဲကိစ္စလည်း Procedure ရှည်တယ်။
လူတွေ အလုပ်လုပ်တာထက် Form ဖြည့်တာပိုများတယ်။
ဒါက ကောင်းတဲ့စနစ်မဟုတ်နိုင်ဘူး။
စနစ်ရဲ့ရည်ရွယ်ချက်က—
အလုပ်ကို ရှင်းစေဖို့။
တာဝန်ကို ရှင်းစေဖို့။
အမှားကို ကာကွယ်ဖို့။
သင်ယူနိုင်ဖို့။
လူအများ ပူးပေါင်းလုပ်နိုင်ဖို့။
လူတွေကို စည်းမျဉ်းအောက်မှာ အသက်ရှူမရအောင် ဖိထားဖို့ မဟုတ်ဘူး။
ဒီဟာကို ခွဲကြည့်ရမယ်။
စနစ်ကောင်းရင်—
လူတွေ မေးခွန်းနည်းလာတယ်။
အကြောင်းက ရှင်းလို့။
စနစ်မကောင်းရင်—
စာရွက်များလာပြီး မေးခွန်းပိုများလာတယ်။
စနစ်ကောင်းရင်—
အမှားဖြစ်တာကို သတင်းပို့ရဲတယ်။
စနစ်မကောင်းရင်—
အမှားဖုံးရတာ ပိုလုံခြုံတယ်။
စနစ်ကောင်းရင်—
အခြေအနေထူးခြားရင် Exception လုပ်နိုင်တဲ့နေရာရှိတယ်။
စနစ်မကောင်းရင်—
Rule ကို လူထက် ပိုကြီးထားတယ်။
ဒါကြောင့် စနစ်တည်ဆောက်ရင် ပညာလိုတယ်။
အင်္ဂုတ္တရနိကာယ် ၆.၅၀ မှာ အခြေအနေတစ်ခုမရှိခြင်းက နောက်တစ်ဆင့်ရဲ့ အခြေအနေကို ပျက်စီးစေနိုင်ပုံကို ဆက်စပ်ဖော်ပြထားတယ်။ ဣန္ဒြိယစောင့်စည်းမှု မရှိရင် သီလအတွက်လိုအပ်တဲ့ အခြေအနေတစ်ခု ပျက်တယ်၊ သီလမရှိရင် မှန်ကန်တဲ့ စိတ်တည်ငြိမ်မှုအတွက် အခြေအနေ ပျက်တယ်၊ ဒီလို ဆက်လက်ဖော်ပြထားတယ်။
ဒီအချက်လည်း System Thinking နဲ့ နားလည်ဖို့ အလွန်အသုံးဝင်တယ်။
ရလဒ်အဆုံးကိုပဲ သွားဖိလို့မရဘူး။
အရင်းအမြစ်ကို ကြည့်ရတယ်။
Process ကို ကြည့်ရတယ်။
Condition ကို ကြည့်ရတယ်။
ဥပမာ—
ဝန်ထမ်းတစ်ယောက် မကြာခဏနောက်ကျတယ်။
ချက်ချင်း—
“မကောင်းတဲ့ဝန်ထမ်း”
လို့ပဲ မသတ်မှတ်နဲ့။
တာဝန်ယူမှုအပိုင်းမှာ သူ့ပြဿနာ ဖြစ်နိုင်တယ်။
ဒါပေမယ့် System ဘက်ကလည်း မေး။
Shift Time ရှင်းသလား။
Schedule ကို ဘယ်အချိန်ပေးသလဲ။
Transport အခြေအနေ ဘာလဲ။
Supervisor တစ်ယောက်နဲ့တစ်ယောက် Rule မတူဘူးလား။
Attendance Rule ကို လူတိုင်းတူတူအသုံးချသလား။
တစ်ယောက်ကို ခွင့်လွှတ်ပြီး တစ်ယောက်ကို အပြစ်ပေးနေလား။
ဒီအရာတွေကိုလည်းကြည့်။
System Thinking က လူရဲ့ တာဝန်ယူမှုကို ဖျက်တာမဟုတ်ဘူး။
လူတစ်ယောက်ရဲ့အမှားနဲ့ အခြေအနေစနစ်ရဲ့အမှားကို ခွဲကြည့်တာ။
ဒါ အရေးကြီးတယ်။
တစ်ယောက်မှားတိုင်း လူပြောင်းမယ်။
နောက်တစ်ယောက်လာတယ်။
အဲဒီအမှား ထပ်ဖြစ်တယ်။
နောက်တစ်ယောက်ပြောင်းတယ်။
ထပ်ဖြစ်တယ်။
ဒီအချိန်မှာ—
လူဆိုးရှာနေတာကို ခဏရပ်ပြီး—
System ကို ပြန်ကြည့်ဖို့ အချိန်ရောက်ပြီ။
ကဲ… Founder အများစုမှာ ပြဿနာတစ်ခုရှိတယ်။
အလုပ်ဖြစ်နေချိန် စနစ်မရေးဘူး။
ဘာကြောင့်လဲ။
“အခုကောင်းနေတာပဲ”
ဆိုပြီး။
တကယ်တော့ စနစ်ရေးဖို့ အကောင်းဆုံးအချိန်က—
အရာတွေ အောင်မြင်နေချိန်လည်း ဖြစ်နိုင်တယ်။
အလုပ်ဘယ်လိုဖြစ်သွားတာလဲ။
ဘယ်အဆင့်က အရေးကြီးလဲ။
ဘယ်အမှားကို ဘယ်လိုရှောင်လိုက်တာလဲ။
ဘယ်ဆုံးဖြတ်ချက်က ကောင်းခဲ့လဲ။
ဘယ် Template က အသုံးဝင်လဲ။
ဒါတွေကို မှတ်ထား။
မဟုတ်ရင် လူပြောင်းတာနဲ့ အသိပညာပါ သွားတယ်။
Company ထဲမှာ နှစ်နှစ်လုပ်ထားတဲ့ လူတစ်ယောက်ရှိတယ်။
သူက Process အကုန်သိတယ်။
စာမရေးထားဘူး။
တစ်နေ့ သူအလုပ်ထွက်တယ်။
အသိပညာပါ ထွက်သွားတယ်။
နောက်တစ်ယောက်က အစကနေ ပြန်သင်ရတယ်။
ဒီလို Company မျိုးမှာ—
လူသစ်တိုင်း Process ပြန်တီထွင်ရတယ်။
ဒါ အလွန်ကုန်ကျတယ်။
System ရဲ့ အရေးကြီးဆုံးအပိုင်းတစ်ခုက—
အဖွဲ့ရဲ့ သင်ယူမှု မပျောက်သွားအောင် ထိန်းပေးခြင်း။
Error ဖြစ်တယ်။
ဘယ်သူ့အပြစ်လဲဆိုတာ ရှာပြီးရပ်မနေနဲ့။
“နောက်တစ်ခါ ဒီလိုမဖြစ်အောင် ဘာပြောင်းမလဲ”
မေး။
အဲဒီမေးခွန်းက System Question။
လူတစ်ယောက်ကို အပြစ်ပေးပြီး ပြဿနာကို မပိတ်နဲ့။
အပြစ်ရှိရင် တာဝန်ယူရမယ်။
ဒါပေမယ့်—
အဲဒီလိုအမှား နောက်လူဆီမှာ ထပ်ဖြစ်နိုင်သေးတယ်ဆိုရင် System မပြင်ရသေးဘူး။
ဥပမာ—
Invoice မှားတယ်။
Staff ကို သတိပေးတယ်။
ပြီးပြီလား။
မပြီးသေးဘူး။
ဘာကြောင့်မှားတာလဲ။
Manual Entry အများကြီးလား။
Double Check မရှိလား။
Template မရှင်းလား။
Price List မတူတဲ့ Version နှစ်ခု သုံးနေလား။
Approval မရှင်းလား။
ဒါကို ပြန်စစ်ရမယ်။
တစ်ခါတလေ Error ဖြစ်တာက—
လူမကောင်းလို့ မဟုတ်ဘူး။
ကောင်းတဲ့လူကို မကောင်းတဲ့စနစ်ထဲ ထည့်ထားလို့ ဖြစ်နိုင်တယ်။
ဒီစကားကို သတိထားပြီး သုံးရမယ်။
လူ့တာဝန်ကို ဖျောက်ဖို့ မဟုတ်ဘူး။
ဒါပေမယ့် Leader တစ်ယောက်က—
“သူမှားတယ်”
ဆိုတာနဲ့ ကျေနပ်မနေဖို့။
ဒီနေရာမှာ Right Effort ကိုလည်း ပြန်စဉ်းစားနိုင်တယ်။
သံယုတ္တနိကာယ် ၄၅.၈ မှာ သမ္မာဝါယာမကို မဖြစ်သေးတဲ့ အကုသိုလ်မဖြစ်လာအောင် အားထုတ်ခြင်း၊ ဖြစ်ပြီးသား အကုသိုလ်ကို ပယ်ခြင်း၊ မဖြစ်သေးတဲ့ ကုသိုလ်ဖြစ်လာအောင် အားထုတ်ခြင်း၊ ဖြစ်ပြီးသားကောင်းမှု ဆက်တည်ပြီး တိုးပွားအောင် အားထုတ်ခြင်းအဖြစ် ဖော်ပြထားတယ်။
ဒီသဘောကို Business Formula လို့ မခေါ်ရဘူး။
ဒါပေမယ့် အဖွဲ့အစည်းဘဝကို ပြန်ကြည့်တဲ့ မှန်တစ်ချပ်အဖြစ် အသုံးချနိုင်တယ်။
ပြဿနာမဖြစ်ခင် ကာကွယ်တဲ့စနစ် ရှိသလား။
ဒါ ပထမ။
ဖြစ်ပြီးသားပြဿနာကို ဖယ်ရှားပြင်ဆင်နိုင်သလား။
ဒါ ဒုတိယ။
ကောင်းတဲ့ Practice အသစ် ဖြစ်လာအောင် လေ့ကျင့်ပေးသလား။
ဒါ တတိယ။
ကောင်းပြီးသား Practice ကို လူပြောင်းလည်း မပျောက်အောင် ထိန်းထားသလား။
ဒါ စတုတ္ထ။
ဒီလိုချိတ်ကြည့်ရင်—
System Building ဟာ—
Rule ရေးတာတင် မဟုတ်ဘူး။
မကောင်းတာကို ကြိုကာကွယ်ခြင်း။
ဖြစ်ပြီးသားအမှားကို ပြန်သင်ယူခြင်း။
ကောင်းတာအသစ် တည်ဆောက်ခြင်း။
ကောင်းပြီးသားကို ရေရှည်ထိန်းခြင်း။
ဒီလေးချက်ပါ။
တချို့ Founder က Error Prevention မလုပ်ဘူး။
Error ဖြစ်မှ Hero လို ဝင်ကယ်တယ်။
မနက် Supplier Problem။
Founder ဖြေရှင်း။
နေ့လယ် Customer ပြဿနာ။
Founder ဖြေရှင်း။
ညနေ Staff ပြဿနာ။
Founder ဖြေရှင်း။
ညမှာ Payment Error။
Founder ဖြေရှင်း။
နေ့ကုန်တော့—
“ငါဒီ Company အတွက် အရမ်းအရေးကြီးတယ်”
ဆိုပြီး ခံစားရတယ်။
ဒါပေမယ့် မနက်ဖြန်—
တူတဲ့ပြဿနာ ပြန်လာတယ်။
နောက်နေ့—
ထပ်လာတယ်။
ဒီမှာ မေးရမှာ—
ပြဿနာဖြေရှင်းတာကောင်းပေမယ့် ပြဿနာအမြဲပြန်ဖြစ်နေအောင် ဘာကြောင့်ထားသလဲ။
Firefighter ကောင်းဖြစ်တာနဲ့—
Fire Prevention ကောင်းဖြစ်တာ မတူဘူး။
မီးလောင်ရင် ငြှိမ်းရမယ်။
ဒါပေမယ့် နေ့တိုင်းတူတဲ့နေရာ မီးလောင်ရင်—
ဘာကြောင့်လောင်တာလဲ စစ်ရမယ်။
အဲဒီလို မစစ်ဘဲ—
မီးလောင်တိုင်း ကိုယ်အရမ်းကောင်းကောင်း ငြှိမ်းနိုင်တာကို ဂုဏ်ယူနေရင်—
စွမ်းအားကို စနစ်ထက် ပိုယုံနေတာ။
ဒီလိုလုပ်ငန်းမှာ Hero Culture ဖြစ်လာတတ်တယ်။
ညလုံးပေါက် အလုပ်လုပ်သူကိုပဲ Hero လို့မြင်တယ်။
အရေးပေါ်ကိစ္စတိုင်း ဝင်ကယ်သူကိုပဲ Hero လို့မြင်တယ်။
ဒါပေမယ့် အရေးပေါ် မဖြစ်အောင် Process ပြင်ထားသူကို မမြင်ဘူး။
စာရင်းရှင်းအောင် လုပ်ထားသူကို မမြင်ဘူး။
Customer ပြဿနာမတက်အောင် Training လုပ်ထားသူကို မမြင်ဘူး။
ဘယ်သူမှ မချီးကျူးဘူး။
ဘာကြောင့်လဲ။
ပြဿနာမဖြစ်တော့လို့။
ကဲ… တကယ်တော့ အဲဒီလူကလည်း Hero ဖြစ်နိုင်တယ်။
ပြဿနာကို ရှင်းသူတင်မဟုတ်ဘဲ ပြဿနာမဖြစ်အောင် အကြောင်းတရားပြင်သူကိုလည်း တန်ဖိုးထားရမယ်။
ဒါမှ Culture ပြောင်းမယ်။
စွမ်းအားပြ Culture ကနေ—
စနစ်တည်ဆောက် Culture သို့။
Founder တစ်ယောက်က—
“အလုပ်များတာကို ပြဖို့”
မလိုတော့ဘူး။
Team က—
“ကိုယ်မရှိရင် မဖြစ်ဘူး”
လို့ပြိုင်တာ မလိုတော့ဘူး။
အစား—
“ကျွန်တော်မရှိရင်တောင် ဒီအလုပ်ဆက်ဖြစ်အောင် ဘယ်လိုထားခဲ့မလဲ”
စဉ်းစားလာတယ်။
ဒါက အဖွဲ့အတွက် အလွန်တန်ဖိုးကြီးတယ်။
ကဲ… ဒီနေရာမှာ Documentation အကြောင်းပြောရမယ်။
တချို့ Company က—
“အားလုံးရေးထားမယ်”
ဆိုပြီး စာရွက်ထူထူကြီးတွေ ဖန်တီးတယ်။
ဘယ်သူမှ မဖတ်ဘူး။
အဲဒါလည်း System မဖြစ်သေးဘူး။
System တစ်ခုက အသုံးပြုနိုင်ရမယ်။
အလွန်ရိုးရှင်းတဲ့အလုပ်ဆိုရင်—
Checklist ကလုံလောက်နိုင်တယ်။
ရှုပ်တဲ့အလုပ်ဆိုရင်—
Procedure လိုနိုင်တယ်။
Decision လုပ်ရမယ်ဆိုရင်—
Decision Rule လိုနိုင်တယ်။
Training လိုရင်—
Video၊ Sample၊ Practice Session လိုနိုင်တယ်။
အရေးကြီးတာ—
စာရွက်ရှိတာ မဟုတ်ဘူး။ မှန်မှန်လိုက်နာနိုင်တဲ့ နားလည်မှုရှိတာ။
Rule ရေးပြီး ဘယ်သူမှ မသိရင်—
System မဟုတ်ဘူး။
Training ပေးပြီး လက်တွေ့မစစ်ရင်—
System မပြည့်စုံဘူး။
Process ရှိပြီး Leader ကိုယ်တိုင် မလိုက်နာရင်—
System ပျက်တယ်။
Founder က—
“အရာအားလုံး Process အတိုင်းလုပ်”
ဆိုတယ်။
ဒါပေမယ့် သူ့မိတ်ဆွေ Customer လာရင် Rule ကျော်တယ်။
သူ့လူဆို Rule တစ်မျိုး။
တခြားသူဆို Rule တစ်မျိုး။
ဒီလိုဆို—
Staff က ဘာသင်ယူမလဲ။
စာရွက်ထဲက Rule ကို မယုံတော့ဘူး။
Founder ရဲ့ Mood ကိုပဲ စောင့်ကြည့်လာမယ်။
ဒီအခြေအနေမှာ System မရှိတော့ဘူး။
Personality Rule ဖြစ်လာတယ်။
ဒါကြောင့် စနစ်ကို ယုံကြည်ချင်ရင်—
Leader ကိုယ်တိုင် စနစ်ကို လေးစားရမယ်။
တရားမမျှတတဲ့ Rule ဖြစ်ရင် ပြင်။
မလိုတော့ရင် ပြင်။
ဒါပေမယ့် Rule ရှိနေချိန်—
လူပေါ်မူတည်ပြီး တစ်မျိုးတစ်ဖုံ မလုပ်နဲ့။
ဒီဃနိကာယ် ၁၆ မှာ ဝဇ္ဇီတို့နဲ့ သံဃာတော်များအတွက် မဆုတ်ယုတ်ရေးအခြေအနေများ ဖော်ပြရာမှာ အတည်ပြုထားတဲ့ မူဘောင်တွေကို မလွယ်လွယ်ဖျက်ဆီးဘဲ လိုက်နာဆောင်ရွက်မှုကို အရေးထားတဲ့အချက်ကို ဒီနေရာမှာ ပြန်သတိရနိုင်တယ်။
ဒါဟာ Rule မပြောင်းရဘူးဆိုပြီး Business ထဲ တိုက်ရိုက်ကူးယူဖို့ မဟုတ်ဘူး။
လုပ်ငန်းစည်းမျဉ်းက Market အလိုက် ပြောင်းဖို့လိုတယ်။
ဥပဒေအလိုက် ပြောင်းဖို့လိုတယ်။
Technology အလိုက် ပြောင်းဖို့လိုတယ်။
ဒါပေမယ့် သင်ခန်းစာတစ်ခု ရတယ်။
လူတိုင်းစိတ်ကြိုက် Rule ပြောင်းနေတဲ့အဖွဲ့ဟာ တည်ငြိမ်ဖို့ခက်တယ်။
Change လုပ်ရင်—
ဘာကြောင့်ပြောင်းတယ်။
ဘယ်နေ့ကစ။
ဘယ် Version။
ဘယ်သူသိရမယ်။
Old Rule ဘာဖြစ်မယ်။
ရှင်းရမယ်။
မဟုတ်ရင်—
Manager တစ်ယောက်ပြောတာ တစ်မျိုး။
Founder ပြောတာ တစ်မျိုး။
စာရွက်ထဲက တစ်မျိုး။
ဝန်ထမ်းဟောင်းသိတာ တစ်မျိုး။
ဝန်ထမ်းသစ်သိတာ တစ်မျိုး။
ဒီဟာ Chaos ပဲ။
အလုပ်လုပ်သူတွေ မကောင်းလို့ မဟုတ်ဘူး။
System က မရှင်းလို့။
ဒကာ ဒကာမတို့…
တစ်ခါတလေ System တည်ဆောက်ဖို့ Founder က ဘာကိုလွှတ်ရမလဲဆိုတော့—
Perfect ဖြစ်ရမယ်ဆိုတဲ့စိတ် ကိုလွှတ်ရမယ်။
“သူများလုပ်ရင် ငါလုပ်သလောက် ကောင်းမှာမဟုတ်ဘူး”
ဟုတ်နိုင်တယ်။
အစပိုင်းမှာ အများအားဖြင့် ဟုတ်နိုင်တယ်။
ကိုယ်ဆယ်နှစ်လုပ်လာတာကို—
လူသစ်တစ်ယောက် တစ်လနဲ့တူမလား။
မတူဘူး။
ဒါပေမယ့်—
သူမကျွမ်းကျင်သေးလို့ အမြဲကိုယ်ပြန်ယူနေရင်—
သူဘယ်တော့ကျွမ်းကျင်မလဲ။
Training ဆိုတာ အချိန်ယူတယ်။
System တည်ဆောက်တာလည်း အစမှာနှေးတယ်။
ကိုယ်တိုင်လုပ်တာက ဒီနေ့မြန်တယ်။
သင်ပေးတာက ဒီနေ့နှေးတယ်။
ဒါပေမယ့်—
သင်ပေးတာက မနက်ဖြန်ရဲ့ စွမ်းအားကို ဖန်တီးတယ်။
ဒီမှာ Short-term Efficiency နဲ့ Long-term Capacity ကွာတယ်။
ကဲ… Founder တစ်ယောက်မှာ စိတ်ရှည်ဖို့လိုတယ်။
အမှားသေးသေးကို ခွင့်ပြုနိုင်ရမယ်။
အမှားကြီးဖြစ်စေမယ့် Risk ကိုတော့ Guardrail ထားရမယ်။
ဒီဟာ အရေးကြီးတယ်။
“အမှားလုပ်လို့ရတယ်”
ဆိုပြီး အရာအားလုံး လွှတ်ထားတာမဟုတ်ဘူး။
Bank Account အကုန် Access ပေးလိုက်တာမျိုး မဟုတ်ဘူး။
Safety Issue ကို လက်တွေ့စမ်းခိုင်းတာမျိုး မဟုတ်ဘူး။
Risk အလိုက် Boundary ခွဲ။
အသေးစားအမှားကနေ သင်ယူခွင့်ရှိ။
ကြီးမားတဲ့အန္တရာယ်မှာ Control ရှိ။
ဒါကလည်း စနစ်။
လူကိုယုံကြည်တာနဲ့—
အရာအားလုံး Blind Trust ပေးတာ မတူဘူး။
ယုံကြည်မှု + စစ်ဆေးနိုင်မှု နှစ်ခုအတူရှိနိုင်တယ်။
အမှန်တကယ် ကောင်းတဲ့ Team မှာ—
Trust ရှိတယ်။
Transparency ရှိတယ်။
Check ရှိတယ်။
Feedback ရှိတယ်။
Correction ရှိတယ်။
အင်္ဂုတ္တရနိကာယ် ၁၀.၃၈ မှာ သံဃာညီညွတ်မှုကို ဖော်ပြရာမှာ တရားဟာ တရားဖြစ်ကြောင်း၊ မတရားဟာ မတရားဖြစ်ကြောင်း၊ သတ်မှတ်ထားတာကို သတ်မှတ်ထားတဲ့အတိုင်း မှန်မှန်ကန်ကန် ခွဲခြားဖော်ပြပြီး ကွဲပြားမှုမဖြစ်စေခြင်းနဲ့ ဆက်စပ်ရှင်းပြထားတယ်။
ဒီအချက်မှာလည်း တစ်ခု သတိရ။
Harmony ဆိုတာ—
အားလုံးက Yes လို့ပြောနေတာ မဟုတ်ဘူး။
Founder ပြောတိုင်း လက်ခံနေတာ မဟုတ်ဘူး။
အမှားမြင်ရင် မပြောရဲတာ Harmony မဟုတ်ဘူး။
အမှန်ကို အမှန်အတိုင်း ပြောနိုင်ပြီး မကွဲကွာအောင် ဆောင်ရွက်နိုင်ခြင်း က ပိုနက်တဲ့ညီညွတ်မှု။
System တစ်ခုက Feedback ကို ပိတ်ထားရင်—
ကြာလာရင် ပျက်တယ်။
Founder ကို မပြောရဲဘူး။
Manager ကို မပြောရဲဘူး။
“ပြဿနာပြောရင် ကိုယ်ပဲအပြစ်တင်ခံရမယ်”
လို့ Staff က သင်ယူသွားတယ်။
အဲဒီနောက်—
Dashboard က အစိမ်းပြတယ်။
Meeting မှာ အားလုံးအဆင်ပြေတယ်။
Report မှာ Problem မရှိဘူး။
ဒါပေမယ့် အောက်မှာ ပြဿနာကြီးလာတယ်။
ဒါကြောင့် System ကောင်းတစ်ခုမှာ—
မကောင်းတဲ့သတင်း မြန်မြန်တက်လာနိုင်ဖို့လိုတယ်။
ပြဿနာတင်ပြသူကို—
“ပြဿနာဖန်တီးသူ”
မမြင်နဲ့။
တကယ်ပြဿနာရှိရင် သိအောင်ပြောသူက—
System ကို ကူညီနေတာ ဖြစ်နိုင်တယ်။
ဒါပေမယ့် Gossip နဲ့ Feedback ကိုလည်း ခွဲရမယ်။
Feedback မှာ—
ဖြစ်ရပ်ရှိတယ်။
Evidence ရှိတယ်။
အကျိုးဆက်ရှိတယ်။
ပြင်ဆင်ဖို့ရည်ရွယ်ချက်ရှိတယ်။
Gossip မှာ—
လူကိုသာ ထိခိုက်စေချင်တာ ပါနိုင်တယ်။
ဒါကြောင့် Right Speech လိုတယ်။
တရားတော်တွေမှာ မမှန်စကား၊ ကွဲပြားစေတဲ့စကား၊ ကြမ်းတမ်းစကား၊ အကျိုးမဲ့စကားကို ပယ်ဖို့နဲ့ ညီညွတ်မှုကို ထောက်ပံ့တဲ့၊ အချိန်တန်၊ မှန်ကန်ပြီး အကျိုးရှိတဲ့ စကားပြောမှုကို အလေးထားထားတယ်။
Team System တစ်ခုမှာ Communication Rule မရှိရင်—
စနစ်မပြည့်စုံဘူး။
တချို့နေရာမှာ Information က Founder ဆီပဲ ရှိတယ်။
တချို့နေရာမှာ Manager ဆီတင် ရှိတယ်။
Staff မသိဘူး။
Staff ကိုတော့—
“ဘာလို့မသိတာလဲ”
လို့ပြောတယ်။
မသိတာက သူ့အပြစ်လား။
Information Flow မရှိတာလား။
စစ်ကြည့်။
Meeting တစ်ခုပြီးရင် Decision ဘယ်မှာရေးလဲ။
ဘယ်သူဘာလုပ်မလဲ သိလား။
Deadline သိလား။
နောက်တစ်ခါ ပြန်စစ်မယ့်အချိန် သိလား။
မဟုတ်ရင်—
Meeting က စကားပြောပွဲပဲ ဖြစ်သွားတယ်။
System တည်ဆောက်ချင်ရင်—
ဆုံးဖြတ်ချက်ကို ရှင်းအောင်လုပ်။
Owner ကို ရှင်းအောင်လုပ်။
Deadline ကို ရှင်းအောင်လုပ်။
Check Point ကို ရှင်းအောင်လုပ်။
ဒါလောက်တောင် အဖွဲ့ကို အများကြီးပြောင်းနိုင်တယ်။
ကဲ… နောက်ထပ် စိတ်ကူးယဉ်ဥပမာတစ်ခု။
လုပ်ငန်းနှစ်ခုရှိတယ်လို့ ထား။
လုပ်ငန်း A မှာ Founder အရမ်းတော်တယ်။
အရာအားလုံး သူမှတ်ထားတယ်။
Customer အားလုံးသူသိတယ်။
Price အားလုံးသူသိတယ်။
Staff အားလုံး ဘာလုပ်နေလဲ သူသိတယ်။
သူရှိရင်—
အလုပ်အရမ်းမြန်တယ်။
ဒါပေမယ့် သူမရှိရင်—
အလုပ်နှေးတယ်။
လူတိုင်းစောင့်ရတယ်။
လုပ်ငန်း B မှာ Founder လည်းကောင်းတယ်။
ဒါပေမယ့် သူက—
Price Policy ရေးထားတယ်။
Customer Record ရှိတယ်။
Complaint Process ရှိတယ်။
Manager Authority ရှင်းတယ်။
Daily Report ရှိတယ်။
Emergency Rule ရှိတယ်။
Training ရှိတယ်။
သူမရှိရင်—
အဖွဲ့က အရာအားလုံး Perfect မဖြစ်ဘူး။
တချို့ကိစ္စနောက်ကျနိုင်တယ်။
တချို့ကိစ္စ သူပြန်လာမှ လိုနိုင်တယ်။
ဒါပေမယ့် အခြေခံစီးဆင်းမှု ဆက်တယ်။
မေး—
ဘယ်လုပ်ငန်းက ရေရှည်ပိုတည်ငြိမ်နိုင်မလဲ။
အဖြေက အခြေအနေများစွာပေါ်မူတည်တယ်။
ဒါပေမယ့် တစ်ခုတော့ မြင်နိုင်တယ်။
တည်တံ့မှုမှာ လူတော်နဲ့အတူ လုပ်ငန်းစဉ်လည်းလိုတယ်။
ဒီဟာ Founder Succession မှာ ပိုထင်ရှားတယ်။
Founder က အမြဲရှိမလား။
မရှိဘူး။
လူတိုင်း အနိစ္စပဲ။
ကိုယ်ခန္ဓာ ပြောင်းတယ်။
အရွယ်ရတယ်။
ကျန်းမာရေးပြောင်းတယ်။
အခန်းကဏ္ဍပြောင်းတယ်။
တစ်နေ့မှာ တာဝန်လွှဲရမယ်။
ဒီအမှန်ကို မကြိုက်လို့ မဖြစ်ဘူး။
လုပ်ငန်းကို—
“ငါရှိသရွေ့ကောင်းမယ်”
ဆိုတဲ့ပုံစံတည်ဆောက်မလား။
ဒါမှမဟုတ်—
“ငါရှိတုန်း မှန်ကန်တဲ့အရာတွေ တည်ဆောက်ထားမယ်၊ ငါမရှိတဲ့နေ့မှာလည်း အကောင်းဘက်ကို ဆက်သွားနိုင်အောင်လုပ်မယ်”
ဆိုတဲ့ပုံစံ တည်ဆောက်မလား။
ဒီမေးခွန်းက Business ကိုကျော်သွားတယ်။
ဘဝအထိ ရောက်သွားတယ်။
မိဘတွေလည်း ဒီလိုပဲ။
ကလေးကို—
အရာအားလုံး ကိုယ်လုပ်ပေးမယ်ဆိုရင်—
ကလေးက ဘယ်တော့လုပ်တတ်မလဲ။
အခက်အခဲတိုင်း ကိုယ်ဝင်ကယ်မယ်ဆိုရင်—
ဘယ်တော့ ဆုံးဖြတ်တတ်မလဲ။
ဆရာတစ်ယောက်လည်း ဒီလိုပဲ။
တပည့်က မသိတိုင်း ကိုယ်ဖြေပေးနေရင်—
တပည့်က ဘယ်တော့ စဉ်းစားတတ်မလဲ။
ကောင်းတဲ့ကူညီမှုဆိုတာ—
အမြဲတမ်း ကိုယ်လုပ်ပေးတာမဟုတ်ဘူး။
သူလုပ်နိုင်အောင် ဖြစ်စေခြင်း။
ဒါ System ရဲ့မေတ္တာပဲ။
ဝန်ထမ်းကို စနစ်ပေးတာ—
Control လုပ်ချင်လို့ပဲ မဟုတ်ဘူး။
သူ့အလုပ်ကို ရှင်းစေဖို့။
မလိုအပ်တဲ့စိတ်ဖိစီးမှု လျော့စေဖို့။
တကယ်အရေးကြီးတာကို သိစေဖို့။
ကိုယ်မေးစရာ မလိုအောင် ဆုံးဖြတ်နိုင်စေဖို့။
Error ဖြစ်ရင် မဖုံးဘဲ ပြင်နိုင်စေဖို့။
ဒါတွေလည်း ကရုဏာနဲ့ဆိုင်တယ်။
System တစ်ခု တကယ်ကောင်းလားဆိုတာ ဘယ်လိုသိမလဲ။
စာရွက်ထူတာနဲ့ မသိရဘူး။
Software ဈေးကြီးတာနဲ့ မသိရဘူး။
Dashboard လှတာနဲ့ မသိရဘူး။
မေးရမယ်—
လူတွေ ပိုရှင်းသလား။
တာဝန် ပိုရှင်းသလား။
ဆုံးဖြတ်ချက် ပိုမှန်လာသလား။
Error ပြန်ဖြစ်မှု လျော့သလား။
Customer အတွေ့အကြုံ တည်ငြိမ်သလား။
Staff အသစ်သင်ဖို့ ပိုလွယ်လာသလား။
Founder မပါလည်း အခြေခံအလုပ် ဆက်သလား။
Transparency ပိုကောင်းသလား။
မတရားမှုလျော့သလား။
အဲဒီအကျိုးကိုကြည့်။
System ရဲ့ ရည်ရွယ်ချက်က System ရှိဖို့မဟုတ်ဘူး။
ကောင်းတဲ့အကျိုးကို မှန်မှန်ဖြစ်စေဖို့။
တချို့အဖွဲ့မှာ Rule တွေ အရမ်းများတယ်။
ဒါပေမယ့် Ethics မရှိဘူး။
Process ရှိတယ်။
ဒါပေမယ့် အမှန်မပြောဘူး။
KPI ရှိတယ်။
ဒါပေမယ့် Number ကောင်းဖို့ Data ကို လှည့်တယ်။
Audit ရှိတယ်။
ဒါပေမယ့် စစ်မယ့်နေ့မှ ပြင်တယ်။
အဲဒီ System က ဘာအကျိုးရှိမလဲ။
ဒါကြောင့်—
စနစ်က သီလကို အစားမထိုးနိုင်ဘူး။
ကောင်းတဲ့လူ + မကောင်းတဲ့စနစ် = ပင်ပန်းတယ်။
မကောင်းတဲ့လူ + ကောင်းတဲ့စနစ် = စနစ်ကို ကျော်ဖို့ ကြိုးစားနိုင်တယ်။
ဒါကြောင့်—
ကောင်းတဲ့လူလည်း တည်ဆောက်ရမယ်။
ကောင်းတဲ့စနစ်လည်း တည်ဆောက်ရမယ်။
နှစ်ခုလုံး။
ဒီမှာ ဦးဇင်းတို့ တစ်ခုသတိထား။
“System ကို ယုံကြည်”
ဆိုတာ—
“လူကို မယုံနဲ့”
လို့မဆိုလိုဘူး။
မဟာပရိနိဗ္ဗာနသုတ်မှာ မဆုတ်ယုတ်ရေးအခြေအနေများကို ဖော်ပြရာမှာ ညီညွတ်စွာ စည်းဝေးခြင်း၊ အကြီးအကဲတို့ကို လေးစားနားထောင်ခြင်း၊ သတ်မှတ်ထားတဲ့ စည်းမျဉ်းကို ထိန်းသိမ်းခြင်းတို့ အတူတူပါဝင်တယ်။ လူ၊ ဆက်ဆံရေးနဲ့ မူဘောင်ကို ခွဲမထားဘူး။
ဒါကြောင့် စနစ်တစ်ခုရဲ့ နှလုံးသားမှာ Trust ရှိရမယ်။
တစ်ယောက်ကို တစ်ယောက် မယုံရင်—
Rule ပိုရေးရတယ်။
Camera ပိုတပ်ရတယ်။
Approval ပိုထည့်ရတယ်။
Password ပိုထားရတယ်။
ဒါပေမယ့် လူတွေက System ကို ကျော်ဖို့ နည်းလမ်းရှာနိုင်တယ်။
စနစ်က Trust ကို ကူညီရမယ်။
Trust က စနစ်ကို ကူညီရမယ်။
တစ်ခုတည်းနဲ့ မပြီးဘူး။
ကဲ… ဒီနေ့ကစပြီး Founder တစ်ယောက် လက်တွေ့ဘာလုပ်နိုင်မလဲ။
ပထမဆုံး—
ကိုယ့်လုပ်ငန်းမှာ ကိုယ်မရှိရင် ရပ်သွားမယ့်အရာတွေ စာရင်းရေး။
မရှက်နဲ့။
ကြည့်။
Payment?
Customer Complaint?
Sales Discount?
Hiring?
Purchasing?
Content Approval?
Quality Check?
Banking?
Supplier?
Decision?
ဘယ်ဟာ ကိုယ့်ဆီမှာ ပိတ်နေသလဲ။
အကုန်ပြောင်းမယ်ဆိုပြီး အလျင်မလိုနဲ့။
တစ်ခုရွေး။
ထပ်မေး—
ဘာကြောင့် ကိုယ့်ဆီပဲလာရတာလဲ။
Skill မရှိလို့လား။
Information မရှိလို့လား။
Authority မရှိလို့လား။
Trust မရှိလို့လား။
Process မရှိလို့လား။
ကိုယ်မလွှတ်ချင်လို့လား။
Risk ကြီးလို့လား။
အကြောင်းကို သိ။
ပြီးတော့—
အဲဒီအလုပ်ကို လူတစ်ယောက် သင်ပေး။
Process ရေး။
Decision Boundary ရှင်း။
Trial Run လုပ်။
Review လုပ်။
အမှားပြင်။
ပြန်လွှဲ။
တစ်နေ့တည်း မလုပ်နဲ့။
Training Cycle အနေနဲ့လုပ်။
ဒုတိယ—
Repeated Problem List လုပ်။
ပြီးခဲ့တဲ့တစ်လမှာ နှစ်ခါ၊ သုံးခါ၊ လေးခါ ထပ်ဖြစ်တဲ့ပြဿနာတွေ ဘာလဲ။
အဲဒီပြဿနာတွေက System Repair အတွက် အကောင်းဆုံး clue တွေ။
နေ့တိုင်း ထပ်ဖြစ်နေတဲ့ Error က—
“လူတွေ ဂရုမစိုက်ဘူး”
လို့တင်မပြောနဲ့။
ဘယ်အခြေအနေက ဒီ Error ကို ဖိတ်ခေါ်နေလဲ ကြည့်။
တတိယ—
တစ်ယောက်ပဲသိတဲ့အရာ ရှာ။
တစ်ယောက်ပဲ Password သိတယ်။
တစ်ယောက်ပဲ Supplier သိတယ်။
တစ်ယောက်ပဲ Customer History သိတယ်။
တစ်ယောက်ပဲ File Location သိတယ်။
တစ်ယောက်ပဲ Machine ပြင်တတ်တယ်။
ဒီလိုဆို Risk ရှိတယ်။
Cross-training လုပ်။
Knowledge မျှဝေ။
ဒါပေမယ့် Security လိုအပ်တဲ့နေရာမှာ Access Control ကို လျော့မပစ်နဲ့။
စနစ်တည်ဆောက်တယ်ဆိုတာ လုံခြုံရေးဖျက်တာမဟုတ်ဘူး။
စတုတ္ထ—
Meeting ကို စနစ်ပြင်တဲ့နေရာဖြစ်စေ။
လူကိုဆူတဲ့နေရာတင် မဖြစ်စေနဲ့။
မေး—
ဘာဖြစ်ခဲ့လဲ။
ဘာကြောင့်ဖြစ်လဲ။
ဘယ်အဆင့်မှာ သိနိုင်ခဲ့လဲ။
နောက်တစ်ခါ မဖြစ်အောင် ဘာပြောင်းမလဲ။
ဘယ်သူတာဝန်ယူမလဲ။
ဘယ်နေ့ ပြန်စစ်မလဲ။
ဒီလိုမေး။
ပဉ္စမ—
Founder ကိုယ်တိုင် Rule အတိုင်း လိုက်။
ကိုယ်ပဲ System ကို ချိုးနေရင်—
ဘယ်သူမှ System ကို မယုံတော့ဘူး။
အရေးပေါ်ကိစ္စဆို Exception လုပ်။
ဒါပေမယ့်—
Exception ကို Normal မလုပ်နဲ့။
ခြောက်ခုမြောက်—
System ကို မကြာခဏ ပြန်စစ်။
မဟာပရိနိဗ္ဗာနသုတ်မှာ “မကြာခဏ စည်းဝေး” ဆိုတဲ့အချက်လည်း အရေးကြီးတယ်။
လုပ်ငန်းမှာလည်း စနစ်တစ်ခု တည်ဆောက်ပြီး ပစ်ထားလို့မရဘူး။
လူပြောင်းတယ်။
အခြေအနေပြောင်းတယ်။
Market ပြောင်းတယ်။
Technology ပြောင်းတယ်။
Customer ပြောင်းတယ်။
System ကလည်း Review လိုတယ်။
ဒါပေမယ့် Review ဆိုတာ—
နေ့တိုင်း Rule ပြောင်းတာမဟုတ်ဘူး။
Evidence ရှိမှ ပြောင်း။
Problem ရှိမှ ပြောင်း။
သင်ယူမှုရမှ ပြောင်း။
တည်ငြိမ်မှုနဲ့ ပြောင်းလဲနိုင်မှု နှစ်ခုလုံး ထိန်းရမယ်။
တရားနာပရိသတ်တို့…
System ယုံတယ်ဆိုပြီး Compassion မပျောက်ဖို့လည်း လိုတယ်။
လူတစ်ယောက်ဖျားနေတယ်။
System က—
“Attendance Rule”
ဆိုပြီး လူကို မမြင်တော့ဘူးဆိုရင် မပြည့်စုံဘူး။
ဒီဃနိကာယ် ၃၁ မှာ အလုပ်ရှင်ဘက်က ဖျားနာသည့်အခါ ဝန်ထမ်းကို ပြုစုစောင့်ရှောက်မှုနဲ့ သင့်လျော်တဲ့အချိန် အားလပ်ခွင့်ပေးမှုပါ ထည့်သွင်းထားတယ်။
ဒီမှာ Dhamma က System ကို လူသားဆန်စေတယ်။
Rule လိုတယ်။
ဒါပေမယ့် ကရုဏာလည်းလိုတယ်။
Standard လိုတယ်။
ဒါပေမယ့် လူ့အခြေအနေကိုလည်း သိရတယ်။
Accountability လိုတယ်။
ဒါပေမယ့် အရှက်ခွဲတာ မလိုဘူး။
Correction လိုတယ်။
ဒါပေမယ့် မုန်းတီးမှု မလိုဘူး။
ဒီလို Balance ရှိရမယ်။
ကဲ… အခု တစ်ချက်ကို နက်နက်စဉ်းစားကြည့်။
Founder တစ်ယောက်က ကိုယ်မရှိတဲ့အခါ အလုပ်ဖြစ်နေတာကို ဝမ်းသာနိုင်သလား။
အဲဒီမေးခွန်းက အရမ်းအရေးကြီးတယ်။
ကိုယ်မရှိဘဲ Meeting ကောင်းကောင်းပြီးသွားတယ်။
ဝမ်းသာလား။
ဒါမှမဟုတ်—
“ငါမပါဘဲ ဆုံးဖြတ်လိုက်ကြတာလား”
လို့ မကျေနပ်ဘူးလား။
Staff က Problem ဖြေရှင်းသွားတယ်။
ဝမ်းသာလား။
ဒါမှမဟုတ်—
“ဘာလို့ ငါ့ကို မပြောတာလဲ”
ဆိုပြီး Ego ထိလား။
ကိုယ်သင်ပေးထားသူက ကိုယ်ထက်ပိုကောင်းလာတယ်။
ဝမ်းသာလား။
ဒါမှမဟုတ်—
Threat လို ခံစားရလား။
အဲဒီနေရာမှာ System Building က—
Attachment Practice ဖြစ်လာတယ်။
“ငါ” ကို လျော့ဖို့။
“ငါလုပ်မှ”
“ငါပြောမှ”
“ငါရှိမှ”
“ငါသိမှ”
ဆိုတဲ့ စွဲမှုကို ပြန်ကြည့်ဖို့။
ကုမ္ပဏီကို တည်ဆောက်နေတာလား။
ကိုယ့်အတ္တကို တည်ဆောက်နေတာလား။
တစ်ခါတလေ ခွဲရခက်တယ်။
Founder Title ကို ကပ်တယ်။
“Founder ဆိုတော့ အရာအားလုံး ငါသိရမယ်”
လို့ထင်တယ်။
မဟုတ်ဘူး။
Company ကြီးလာလေ—
Founder မသိတဲ့အရာ များလာနိုင်တယ်။
အဲဒါ ပုံမှန်ပဲ။
Finance Specialist က Finance ကို ပိုသိမယ်။
Engineer က Engineering ကို ပိုသိမယ်။
Marketing Lead က Campaign ကို ပိုသိမယ်။
Operations Manager က Daily Flow ကို ပိုသိမယ်။
Founder အလုပ်က—
အရာအားလုံးထက် ပိုသိဖို့မဟုတ်ဘူး။
မှန်တဲ့လူ၊ မှန်တဲ့မူဘောင်၊ မှန်တဲ့သတင်းအချက်အလက်၊ မှန်တဲ့တာဝန်ခွဲဝေမှုနဲ့ အဖွဲ့ကို တစ်လမ်းတည်းသွားနိုင်အောင် တည်ဆောက်ဖို့။
ဒါ Leadership ရဲ့ နောက်အဆင့်။
ဒီလိုတည်ဆောက်နိုင်တဲ့အခါ Founder ကိုယ်တိုင်လည်း လွတ်လာတယ်။
အသေးအဖွဲကိစ္စ မကိုင်ရတော့ဘူး။
Strategy ကြည့်နိုင်တယ်။
လူတွေကို ဖွံ့ဖြိုးပေးနိုင်တယ်။
Future Risk စဉ်းစားနိုင်တယ်။
Culture ကို ထိန်းနိုင်တယ်။
မိသားစုအတွက် အချိန်ရှိလာနိုင်တယ်။
ကိုယ်ကျန်းမာရေး ဂရုစိုက်နိုင်တယ်။
တရားအားထုတ်ဖို့ အချိန်ပေးနိုင်တယ်။
ဒါပေမယ့် System တည်ဆောက်တာရဲ့ ရည်ရွယ်ချက်ကို—
“ငါအလုပ်မလုပ်တော့ဘူး”
လို့ မယူနဲ့။
Founder အလုပ်ပုံစံ ပြောင်းတာ။
Doing ကနေ Designing။
Answering ကနေ Teaching။
Controlling ကနေ Enabling။
Rescuing ကနေ Preventing။
ဒီလိုပြောင်းလာတယ်။
ကဲ… ဒကာကြီးတို့။
ဒီတရားမှာ System ကို အရမ်းချီးကျူးပြီး တစ်ဖက်မရောက်ဖို့လိုတယ်။
System ဆိုတာလည်း အနိစ္စပဲ။
ဒီနေ့ကောင်းတဲ့ Process မနက်ဖြန် မကိုက်နိုင်ဘူး။
ဒါကြောင့်—
System ကိုလည်း မစွဲနဲ့။
သူ့ရည်ရွယ်ချက်ကို နားလည်။
မူကို ထိန်း။
လိုအပ်ရင် နည်းလမ်းပြင်။
ဒါဟာ အလွန်အရေးကြီးတယ်။
တချို့ Leader က—
“ငါတို့ အရင်က ဒီလိုပဲလုပ်လာတာ”
ဆိုပြီး မပြောင်းဘူး။
ဒါလည်း စွဲတာ။
တချို့ Leader က—
နေ့တိုင်းအသစ်ပြောင်းတယ်။
ဒါလည်း အစွန်းတစ်ဖက်။
System က တည်ငြိမ်ဖို့လိုတယ်။
တစ်ချိန်တည်းမှာ သင်ယူနိုင်ဖို့လိုတယ်။
စနစ်တစ်ခုကို ယုံကြည်ခြင်းဆိုတာ—
မျက်စိပိတ်ယုံတာမဟုတ်ဘူး။
စစ်ဆေးနိုင်တဲ့စနစ် တည်ဆောက်ခြင်း။
Measurement ရှိ။
Feedback ရှိ။
Correction ရှိ။
Ethics ရှိ။
Review ရှိ။
ဒီလို။
ဒါကြောင့် Founder တစ်ယောက် နေ့ကုန်ရင် မေးစရာမေးခွန်း ပြောင်းရမယ်။
“ဒီနေ့ ငါ ဘယ်လောက်အလုပ်လုပ်ခဲ့လဲ”
တစ်ခုတည်း မမေးနဲ့။
“ဒီနေ့ ငါမရှိတဲ့နေ့အတွက် ဘာတည်ဆောက်ခဲ့လဲ”
မေး။
“ဒီနေ့ ဘယ်နှ Problem ဖြေရှင်းခဲ့လဲ”
တစ်ခုတည်း မမေးနဲ့။
“ဒီ Problem မနက်ဖြန်မပြန်ဖြစ်အောင် ဘာပြင်ခဲ့လဲ”
မေး။
“Staff က ငါ့ကို ဘယ်လောက်လိုအပ်လဲ”
တစ်ခုတည်း မမေးနဲ့။
“Staff ကို ကိုယ်တိုင်ဆုံးဖြတ်နိုင်အောင် ဘယ်လောက်သင်ပေးခဲ့လဲ”
မေး။
“ငါမရှိရင် ဘယ်သူမှ မလုပ်နိုင်ဘူး”
လို့ ဂုဏ်ယူမယ့်အစား—
“ငါမရှိလည်း မှန်မှန်လုပ်နိုင်တဲ့လူတွေ တည်ဆောက်ထားတယ်”
လို့ ဝမ်းသာနိုင်အောင် ကြိုးစား။
ဒါက Founder ရဲ့ အမွေတစ်ခု။
တစ်နေ့ ကိုယ်ထွက်သွားရင်—
Office Building မကျန်လည်း ရတယ်။
Brand ပြောင်းနိုင်တယ်။
Technology ပြောင်းနိုင်တယ်။
ဒါပေမယ့်—
သီလရှိတဲ့ Culture၊
မှန်ကန်တဲ့ Decision Principle၊
အချင်းချင်းလေးစားမှု၊
Learning Habit၊
တာဝန်ယူမှု၊
စနစ်တကျလုပ်တတ်မှု၊
အမှန်ပြောရဲမှု၊
လူကို ဖွံ့ဖြိုးပေးတတ်မှု—
ဒီလိုအရာတွေ ကျန်ခဲ့ရင်—
ဒါ တန်ဖိုးကြီးတဲ့အမွေ။
ဒကာ ဒကာမတို့…
အခု ဒီတရားကို ပိုနက်တဲ့ဓမ္မဘက် ဆင်းကြည့်ရအောင်။
ဘာကြောင့် လူက စွမ်းအားကို စနစ်ထက် ပိုယုံတတ်သလဲ။
ဘာကြောင့်—
“ငါကိုယ်တိုင်လုပ်လိုက်မယ်”
ဆိုတာ အမြဲလွယ်သလဲ။
တစ်ဖက်မှာ အချိန်မြန်လို့။
ဒါမှန်တယ်။
ဒါပေမယ့် အတွင်းမှာ—
Control လိုစိတ်ရှိနိုင်တယ်။
အထင်ကြီးခံချင်မှုရှိနိုင်တယ်။
မှားမှာကြောက်မှုရှိနိုင်တယ်။
သူများကို မယုံမှုရှိနိုင်တယ်။
ကိုယ်မလိုတော့မှာကြောက်မှုရှိနိုင်တယ်။
အဲဒီနေရာမှာ—
Business Problem ဟာ စိတ်ပြဿနာနဲ့ ဆုံလာတယ်။
ကဲ… ဦးဇင်းတို့ မျက်စိမှိတ်ပြီး ခဏစဉ်းစားကြည့်လို့ရတယ်။
ကိုယ့်လုပ်ငန်းထဲမှာ—
“ငါပဲလုပ်မှဖြစ်တယ်”
လို့ ကိုယ်ယူထားတဲ့အရာ တစ်ခုရှိသလား။
တကယ်ကိုယ်ပဲလုပ်ရတာလား။
ဒါမှမဟုတ် လွှဲမပေးချင်တာလား။
ကိုယ်မပါဘဲ Team က ဆုံးဖြတ်သွားရင် စိတ်ထဲ ဘာဖြစ်လဲ။
စိုးရိမ်သလား။
ဒေါသထွက်သလား။
ဂုဏ်ထိသလား။
ဝမ်းသာသလား။
ဒီကိုကြည့်။
System Building ကို ဘာ software သုံးမလဲဆိုတာထက်—
တစ်ခါတလေ ဒီမေးခွန်းက ပိုအရေးကြီးတယ်။
ကိုယ့်အတ္တကို မမြင်ရင်—
System ဘယ်လောက်ရေးရေး Founder က ပြန်ချိုးနိုင်တယ်။
ကိုယ့်ကြောက်စိတ်ကို မမြင်ရင်—
Delegation လုပ်ပြီး ပြန်ယူမယ်။
ကိုယ့် Control လိုစိတ်ကို မမြင်ရင်—
Manager ခန့်ပြီး Manager ကို Manager လုပ်ခွင့်မပေးဘူး။
အဲဒီတော့—
System Transformation မတိုင်ခင်—
Mind Transformation လိုတယ်။
သမ္မာဒိဋ္ဌိနဲ့ ကြည့်။
“အရာအားလုံးကို ငါထိန်းလို့ မရဘူး”
လို့ မြင်။
လူက လူပဲ။
မှားနိုင်တယ်။
ကိုယ်တိုင်လည်း မှားနိုင်တယ်။
System လည်း မှားနိုင်တယ်။
ဒါကြောင့်—
အမှားကင်းစင်တဲ့ကမ္ဘာ မရှာဘဲ—
အမှားကို မြန်မြန်သိ၊ မှန်မှန်ပြင်၊ သင်ယူနိုင်တဲ့အဖွဲ့ တည်ဆောက်။
ဒီက ပိုလက်တွေ့ကျတယ်။
စွမ်းအားဆိုတာ တစ်နေ့ကျမယ်။
ကိုယ်အားကျမယ်။
အာရုံကျမယ်။
အရွယ်ရမယ်။
အခြေအနေပြောင်းမယ်။
ဒါ အနိစ္စ။
စနစ်လည်း အနိစ္စ။
ဒါပေမယ့်—
သတိနဲ့ တည်ဆောက်ထားတဲ့ အကြောင်းအခြေအနေတွေက အကျိုးကောင်းဖြစ်လာဖို့ ပံ့ပိုးနိုင်တယ်။
ဒီမှာ ဦးဇင်းတို့ အမြဲသတိရရမှာ—
System က ဘုရားမဟုတ်ဘူး။
System ကို worship မလုပ်နဲ့။
System က ကိရိယာ။
ရည်ရွယ်ချက်က—
လူကောင်းများ အကျိုးရှိစွာ အတူလုပ်နိုင်ဖို့။
အမှားလျော့ဖို့။
တရားမျှတဖို့။
သီလမပျက်ဖို့။
လူတစ်ယောက်ပေါ် မတရားဝန်မပိဖို့။
ဒီလိုပဲ။
အခု သစ္စာလေးပါးနဲ့ ဒီတရားကို ဆုံကြည့်မယ်။
လူတစ်ယောက်ရဲ့ စွမ်းအားကို အရာအားလုံးက မှီခိုနေတဲ့အဖွဲ့မှာ—
ဒုက္ခ ရှိတယ်။
Founder မနားနိုင်ဘူး။
Team မကြီးလာဘူး။
ဆုံးဖြတ်ချက်အားလုံး ပိတ်နေတယ်။
အရေးပေါ်ကိစ္စတွေ များတယ်။
လူတစ်ယောက်ဖျားတာနဲ့ အလုပ်ရပ်တယ်။
လူတစ်ယောက်ထွက်တာနဲ့ အသိပညာပျောက်တယ်။
Staff က Founder ကို စောင့်ရတယ်။
Founder က Staff ကို မယုံဘူး။
လူတိုင်း ပင်ပန်းတယ်။
ဒါ ဒုက္ခ။
အဲဒီဒုက္ခရဲ့ သမုဒယ ဘက်ကိုကြည့်။
အကြောင်းက တစ်ခုတည်း မဟုတ်ဘူး။
Skill Gap ဖြစ်နိုင်တယ်။
Capital နည်းမှု ဖြစ်နိုင်တယ်။
Team သေးမှု ဖြစ်နိုင်တယ်။
စတင်ကာလဖြစ်နိုင်တယ်။
ဒါတွေက လက်တွေ့အကြောင်းတွေ။
ဒါပေမယ့် စိတ်ထဲမှာ—
Control လိုမှု။
“ငါပဲ”
ဆိုတဲ့စွဲမှု။
မှားမှာကြောက်မှု။
လူကို မယုံမှု။
လိုအပ်ခံရမှုကို စွဲမှု။
အရာအားလုံး Perfect ဖြစ်ချင်မှု။
ဂုဏ်လိုမှု။
ဒီအရာတွေကလည်း လူတစ်ယောက်ပေါ် အားလုံးစုလာစေတယ်။
ဒီအရာတွေကို မမြင်ရင်—
System တည်ဆောက်မယ်ပြောပြီး အတွင်းက ပြန်ဖျက်နေမယ်။
System Building က Founder Technique တစ်ခုတည်းမဟုတ်တော့ဘူး။
ကိုယ့်စိတ်ကို ကြည့်တဲ့ Practice တစ်ခုဖြစ်လာတယ်။
လွှတ်တတ်မှုကို လေ့ကျင့်ရတယ်။
သူများကို ယုံကြည်ဖို့ လေ့ကျင့်ရတယ်။
မှားနိုင်ခြင်းကို လက်ခံဖို့ လေ့ကျင့်ရတယ်။
အမှန်ပြောတဲ့ Culture ကို တည်ဆောက်ရတယ်။
တာဝန်ယူမှုနဲ့ ကရုဏာကို အတူထားရတယ်။
ဒကာ ဒကာမတို့…
ဒီနေ့ကစပြီး တစ်ခုပဲ လုပ်ကြည့်။
ကိုယ်အမြဲဝင်ကယ်နေရတဲ့ ပြဿနာတစ်ခုရွေး။
ပြီးတော့ မေး—
“ဒီပြဿနာကို နောက်တစ်ခါ ငါမဝင်ကယ်ရအောင် ဘာတည်ဆောက်ရမလဲ”
တစ်ခု။
Checklist လား။
Training လား။
Role ရှင်းဖို့လား။
Decision Boundary လား။
Communication Rule လား။
Information Sharing လား။
Review လား။
Ethics Rule လား။
လူသစ်တစ်ယောက် ထပ်သင်ပေးဖို့လား။
ဘယ်ဟာလဲ။
ပြန်ကြည့်။
နောက်တစ်ခု—
ကိုယ်တစ်ယောက်ပဲ သိနေတဲ့အရာတစ်ခုကို ရွေး။
အဲဒါကို လုံခြုံစွာ မျှဝေနိုင်တဲ့ ပုံစံလုပ်။
နောက်တစ်ခု—
Team က မေးတိုင်း ကိုယ်ဖြေပေးမယ့်အစား—
တစ်ခါတလေ—
“မင်းဘယ်လိုစဉ်းစားထားလဲ”
ပြန်မေး။
သူတို့စဉ်းစားခွင့်ပေး။
ကိုယ့်ဖြေဆိုချက်ပဲ ပေးနေတဲ့ Leader က—
လိုက်နာသူတွေ ဖန်တီးတယ်။
စဉ်းစားခွင့်ပေးတဲ့ Leader က—
နောက် Leader တွေ ဖန်တီးနိုင်တယ်။
ဒီဟာ အရေးကြီးတယ်။
ပြီးတော့—
ကိုယ်မရှိတဲ့နေ့မှာ အလုပ်ဖြစ်တာကို စမ်းကြည့်။
အမြဲအကုန်ဝင်မလုပ်နဲ့။
မသေချာတဲ့နေရာမှာ Guardrail ထား။
အဲဒီနောက် ကြည့်။
ဘယ်နေရာမှာ System ပျက်လဲ။
အပြစ်ရှာဖို့မဟုတ်ဘူး။
သင်ယူဖို့။
ဒီလိုနဲ့ လုပ်ငန်းက—
Founder ရဲ့ ကိုယ်အားကို စားသုံးနေတဲ့စနစ်ကနေ—
လူများစွာရဲ့ ပညာ၊ သီလ၊ တာဝန်ယူမှုနဲ့ ပူးပေါင်းလုပ်နိုင်တဲ့စနစ် ဖြစ်လာမယ်။
နောက်ဆုံးတစ်ခု သတိထား။
Founder ကိုယ်တိုင်လည်း တစ်နေ့မရှိတော့ဘူး။
ဒီဟာ စိတ်မကောင်းစရာလို့ပြောတာမဟုတ်ဘူး။
အနိစ္စရဲ့အမှန်။
ဒီအမှန်ကို သိလို့—
ပိုကောင်းတဲ့အမွေထားခဲ့ရမယ်။
“ငါရှိတုန်း ငါအရမ်းတော်တယ်”
ဆိုတဲ့အမွေထက်—
“ငါရှိတုန်း လူတွေတော်လာအောင်၊ စနစ်ကောင်းလာအောင်၊ သီလတည်လာအောင် တည်ဆောက်ခဲ့တယ်”
ဆိုတဲ့အမွေက ပိုတန်ဖိုးရှိနိုင်တယ်။
လုပ်ငန်းကြီးတစ်ခုထားခဲ့တာထက်—
လူကောင်းတွေ ထားခဲ့။
Rule စာအုပ်ကြီးထားခဲ့တာထက်—
အမှန်ကိုတန်ဖိုးထားတဲ့ Culture ထားခဲ့။
ကိုယ့်နာမည်ထားခဲ့တာထက်—
အကျိုးရှိတဲ့နည်းလမ်းထားခဲ့။
တစ်နေ့ ကိုယ့်နာမည်မရှိတော့လည်း—
ကောင်းတဲ့အကျိုး ဆက်သွားနိုင်ရင်—
အဲဒီစနစ် တန်ဖိုးရှိတယ်။
ဒီနေ့တရားနာယူမှုမှသည်—
မိမိတို့လုပ်ငန်းများသည် လူတစ်ယောက်၏ အလွန်အကျွံစွမ်းအားပေါ်သာ တည်မှီနေသောလုပ်ငန်းများ မဖြစ်ကြပါစေနှင့်။
လူတော်များကို လေးစားနိုင်ကြပါစေ။
လူတော်တစ်ယောက်ပေါ် အားလုံးမပစ်ထားကြပါစေနှင့်။
အသိပညာကို မျှဝေနိုင်ကြပါစေ။
တာဝန်ကို မှန်ကန်စွာ ခွဲဝေနိုင်ကြပါစေ။
ဆုံးဖြတ်ခွင့်ကို သင့်လျော်စွာပေးနိုင်ကြပါစေ။
အမှားကို ဖုံးကွယ်ခြင်းမဟုတ်ဘဲ သင်ယူခြင်းအဖြစ် ပြောင်းနိုင်ကြပါစေ။
ပြဿနာဖြစ်တိုင်း Hero လုပ်ရခြင်းထက် ပြဿနာမဖြစ်အောင် အကြောင်းအခြေအနေ ကောင်းကောင်းတည်ဆောက်နိုင်ကြပါစေ။
အဖွဲ့ဝင်တို့၏ စွမ်းရည်ကို ဖိထားခြင်းမဟုတ်ဘဲ ဖွံ့ဖြိုးစေနိုင်ကြပါစေ။
မိမိမပါဘဲ အလုပ်ဖြစ်လာသည့်အခါ မနာလိုခြင်းမရှိဘဲ ဝမ်းမြောက်နိုင်ကြပါစေ။
“ငါပဲ” ဆိုသော စွဲလမ်းမှု လျော့ပါးနိုင်ကြပါစေ။
“ငါမရှိရင် မဖြစ်ဘူး” ဆိုသော အတ္တမာနကို ပညာဖြင့် ပြန်မြင်နိုင်ကြပါစေ။
တာဝန်ကို မပစ်ဘဲ လွှတ်တတ်ကြပါစေ။
ယုံကြည်မှုမဲ့ခြင်းမဟုတ်ဘဲ စစ်ဆေးနိုင်သော ယုံကြည်မှု တည်ဆောက်နိုင်ကြပါစေ။
စနစ်ရှိခြင်းကြောင့် မေတ္တာပျောက်မသွားကြပါစေနှင့်။
စည်းကမ်းရှိခြင်းကြောင့် ကရုဏာမပျောက်ကြပါစေနှင့်။
ကရုဏာရှိခြင်းကြောင့် တာဝန်ယူမှုမပျောက်ကြပါစေနှင့်။
တာဝန်ယူမှုရှိခြင်းကြောင့် လူ့ဂုဏ်သိက္ခာကို မဖျက်ဆီးကြပါစေနှင့်။
အဖွဲ့အစည်းအတွင်း ညီညွတ်စွာ စည်းဝေးနိုင်ကြပါစေ။
မှန်ကန်သောအရာကို မှန်ကန်သောအရာဟု ပြောနိုင်ကြပါစေ။
အမှားကို အမှားဟု ငြိမ်းချမ်းစွာ ပြောနိုင်ကြပါစေ။
ကောင်းသောမူဝါဒများကို ထိန်းသိမ်းနိုင်ကြပါစေ။
မကောင်းတော့သော နည်းလမ်းများကို သတိပညာဖြင့် ပြင်နိုင်ကြပါစေ။
သီလ၊ သတိ၊ ပညာတို့နှင့် လုပ်ငန်းစီမံနိုင်ကြပါစေ။
ဒုက္ခကို ဒုက္ခအဖြစ် သိနိုင်ကြပါစေ။
အရာအားလုံး ကိုယ်တစ်ယောက်တည်း ထိန်းချုပ်လိုသောစွဲလမ်းမှုကို သမုဒယဘက်မှ မြင်နိုင်ကြပါစေ။
တဏှာ၊ ဥပါဒါန်နှင့် အတ္တမာနတို့ အေးချမ်းလျော့ပါးရာ နိရောဓ၏အရသာကို သိရှိနိုင်ကြပါစေ။
သမ္မာဒိဋ္ဌိ၊ သမ္မာသင်္ကပ္ပ၊ သမ္မာဝါစာ၊ သမ္မာကမ္မန္တ၊ သမ္မာအာဇီဝ၊ သမ္မာဝါယာမ၊ သမ္မာသတိ၊ သမ္မာသမာဓိတို့ဖြင့် မိမိတို့ဘဝနှင့် လုပ်ငန်းကို ကောင်းသောအကြောင်းအခြေအနေများအဖြစ် တည်ဆောက်နိုင်ကြပါစေ။
မိမိတို့၏ စွမ်းအားသည် အနိစ္စဖြစ်ကြောင်း သိနိုင်ကြပါစေ။
ထို့ကြောင့် စွမ်းအားရှိစဉ် ကောင်းသောလူများကို တည်ဆောက်နိုင်ကြပါစေ။
ကောင်းသောလူများရှိစဉ် ကောင်းသောစနစ်များ တည်ဆောက်နိုင်ကြပါစေ။
ကောင်းသောစနစ်များရှိစဉ် သီလနှင့်ပညာဖြင့် ထိန်းသိမ်းနိုင်ကြပါစေ။
မည်သည့်စနစ်ကိုမျှ စွဲလမ်းခြင်းမရှိဘဲ အကျိုးရှိသည့်အခါ အသုံးချ၍ အကျိုးမရှိတော့သည့်အခါ ပညာဖြင့် ပြန်လည်ပြုပြင်နိုင်ကြပါစေ။
အလုပ်ကိုသာ မတည်ဆောက်ဘဲ လူကို တည်ဆောက်နိုင်ကြပါစေ။
လူကိုသာ မတည်ဆောက်ဘဲ ကုသိုလ်တရားကို တည်ဆောက်နိုင်ကြပါစေ။
မိမိကိုယ်တိုင် တစ်နေ့မရှိတော့သည့်အခါလည်း ကောင်းသောအကျိုးများ ဆက်လက်တည်ရှိနိုင်သည့် အကြောင်းအခြေအနေများ ထားခဲ့နိုင်ကြပါစေ။
သတ္တဝါအပေါင်း ဘေးရန်ကင်းကြပါစေ။
ကိုယ်စိတ်နှစ်ပါး ချမ်းသာကြပါစေ။
အချင်းချင်း ယုံကြည်မှု၊ မေတ္တာ၊ ကရုဏာ၊ သီလ၊ ပညာတို့ဖြင့် အတူတကွ ဆောင်ရွက်နိုင်ကြပါစေ။
ဗုဒ္ဓ သာသနံ စိရံ တိဋ္ဌတု
ဗုဒ္ဓ သာသနံ စိရံ တိဋ္ဌတု
ဗုဒ္ဓ သာသနံ စိရံ တိဋ္ဌတု
