လက်လီအရောင်းဆိုင်မှာ စားပွဲတင်၊ တကယ်လား။

Excel တွင် အစီရင်ခံရန် အချိန်သည် လျင်မြန်စွာ ပျောက်ကွယ်သွားသည် - အချက်အလက်များကို တင်ပြခြင်းနှင့် ခွဲခြမ်းစိတ်ဖြာခြင်းအတွက် အဆင်ပြေသော ကိရိယာများဆီသို့ လမ်းကြောင်းကို နေရာတိုင်းတွင် မြင်နိုင်သည်။ ကျွန်ုပ်တို့သည် အစီရင်ခံခြင်း၏ ဒစ်ဂျစ်တယ်အသွင်ကူးပြောင်းရေးကို အချိန်အတော်ကြာအောင် အတွင်းပိုင်း၌ ဆွေးနွေးခဲ့ပြီး Tableau စိတ်ကူးပုံဖော်မှုနှင့် ကိုယ်တိုင်ဝန်ဆောင်မှု ခွဲခြမ်းစိတ်ဖြာမှုစနစ်ကို ရွေးချယ်ခဲ့သည်။ M.Video-Eldorado Group ၏ ခွဲခြမ်းစိတ်ဖြာဖြေရှင်းချက်များနှင့် အစီရင်ခံရေးဌာန အကြီးအကဲ Alexander Bezugly က တိုက်ပွဲဒိုင်ခွက်တစ်ခုတည်ဆောက်ခြင်း၏ အတွေ့အကြုံနှင့် ရလဒ်များအကြောင်းကို ပြောကြားခဲ့သည်။

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

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

ငါတို့ဘယ်ကစခဲ့တာလဲ။

M.Video-Eldorado တွင် ကောင်းမွန်စွာ တီထွင်ထားသော ဒေတာမော်ဒယ်တစ်ခု ရှိသည်- လိုအပ်သော သိုလှောင်မှုအတိမ်အနက်နှင့် ဖွဲ့စည်းတည်ဆောက်ထားသော အချက်အလက်များနှင့် ပုံသေပုံစံ အစီရင်ခံစာအများအပြား (အသေးစိတ်အချက်အလက်များကို ပိုမိုကြည့်ရှုပါ။ ဤဆောင်ပါး) ယင်းတို့ထံမှ လေ့လာဆန်းစစ်သူများသည် မဏ္ဍိုင်ဇယားများ သို့မဟုတ် Excel တွင် ဖော်မတ်လုပ်ထားသော သတင်းလွှာများ သို့မဟုတ် သုံးစွဲသူများအတွက် လှပသော PowerPoint တင်ပြမှုများကို ပြုလုပ်ကြသည်။

လွန်ခဲ့သောနှစ်နှစ်ခန့်က ပုံသေပုံစံအစီရင်ခံစာများအစား SAP ခွဲခြမ်းစိတ်ဖြာမှုအစီရင်ခံစာများ (Excel အပိုပရိုဂရမ်တစ်ခု၊ အခြေခံအားဖြင့် OLAP အင်ဂျင်ပေါ်ရှိ ဆုံချက်ဇယား) ကို စတင်ဖန်တီးခဲ့သည်။ သို့သော် ဤကိရိယာသည် အသုံးပြုသူအားလုံး၏ လိုအပ်ချက်များကို ဖြည့်ဆည်းပေးနိုင်ခြင်းမရှိခဲ့ဘဲ၊ အများစုသည် လေ့လာသုံးသပ်သူများမှ စီမံဆောင်ရွက်ထားသော အချက်အလက်များကို ဆက်လက်အသုံးပြုနေပါသည်။

ကျွန်ုပ်တို့၏ သုံးစွဲသူများသည် အမျိုးအစားသုံးမျိုး ခွဲခြားထားပါသည်။

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

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

အစုလိုက်အပြုံလိုက်အသုံးပြုသူများ. ၎င်းတို့သည် အချက်အလက်များကို လွတ်လပ်စွာ ခွဲခြမ်းစိတ်ဖြာရန် စိတ်မဝင်စားပါ၊ ၎င်းတို့သည် Excel ရှိ သတင်းလွှာများနှင့် မဏ္ဍိုင်ဇယားများပုံစံဖြင့် လွတ်လပ်မှုအတိုင်းအတာ အကန့်အသတ်ရှိသော အစီရင်ခံစာများကို အသုံးပြုသည်။

ကျွန်ုပ်တို့၏ စိတ်ကူးမှာ သုံးစွဲသူအားလုံး၏ လိုအပ်ချက်များကို ကာမိစေရန်နှင့် ၎င်းတို့ကို တစ်ခုတည်းသော အဆင်ပြေသော ကိရိယာတစ်ခု ပေးဆောင်ရန်ဖြစ်သည်။ ထိပ်တန်းစီမံခန့်ခွဲမှုဖြင့် စတင်ရန် ဆုံးဖြတ်ခဲ့သည်။ အဓိက လုပ်ငန်းရလဒ်များကို ခွဲခြမ်းစိတ်ဖြာရန် ၎င်းတို့သည် အသုံးပြုရလွယ်ကူသော ဒက်ရှ်ဘုတ်များ လိုအပ်ပါသည်။ ထို့ကြောင့်၊ ကျွန်ုပ်တို့သည် Tableau ဖြင့် စတင်ခဲ့ပြီး ထိပ်တန်းစီမံခန့်ခွဲမှုမှ တောင်းဆိုထားသည့် ဒေတာ၏ 80% ခန့်ကို လွှမ်းခြုံနိုင်စေမည့် ကန့်သတ်အတိမ်အနက်နှင့် အနံပါရှိသော ခွဲခြမ်းစိတ်ဖြာမှု အကန့်အသတ်ရှိသော လက်လီနှင့် အွန်လိုင်းရောင်းချမှုဆိုင်ရာ ညွှန်ကိန်းများကို ဦးစွာရွေးချယ်ခဲ့သည်။

ဒက်ရှ်ဘုတ်များကို အသုံးပြုသူများသည် ထိပ်တန်းစီမံခန့်ခွဲမှုဖြစ်သောကြောင့်၊ ထုတ်ကုန်၏ နောက်ထပ် KPI ပေါ်လာသည် - တုံ့ပြန်မှုမြန်နှုန်း။ ဒေတာ အပ်ဒိတ်လုပ်ရန် စက္ကန့် 20-30 စောင့်မည် မဟုတ်ပါ။ လမ်းကြောင်းပြခြင်းကို 4-5 စက္ကန့်အတွင်း လုပ်ဆောင်သင့်သည်၊ သို့မဟုတ် ပိုကောင်းသော်လည်း၊ ချက်ချင်းလုပ်ဆောင်သင့်သည်။ ဖြစ်ချင်တော့ ငါတို့ ဒါကို အောင်မြင်အောင် မအောင်မြင်ခဲ့ဘူး။

ကျွန်ုပ်တို့၏ပင်မဒိုင်ခွက်၏ အပြင်အဆင်မှာ ဤအရာဖြစ်သည်-

အဓိက အိုင်ဒီယာမှာ ဘယ်ဘက်တွင် စုစုပေါင်း 19 ခု ပါရှိသည့် အဓိက KPI ဒရိုက်ဘာများကို ပေါင်းစပ်ပြီး ညာဘက်တွင် ၎င်းတို့၏ ဒိုင်နမစ်များနှင့် ကွဲအက်မှုများကို တင်ပြရန်ဖြစ်သည်။ အလုပ်သည် ရိုးရှင်းပုံရသည်၊ အသေးစိတ်အချက်အလက်များကို သင်မသိမချင်း စိတ်ကူးပုံဖော်ခြင်းသည် ယုတ္တိရှိပြီး နားလည်နိုင်သည်။

အသေးစိတ်အချက် ၁။ ဒေတာပမာဏ

နှစ်စဉ်ရောင်းအားအတွက် ကျွန်ုပ်တို့၏ အဓိကစားပွဲသည် အတန်းပေါင်း သန်း 300 ခန့်ရှိသည်။ ယမန်နှစ်နှင့်ယခင်နှစ်အတွက် ဒိုင်းနမစ်များကို ရောင်ပြန်ဟပ်ရန် လိုအပ်သောကြောင့် အမှန်တကယ်ရောင်းအားတစ်ခုတည်းတွင် ဒေတာပမာဏသည် လိုင်း ၁ ဘီလီယံခန့်ရှိသည်။ စီစဉ်ထားသောဒေတာနှင့် အွန်လိုင်းရောင်းချမှုပိတ်ဆို့ခြင်းဆိုင်ရာ အချက်အလက်များကိုလည်း သီးခြားသိမ်းဆည်းထားသည်။ ထို့ကြောင့်၊ ကျွန်ုပ်တို့သည် columnar in-memory DB SAP HANA ကိုအသုံးပြုသော်လည်း၊ လက်ရှိသိုလှောင်မှုမှ တစ်ပတ်တာအတွက် ညွှန်ကိန်းများအားလုံးရွေးချယ်မှုနှင့်အတူ မေးမြန်းမှု၏အမြန်နှုန်းမှာ 1-15 စက္ကန့်ခန့်ဖြစ်သည်။ ဤပြဿနာအတွက် အဖြေသည် သူ့ဘာသာသူ အကြံပြုသည် - ဒေတာ၏ ထပ်လောင်းရုပ်လုံးပေါ်လာခြင်း ။ ဒါပေမယ့်လည်း အောက်မှာဖော်ပြထားတဲ့ အားနည်းချက်တွေရှိပါတယ်။

အသေးစိတ် 2. ပေါင်းထည့်ခြင်းမရှိသော အညွှန်းများ

ကျွန်ုပ်တို့၏ KPI အများအပြားကို လက်ခံဖြတ်ပိုင်းအရေအတွက်နှင့် ချိတ်ဆက်ထားသည်။ ဤညွှန်ပြချက်သည် အတန်းအရေအတွက်၏ COUNT DISTINCT ကို ကိုယ်စားပြုပြီး ရွေးချယ်ထားသော အရည်အချင်းများပေါ်မူတည်၍ ကွဲပြားသောပမာဏကို ပြသသည်။ ဥပမာအားဖြင့်၊ ဤညွှန်ကိန်းနှင့် ၎င်း၏ ဆင်းသက်လာမှုကို မည်ကဲ့သို့ တွက်ချက်သင့်သည်-

သင်၏ တွက်ချက်မှုများကို မှန်ကန်စေရန်၊ သင်လုပ်နိုင်သည်-

• သိုလှောင်မှုတွင် ပျံသန်းနေသည့် ညွှန်ကိန်းများကို တွက်ချက်ပါ။
• Tableau ရှိ ဒေတာထုထည်တစ်ခုလုံးအတွက် တွက်ချက်မှုများကို လုပ်ဆောင်ပါ။ Tableau တွင်တောင်းဆိုချက်အရ၊ လက်ခံရရှိမှုအနေအထား၏အသေးစိတ်အချက်တွင် ရွေးချယ်ထားသော စစ်ထုတ်မှုများအရ အချက်အလက်အားလုံးကို ပေးဆောင်ပါ။
• မတူညီသော ပေါင်းထည့်ခြင်းမရှိသော ရလဒ်များကို ပေးစွမ်းနိုင်သော နမူနာရွေးချယ်မှုအားလုံးတွင် ညွှန်ကိန်းများအားလုံးကို တွက်ချက်မည့် ရုပ်လုံးပေါ်လာအောင် ဖန်တီးပါ။

ဥပမာ UTE1 နှင့် UTE2 တို့သည် ထုတ်ကုန်၏ အထက်တန်းအဆင့်ကို ကိုယ်စားပြုသည့် ပစ္စည်း attribute များဖြစ်ကြောင်း ထင်ရှားပါသည်။ ဤအရာသည် တည်ငြိမ်သောအရာမဟုတ်ပါ၊ ကုမ္ပဏီအတွင်း စီမံခန့်ခွဲမှုသည် ၎င်းကိုဖြတ်သန်းသောကြောင့်ဖြစ်သည်။ မတူညီသော မန်နေဂျာများသည် မတူညီသော ထုတ်ကုန်အုပ်စုများအတွက် တာဝန်ရှိပါသည်။ အဆင့်အားလုံးပြောင်းလဲသောအခါ၊ ဆက်ဆံရေးများကို ပြန်လည်ပြင်ဆင်သောအခါ၊ အုပ်စုတစ်ခုမှ node တစ်ခုမှ အခြားတစ်ခုသို့ ရွေ့လျားလာသောအခါတွင် အဆက်မပြတ်အမှတ်ပြောင်းလဲသောအခါ၊ ဤအထက်တန်းအဆင့်၏ ကမ္ဘာလုံးဆိုင်ရာ ပြန်လည်ပြင်ဆင်မှုများစွာကို ကျွန်ုပ်တို့ရှိခဲ့ပါသည်။ သမားရိုးကျအစီရင်ခံမှုတွင်၊ ဤအရာအားလုံးကို ပစ္စည်း၏ဂုဏ်ရည်တော်များမှ ပျံသန်းမှုတွင် တွက်ချက်သည်၊ ဤဒေတာကို ရုပ်လုံးပေါ်လာသောအခါတွင်၊ ထိုပြောင်းလဲမှုများကို ခြေရာခံရန်နှင့် သမိုင်းအချက်အလက်များကို အလိုအလျောက် ပြန်လည်စတင်ရန်အတွက် ယန္တရားတစ်ခု ဖန်တီးရန် လိုအပ်ပါသည်။ အလွန်အသေးအဖွဲမဟုတ်သော အလုပ်တစ်ခု။

အသေးစိတ်အချက် ၃။ ဒေတာ နှိုင်းယှဉ်ခြင်း။

ဤအချက်သည် ယခင်အချက်နှင့် ဆင်တူသည်။ အဓိကအချက်မှာ ကုမ္ပဏီတစ်ခုအား ခွဲခြမ်းစိတ်ဖြာသည့်အခါ ယခင်ကာလနှင့် နှိုင်းယှဉ်မှု အဆင့်များစွာကို ဖွဲ့စည်းရန် ထုံးစံအတိုင်းဖြစ်သည်-

ယခင်ကာလနှင့် နှိုင်းယှဉ်ခြင်း (နေ့စဉ်၊ တစ်ပတ်မှ တစ်ပတ်၊ လမှတစ်လ)

ဤနှိုင်းယှဉ်မှုတွင်၊ အသုံးပြုသူမှရွေးချယ်ထားသောကာလပေါ် မူတည်၍ (ဥပမာ၊ တစ်နှစ်၏ 33 ရက်သတ္တပတ်) တွင် ကျွန်ုပ်တို့သည် 32 ရက်သတ္တပတ်တွင် ဒိုင်နမစ်များကိုပြသသင့်သည်ဟု ယူဆသည်၊ ဥပမာအားဖြင့် တစ်လအတွက်ဒေတာကိုရွေးချယ်ပါက၊ မေလ၊ ထို့နောက် ဤနှိုင်းယှဉ်မှုသည် ဧပြီလတွင် ဒိုင်နမစ်များကို ပြသမည်ဖြစ်သည်။

မနှစ်ကနဲ့ နှိုင်းယှဉ်တယ်။

ဤနေရာတွင် အဓိက ကွာခြားချက်မှာ နေ့နှင့် အပတ်ကို နှိုင်းယှဉ်ကြည့်သောအခါ၊ သင်သည် ယမန်နှစ်၏ တူညီသောနေ့ကို မယူဘဲ၊ ဆိုလိုသည်မှာ၊ လက်ရှိနှစ်ကို အနုတ်လက္ခဏာပြရုံနဲ့တင် မရပါဘူး။ သင်နှိုင်းယှဉ်နေသော ရက်သတ္တပတ်၏နေ့ရက်ကို ကြည့်ရှုရပါမည်။ လများကို နှိုင်းယှဉ်သောအခါ၊ ဆန့်ကျင်ဘက်အနေနှင့် သင်သည် ယမန်နှစ်၏ ပြက္ခဒိန်နေ့ကို အတိအကျယူရန် လိုအပ်သည်။ ရက်ထပ်နှစ်များနှင့် ကွဲလွဲမှုများလည်း ရှိပါသည်။ မူရင်းသိမ်းဆည်းရာနေရာများတွင် အချက်အလက်အားလုံးကို နေ့အလိုက်ဖြန့်ဝေသည်၊ ရက်သတ္တပတ်များ၊ လများ သို့မဟုတ် နှစ်များပါ သီးခြားအကွက်များမရှိပါ။ ထို့ကြောင့်၊ အကန့်ရှိ ပြီးပြည့်စုံသော ခွဲခြမ်းစိတ်ဖြာမှုပိုင်းဖြတ်ပိုင်းကို ရယူရန်၊ ဥပမာအားဖြင့် တစ်ပတ်လျှင် 4 ပတ်ကို အချိန်ကာလတစ်ခုမျှ မရေတွက်ရန် လိုအပ်ပြီး ထိုဒေတာများကို နှိုင်းယှဉ်ကာ ဒိုင်နမစ်များ၊ သွေဖည်မှုများကို ထင်ဟပ်စေပါသည်။ ထို့ကြောင့်၊ ဒိုင်းနမစ်တွင် နှိုင်းယှဉ်မှုများကို ဖန်တီးရန်အတွက် ဤယုတ္တိကို Tableau တွင် သို့မဟုတ် စတိုးဆိုင်ဘက်၌လည်း အကောင်အထည်ဖော်နိုင်သည်။ ဟုတ်ပါတယ်၊ ဒီဇိုင်းအဆင့်မှာ ဒီအသေးစိတ်အချက်အလက်တွေကို သိပြီး စဉ်းစားထားပေမယ့် နောက်ဆုံးဒိုင်ခွက်ရဲ့ စွမ်းဆောင်ရည်အပေါ် သူတို့ရဲ့ သက်ရောက်မှုကို ခန့်မှန်းရခက်ပါတယ်။

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

အပိုင်း 1- Tableau တွင်ယုံကြည်ခြင်း

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

အဆင့် 1။ အရာအားလုံးသည် တိုက်ရိုက်ဖြစ်သည်၊ ဝင်းဒိုးပြုပြင်မွမ်းမံမှုများမရှိပါ။

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

ရလဒ်:

အဖြေက စိတ်ပျက်စရာ - မိနစ် 20 ။ ကွန်ရက်မှတဆင့် ဒေတာလွှဲပြောင်းမှု၊ Tableau တွင် မြင့်မားသောဝန်ထုပ်ဝန်ပိုး။ ပေါင်းထည့်ခြင်းမရှိသော အညွှန်းများပါသော ယုတ္တိဗေဒကို HANA တွင် အကောင်အထည်ဖော်ရန် လိုအပ်ကြောင်း ကျွန်ုပ်တို့ သဘောပေါက်ပါသည်။ ၎င်းသည် ကျွန်ုပ်တို့အား များစွာမခြောက်လှန့်ခဲ့ပေ၊ ကျွန်ုပ်တို့သည် BO နှင့် ခွဲခြမ်းစိတ်ဖြာခြင်းဆိုင်ရာ အလားတူအတွေ့အကြုံရှိထားပြီးဖြစ်ပြီး ပေါင်းစပ်ထည့်သွင်းခြင်းမဟုတ်သော ညွှန်ကိန်းများကို မှန်ကန်စွာတွက်ချက်ထုတ်ပေးသည့် HANA တွင် အမြန်ပြပွဲများကို မည်သို့တည်ဆောက်ရမည်ကို သိရှိထားပါသည်။ အခုတော့ ကျန်တာအကုန်လုံးကို Tableau နဲ့ ချိန်ညှိဖို့ပဲကျန်တော့တယ်။

အဆင့် 2။ ကျွန်ုပ်တို့သည် ပြခန်းများကို ချိန်ညှိကာ၊ ရုပ်လုံးပေါ်လာခြင်းမရှိဘဲ၊ အရာအားလုံးသည် ပျံသန်းနေပါသည်။

ကျွန်ုပ်တို့သည် TABLEAU အတွက် လိုအပ်သော ဒေတာများကို အလျင်အမြန် ထုတ်လုပ်ပေးသည့် သီးခြား ပြပွဲအသစ်တစ်ခုကို ဖန်တီးခဲ့သည်။ ယေဘူယျအားဖြင့်၊ ကျွန်ုပ်တို့သည် ရလဒ်ကောင်းတစ်ခုရခဲ့သည်၊ ကျွန်ုပ်တို့သည် တစ်ပတ်အတွင်း ညွှန်ကိန်းအားလုံးကို ထုတ်ပေးရန်အတွက် အချိန်ကို 9-10 စက္ကန့်အထိ လျှော့ချခဲ့သည်။ ထို့အပြင် Tableau တွင် ဒက်ရှ်ဘုတ်၏ တုံ့ပြန်ချိန်သည် ပထမအဖွင့်တွင် 20-30 စက္ကန့်ဖြစ်ပြီး ယေဘုယျအားဖြင့် ကျွန်ုပ်တို့နှင့် ကိုက်ညီမည့် cache 10 မှ 12 ကြောင့် ကျွန်ုပ်တို့ ရိုးရိုးသားသား မျှော်လင့်ထားသည်။

ရလဒ်:

ပထမဆုံး ဒိုင်ခွက်ကိုဖွင့်ပါ- ၄-၅ မိနစ်
မည်သည့်ကလစ်: 3-4 မိနစ်
ဆိုင်မျက်နှာစာလုပ်ငန်းတွင် ဤကဲ့သို့ တိုးလာမည်ကို မည်သူမျှ မမျှော်လင့်ထားပေ။

အပိုင်း ၂။ Tableau သို့ ထိုးဆင်းပါ။

အဆင့် 1။ Tableau စွမ်းဆောင်ရည်ခွဲခြမ်းစိတ်ဖြာခြင်းနှင့် အမြန်ချိန်ညှိခြင်း။

Tableau ၏ အချိန်အများစုကို မည်သည့်နေရာတွင် သုံးစွဲသည်ကို ကျွန်ုပ်တို့ စတင်ခွဲခြမ်းစိတ်ဖြာခဲ့သည်။ ပြီးတော့ ဒီအတွက် တော်တော်ကောင်းတဲ့ ကိရိယာတွေ ရှိပါတယ်၊ အဲ့ဒါက Tableau ရဲ့ အားသာချက်တစ်ခုပါ။ ကျွန်ုပ်တို့ဖော်ထုတ်ခဲ့သည့် အဓိကပြဿနာမှာ Tableau တည်ဆောက်နေသည့် အလွန်ရှုပ်ထွေးသော SQL queries များဖြစ်သည်။ ၎င်းတို့သည် အဓိကအားဖြင့်-

- ဒေတာကူးပြောင်းမှု။ Tableau တွင် ဒေတာအတွဲများကို ကူးယူခြင်းအတွက် ကိရိယာများ မပါရှိသောကြောင့်၊ KPI အားလုံးကို အသေးစိတ်ကိုယ်စားပြုမှုဖြင့် ဒက်ရှ်ဘုတ်၏ ဘယ်ဘက်ခြမ်းကို တည်ဆောက်ရန်၊ case တစ်ခုကို အသုံးပြု၍ ဇယားတစ်ခုကို ဖန်တီးရမည်ဖြစ်သည်။ ဒေတာဘေ့စ်ရှိ SQL queries ၏အရွယ်အစားသည် စာလုံးရေ 120 သို့ရောက်ရှိခဲ့သည်။

- အချိန်ကာလရွေးချယ်မှု။ ဒေတာဘေ့စ်အဆင့်ရှိ ထိုသို့သောမေးခွန်းသည် လုပ်ဆောင်ရန်ထက် compile လုပ်ရန် အချိန်ပိုယူသည်-

အဲဒါတွေ။ တောင်းဆိုမှုလုပ်ဆောင်ခြင်း 12 စက္ကန့် + 5 စက္ကန့်လုပ်ဆောင်ခြင်း။

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

ဦးစွာ၊ ကျွန်ုပ်တို့သည် ပျံသန်းခြင်းတွင် အသွင်ကူးပြောင်းမှုကို ပြုလုပ်ခဲ့ပြီး၊ ဝီကီတွင်ဖော်ပြထားသော ဤချဉ်းကပ်မှုအရ VIEW တွက်ချက်မှု၏ နောက်ဆုံးအဆင့်တွင် ပြင်ပပါဝင်မှုအပြည့်ဖြင့် ပြုလုပ်ခဲ့သည်။ Transpose - Wikipedia၊ အခမဲ့စွယ်စုံကျမ်း и မူလတန်းမက်ထရစ် - Wikipedia၊ အခမဲ့စွယ်စုံကျမ်း.

ဆိုလိုသည်မှာ၊ ကျွန်ုပ်တို့သည် setting table - transposition matrix (21x21) ကိုပြုလုပ်ပြီး ညွှန်ကိန်းအားလုံးကို အတန်းအလိုက်ခွဲခြမ်းစိတ်ဖြာကာ လက်ခံရရှိခဲ့ပါသည်။

ဖြစ်ခဲ့သည်-


ဖြစ်လာသည်-


ဒေတာဘေ့စ် ကူးပြောင်းခြင်းအတွက် အချိန်ကုန်လုနီးပါး မရှိပါ။ ရက်သတ္တပတ်အတွက် အညွှန်းအားလုံးအတွက် တောင်းဆိုမှုကို 10 စက္ကန့်ခန့်အတွင်း ဆက်လက်လုပ်ဆောင်ခဲ့သည်။ သို့သော် အခြားတစ်ဖက်တွင်၊ တိကျသောညွှန်ပြချက်တစ်ခုအပေါ်အခြေခံ၍ ဒက်ရှ်ဘုတ်တစ်ခုတည်ဆောက်ရာတွင် ပြောင်းလွယ်ပြင်လွယ် ဆုံးရှုံးသွားပါသည်။ တိကျသောညွှန်ပြချက်တစ်ခု၏ ဒိုင်နမစ်နှင့်အသေးစိတ်ပိုင်းခြားမှုကိုပြသသည့် ဒက်ရှ်ဘုတ်၏ညာဘက်အခြမ်းအတွက်၊ ယခင်က display case သည် 1-3 စက္ကန့်အတွင်း အလုပ်လုပ်သောကြောင့်၊ တောင်းဆိုချက်သည် အညွှန်းတစ်ခုပေါ်တွင် အခြေခံထားပြီး ယခုအခါ ဒေတာဘေ့စ်သည် အညွှန်းအားလုံးကို အမြဲတမ်းရွေးချယ်ကာ ရလဒ်ကို Tableau သို့မပြန်မီ ရလဒ်ကို စစ်ထုတ်ခဲ့သည်။

ရလဒ်အနေဖြင့် ဒက်ရှ်ဘုတ်၏ အမြန်နှုန်းသည် ၃ ဆနီးပါး လျော့ကျသွားသည်။

ရလဒ်:

1. 5 စက္ကန့် - ဒက်ရှ်ဘုတ်များကို ခွဲခြမ်းစိတ်ဖြာခြင်း၊ ပုံဖော်ခြင်း
2. 15-20 စက္ကန့် - Tableau တွင်ကြိုတင်တွက်ချက်မှုများလုပ်ဆောင်ခြင်းဖြင့်မေးခွန်းများကိုပြုစုရန်ပြင်ဆင်မှု
3. 35-45 စက္ကန့် - Hana တွင် SQL queries များစုစည်းမှုနှင့် ၎င်းတို့၏ အပြိုင်-ဆင့်ကဲ လုပ်ဆောင်မှု
4. 5 စက္ကန့် – Tableau တွင် ရလဒ်များကို စီမံဆောင်ရွက်ခြင်း၊ အမျိုးအစားခွဲခြင်း၊ ပုံဖော်ခြင်းများကို ပြန်လည်တွက်ချက်ခြင်း။
5. ဟုတ်ပါတယ်၊ ထိုသို့သောရလဒ်များသည် လုပ်ငန်းနှင့်မကိုက်ညီဘဲ အကောင်းဆုံးဖြစ်အောင် ဆက်လက်လုပ်ဆောင်ပါသည်။

အဆင့် 2။ Tableau တွင် အနည်းဆုံးယုတ္တိ၊

10 စက္ကန့်ကြာလည်ပတ်သည့် စတိုးဆိုင်မျက်နှာစာတွင် စက္ကန့်များစွာကြာ တုံ့ပြန်မှုအချိန်တစ်ခုဖြင့် ဒက်ရှ်ဘုတ်တစ်ခု တည်ဆောက်ရန် မဖြစ်နိုင်ကြောင်း ကျွန်ုပ်တို့ နားလည်ထားပြီး လိုအပ်သော ဒက်ရှ်ဘုတ်အတွက် ဒေတာဘေ့စ်ဘက်ခြမ်းတွင် ဒေတာများဖန်တီးရန်အတွက် ရွေးချယ်စရာများကို ထည့်သွင်းစဉ်းစားထားပါသည်။ သို့သော် အထက်တွင်ဖော်ပြထားသော ကမ္ဘာလုံးဆိုင်ရာပြဿနာ - ပေါင်းထည့်ခြင်းမရှိသော ညွှန်ကိန်းများကို ကျွန်ုပ်တို့ကြုံတွေ့ခဲ့ရသည်။ စစ်ထုတ်မှုများ သို့မဟုတ် တူးဖော်မှုများကို ပြောင်းလဲသည့်အခါ၊ Tableau သည် မတူညီသော ထုတ်ကုန်ဆိုင်ရာ အဆင့်ဆင့်အတွက် ကြိုတင်ဒီဇိုင်းထုတ်ထားသော မတူညီသောစတိုးမျက်နှာစာများနှင့် အဆင့်များကြား လိုက်လျောညီထွေပြောင်းသွားကြောင်း မသေချာနိုင်ပါ။ (ဥပမာ၊ UTE မပါသော မေးခွန်းသုံးခု၊ UTE1 နှင့် UTE2 တို့သည် မတူညီသောရလဒ်များထုတ်ပေးသည်)။ ထို့ကြောင့်၊ ကျွန်ုပ်တို့သည် ဒက်ရှ်ဘုတ်ကို ရိုးရှင်းစေရန်၊ ဒက်ရှ်ဘုတ်ရှိ ထုတ်ကုန်အဆင့်ကို စွန့်လွှတ်ကာ ရိုးရှင်းသောဗားရှင်းတွင် မည်မျှမြန်နိုင်သည်ကို ကြည့်ရှုရန် ဆုံးဖြတ်ခဲ့သည်။

ထို့ကြောင့်၊ ဤနောက်ဆုံးအဆင့်တွင်၊ ကျွန်ုပ်တို့သည် KPIs အားလုံးကို transposed ပုံစံဖြင့် ထည့်သွင်းထားသော သီးခြားသိုလှောင်မှုတစ်ခုကို စုစည်းထားပါသည်။ ဒေတာဘေ့စ်ဘက်တွင်၊ ထိုသို့သောသိုလှောင်မှုတစ်ခုအတွက် တောင်းဆိုမှုမှန်သမျှကို 0,1 မှ 0,3 စက္ကန့်အတွင်း လုပ်ဆောင်ပါသည်။ ဒက်ရှ်ဘုတ်တွင် အောက်ပါရလဒ်များကို ကျွန်ုပ်တို့ ရရှိခဲ့ပါသည်။

ပထမအဖွင့်: 8-10 စက္ကန့်
မည်သည့်ကလစ်နှိပ်ပါ- 6-7 စက္ကန့်

Tableau အသုံးပြုသည့်အချိန်များ ပါဝင်သည်။

1. 0,3 စက္ကန့် - SQL queries များ၏ ဒက်ရှ်ဘုတ် ခွဲခြမ်းစိပ်ဖြာခြင်းနှင့် စုစည်းမှု
2. 1,5-3 စက္ကန့်။ - ပင်မအမြင်အာရုံအတွက် Hana ရှိ SQL မေးမြန်းမှုများကို လုပ်ဆောင်ခြင်း (အဆင့် 1 နှင့် အပြိုင်လုပ်ဆောင်သည်)
3. 1,5-2 စက္ကန့်။ - ပုံဖော်ခြင်း၊ မြင်ယောင်ခြင်းများကို ပြန်လည်တွက်ချက်ခြင်း။
4. 1,3 စက္ကန့် — သက်ဆိုင်ရာ စစ်ထုတ်မှုတန်ဖိုးများ (အမှတ်တံဆိပ်၊ ဌာနခွဲ၊ မြို့၊ စတိုး)၊ ခွဲခြမ်းစိတ်ဖြာမှုရလဒ်များရရှိရန် ထပ်လောင်း SQL queries များကို လုပ်ဆောင်ခြင်း

အကျဉ်းချုပ်ပြောရလျှင်

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

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

1. Tableau သည် များပြားသော ဒေတာများဖြင့် အလုပ်မလုပ်နိုင်ပါ။ မူရင်းဒေတာမော်ဒယ်တွင် သင့်တွင် ဒေတာ 10 GB ထက်ပိုသော (ခန့်မှန်းခြေအားဖြင့် သန်း 200 X 50 အတန်းများ) ရှိပါက ဒက်ရှ်ဘုတ်သည် ကလစ်တစ်ချက်စီအတွက် 10 စက္ကန့်မှ မိနစ်များစွာအထိ နှေးကွေးသွားမည်ဖြစ်သည်။ တိုက်ရိုက်ချိတ်ဆက်ခြင်းနှင့် ထုတ်ယူခြင်းနှစ်မျိုးလုံးကို ကျွန်ုပ်တို့ စမ်းသပ်ခဲ့သည်။ လည်ပတ်မှုအမြန်နှုန်းကို နှိုင်းယှဉ်နိုင်သည်။
2. သိုလှောင်မှုအများအပြား (ဒေတာအတွဲများ) ကို အသုံးပြုသည့်အခါ ကန့်သတ်ချက်။ စံနည်းလမ်းများကို အသုံးပြု၍ ဒေတာအတွဲများကြား ဆက်စပ်မှုကို ညွှန်ပြရန် နည်းလမ်းမရှိပါ။ ဒေတာအတွဲများကို ချိတ်ဆက်ရန် ဖြေရှင်းနည်းများကို အသုံးပြုပါက၊ ၎င်းသည် စွမ်းဆောင်ရည်ကို များစွာထိခိုက်စေမည်ဖြစ်သည်။ ကျွန်ုပ်တို့၏အခြေအနေတွင်၊ လိုအပ်သောကြည့်ရှုမှုအပိုင်းတစ်ခုစီတွင် ဒေတာကိုပုံဖော်ခြင်းနှင့် ယခင်ရွေးချယ်ထားသောစစ်ထုတ်မှုများကို ထိန်းသိမ်းထားစဉ် ဤရုပ်လုံးပေါ်လာသည့်ဒေတာအတွဲများပေါ်တွင် ခလုတ်များပြုလုပ်ခြင်းအား ကျွန်ုပ်တို့ထည့်သွင်းစဉ်းစားခဲ့သည် - ၎င်းသည် Tableau တွင်လုပ်ဆောင်ရန်မဖြစ်နိုင်တော့ပေ။
3. Tableau တွင် ဒိုင်းနမစ်ပါရာမီတာများကို ပြုလုပ်ရန် မဖြစ်နိုင်ပါ။ ထုတ်ယူမှုတစ်ခုတွင် ဒေတာအတွဲတစ်ခု သို့မဟုတ် တိုက်ရိုက်ချိတ်ဆက်မှုတစ်ခုအတွင်း ဒေတာအတွဲမှ အခြားရွေးချယ်မှုရလဒ် သို့မဟုတ် အခြား SQL မေးမြန်းမှု၏ရလဒ်၊ မူရင်းအသုံးပြုသူထည့်သွင်းမှု သို့မဟုတ် ကိန်းသေတစ်ခုမျှသာ ဒေတာအတွဲတစ်ခုကို စစ်ထုတ်ရန်အသုံးပြုသည့် ကန့်သတ်ဘောင်တစ်ခုကို သင်ဖြည့်၍မရပါ။
4. OLAP|PivotTable အစိတ်အပိုင်းများဖြင့် ဒက်ရှ်ဘုတ်တစ်ခု တည်ဆောက်ခြင်းနှင့် ဆက်စပ်သော ကန့်သတ်ချက်များ။
   MSTR၊ SAP SAC၊ SAP ခွဲခြမ်းစိတ်ဖြာမှုတွင် သင်သည် အစီရင်ခံစာတစ်ခုသို့ ဒေတာအတွဲတစ်ခုကို ထည့်ပါက၊ ၎င်းတွင်ရှိသော အရာအားလုံးကို ပုံသေအားဖြင့် တစ်ခုနှင့်တစ်ခု ဆက်စပ်နေပါသည်။ Tableau တွင် ၎င်းမပါဝင်ပါ၊ ချိတ်ဆက်မှုကို ကိုယ်တိုင်ပြင်ဆင်ရပါမည်။ ၎င်းသည် ပိုမိုပြောင်းလွယ်ပြင်လွယ်ဖြစ်နိုင်သော်လည်း ကျွန်ုပ်တို့၏ ဒက်ရှ်ဘုတ်များအားလုံးအတွက် ၎င်းသည် အစိတ်အပိုင်းများအတွက် မဖြစ်မနေလိုအပ်ချက်ဖြစ်သည် - ထို့ကြောင့် ၎င်းသည် အပိုဆောင်းလုပ်သားစရိတ်ဖြစ်သည်။ ထို့အပြင်၊ ဥပမာအားဖြင့်၊ ဒေသတစ်ခုအား စစ်ထုတ်သည့်အခါ၊ မြို့များစာရင်းသည် ဤဒေသရှိမြို့များသာ ကန့်သတ်ထားသောကြောင့်၊ သင်သည် ဒေတာဘေ့စ် သို့မဟုတ် Extract သို့ သိသိသာသာ နှေးကွေးသွားစေသည့် ဆက်တိုက်မေးမြန်းချက်များနှင့် ချက်ချင်းအဆုံးသတ်သွားမည်ဖြစ်သည်။ ဒက်ရှ်ဘုတ်
5. လုပ်ဆောင်ချက်များတွင် ကန့်သတ်ချက်များ။ အစုလိုက်အပြုံလိုက် အသွင်ပြောင်းခြင်းများ ထုတ်ယူခြင်း သို့မဟုတ် အထူးသဖြင့် Live-connecta မှ ဒေတာအတွဲပေါ်တွင် သော်လည်းကောင်း လုပ်ဆောင်၍မရပါ။ ၎င်းကို Tableau Prep မှတစ်ဆင့် လုပ်ဆောင်နိုင်သော်လည်း ၎င်းသည် အပိုအလုပ်နှင့် သင်ယူထိန်းသိမ်းရန် အခြားကိရိယာတစ်ခုဖြစ်သည်။ ဥပမာအားဖြင့်၊ သင်သည် ဒေတာကို လွှဲပြောင်းခြင်း သို့မဟုတ် ၎င်းနှင့် ၎င်းကို ချိတ်ဆက်၍မရပါ။ ကော်လံတစ်ခုစီ သို့မဟုတ် အကွက်များပေါ်တွင် အသွင်ပြောင်းခြင်းမှတစ်ဆင့် ပိတ်ထားသည်ကို case သို့မဟုတ် if ဖြင့် ရွေးချယ်ရမည်ဖြစ်ပြီး၊ ၎င်းသည် အလွန်ရှုပ်ထွေးသော SQL queries များကို ထုတ်ပေးသည်၊ ၎င်းသည် ဒေတာဘေ့စ်မှ query text ကို ပြုစုရာတွင် အချိန်အများစုကို ကုန်ဆုံးစေသည်။ ပိုမိုရှုပ်ထွေးသောသိုလှောင်မှု၊ ထပ်လောင်းဒေါင်းလုဒ်များနှင့် အသွင်ပြောင်းမှုများဆီသို့ ဦးတည်သွားစေသည့် ဤကိရိယာ၏ ပျော့ပြောင်းမှုကို ပြခန်းအဆင့်တွင် ဖြေရှင်းရမည်ဖြစ်သည်။

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

ယခု ကျွန်ုပ်တို့သည် အခြားကိရိယာတစ်ခုတွင် အလားတူ ဒက်ရှ်ဘုတ်တစ်ခုကို တက်ကြွစွာ တီထွင်နေပြီး တစ်ချိန်တည်းတွင် ၎င်းကို ပိုမိုရိုးရှင်းစေရန်အတွက် Tableau ရှိ ဒက်ရှ်ဘုတ်ဗိသုကာကို ပြန်လည်ပြင်ဆင်ရန် ကြိုးစားနေပါသည်။ အသိုင်းအဝိုင်းက စိတ်ဝင်စားတယ်ဆိုရင် ရလဒ်တွေအကြောင်း ပြောပြမယ်။

ကျွန်ုပ်တို့တွင် လက်လီဆိုင်ထက် ဒေတာများစွာရှိသည့် ဝဘ်ဆိုဒ်တစ်ခုရှိသောကြောင့် ကျွန်ုပ်တို့တွင် ဤကဲ့သို့သော များပြားလှသော ဒေတာပမာဏများပေါ်တွင် လျင်မြန်သော ဒိုင်ခွက်များကို သင်မည်သို့ အမြန်တည်ဆောက်နိုင်ပုံနှင့်ပတ်သက်၍ သင်၏အကြံဥာဏ်များ သို့မဟုတ် အကြံဉာဏ်များကို ကျွန်ုပ်တို့ စောင့်မျှော်နေပါသည်။

source: www.habr.com