AI agent မမိတ်ဆက်ခင်၊ ရိုးစင်းတဲ့ မေးခွန်းတစ်ခု အရင်မေးပါ - သင့် customer data မှာ version ဘယ်နှစ်ခု ရှိလဲ

ရန်ကုန်က စက်ရုံတစ်ခုရဲ့ sales vice president က AI assistant သရုပ်ပြ အစည်းအဝေးမှာ အလွန် ရိုးရှင်းတဲ့ မေးခွန်းတစ်ခု မေးလိုက်တယ် - "မနှစ်က ကျွန်တော်တို့ ABC Group နဲ့ ဘယ်လောက် အရောင်း လုပ်ခဲ့လဲ"

System က ဂဏန်းတစ်ခု ပြန်ဖြေတယ်။ VP က မျက်မှောင်ကြုတ်တယ် - "မဟုတ်ဘူးလေ၊ ဒီဂဏန်းက နည်းလွန်းတယ်။"

နောက်မှ စစ်ကြည့်တော့၊ ERP ထဲမှာ "ABC Group" "ABC Group Co., Ltd." "ABC" ဆိုပြီး customer သုံးခု ရှိနေတယ်၊ order တွေ code သုံးခုအောက်မှာ ကွဲနေတယ်။ AI က မမှားဘူး၊ သူက "ABC Group" ဆိုတဲ့ တစ်ခုရဲ့ ပမာဏကိုသာ ရိုးရိုးသားသား ပေါင်းပြောပြတာ။ မှားတာက data ပါ။

ဒီ သရုပ်ပြပွဲရဲ့ ကောက်ချက်က "AI မရင့်ကျက်သေးဘူး" ဆိုတာပါ။ ဒီကောက်ချက် အလွန်မြန်မြန် ချလိုက်တာလို့ ကျွန်တော် ထင်ပါတယ်။

ဖြစ်ရပ် နောက်ခံ

2026 ခုနှစ်မှာ ကမ္ဘာလုံးဆိုင်ရာ C-level executive ၁,၀၀၀ ကို မေးမြန်းတဲ့ စစ်တမ်းတစ်ခုက စိတ်ဝင်စားစရာ ဂဏန်းတစ်ခု ပေးလိုက်တယ် - data management ဟာ AI အကောင်အထည်ဖော်ရာမှာ အကြီးဆုံး စိန်ခေါ်မှုဖြစ်ပြီး ၅၁ ရာခိုင်နှုန်း ရှိကာ cost နဲ့ talent ကို ကျော်လွန်သွားပါပြီ။

ဒါက လွန်ခဲ့တဲ့ နှစ်နှစ်ရဲ့ narrative နဲ့ လုံးဝ မတူပါ။ 2023, 2024 မှာ လူတိုင်း စိုးရိမ်ခဲ့တာက "AI လုပ်တတ်တဲ့ လူ ရှာမတွေ့" "GPU အရမ်း စျေးကြီး" ပါ။ နှစ်နှစ် ကုန်သွားတော့ model က စျေးပေါလာ၊ tool က သုံးရ ပိုကောင်းလာ၊ ပြီးတော့ လူတိုင်း တွေ့ရှိလိုက်တာက ပိတ်နေတဲ့ နေရာက ပိုရှေ့မှာ ဖြစ်နေတယ် - data ထုတ်လို့ မရ၊ တိုက်လို့ မရ၊ တာဝန်ခံ ဝံ့တဲ့ လူ မရှိ။

အဲဒီ ကာလမှာပဲ၊ နောက်ပြောင်းလဲမှုတစ်ခုက ဒီကိစ္စရဲ့ ဆိုးရွားမှုကို အဆင့်တစ်ဆင့် တွန်းတင်လိုက်တယ် - AI က "မေးခွန်း ဖြေ" ကနေ "လုပ်ဆောင်ချက် လုပ်" အဖြစ် ပြောင်းသွားတယ်။

ဒါက အနှစ်သာရ ကွာခြားချက်ပါ။ အရင်က AI က summary တစ်ခု ပေးရင်၊ မှားရင် သင်ကိုယ်တိုင် တွေ့ပါလိမ့်မယ်။ အခု agent က CRM မှာ order ဖွင့်၊ ERP မှာ customer တည်ဆောက်၊ customer ဆီ email ပို့ - မှားရင် ဖြစ်ပြီးသား ကိစ္စဖြစ်ပြီး ဖြစ်ပြီးမှသာ ကုစားနိုင်ပါတယ်။

အဓိက အချက်များ

agent ကို လုံခြုံစွာ အလုပ်ခန့်ဖို့ ရှောင်လွှဲမရတဲ့ data အခြေခံ လုပ်ငန်း သုံးခု ရှိပါတယ် -

• master data management (MDM) - customer, product, supplier တစ်ခုတည်းက system အားလုံးမှာ တစ်ခုတည်း ဖြစ်စေတာ။ ဒါက အခြေခံဆုံးဖြစ်ပြီး အကျော်ခံရဆုံးလည်း ဖြစ်တယ်။
• entity resolution - "John Smith" "Mr. John Smith" "SMITH JOHN" က တစ်ယောက်တည်း ဟုတ်မဟုတ် ဆုံးဖြတ်၊ ဘာလို့လဲ ပြောနိုင်ရမယ်။ explainability က ကြီးကြပ်ခံ industry မှာ bonus မဟုတ်ဘဲ မဖြစ်မနေ ဖြစ်တယ်။
• data lineage နဲ့ access governance - ဒီ data က ဘယ်ကလာ၊ ဘယ်သူ ထိ၊ agent က ဘယ် field မြင်နိုင်လဲ။ ဒီ layer မရှိရင် ကိစ္စတက်တဲ့အခါ ရှာဖွေဖို့တောင် မရနိုင်ပါ။

market သက်ရောက်မှု ဆန်းစစ်ချက်

Myanmar သုံးစွဲသူများအတွက် - ရိုးရိုး ရုံးဝန်ထမ်း အတွက် အတိုက်ရိုက်ဆုံး ခံစားချက်က AI assistant "အလွန် ယုံကြည်စိတ်ချစွာ ပြောပေမဲ့ အဖြေ မှား" တာပါ။ လူအများစုရဲ့ တုံ့ပြန်မှုက မယုံ၊ ပြီးတော့ မသုံးတော့တာပါ။ ဒါက အမှန်တကယ် ဆင်ခြင်တုံတရားရှိတဲ့ တုံ့ပြန်မှုပါ - ဂဏန်း လုပ်ကြံတဲ့ assistant က assistant မရှိတာထက် ပိုအန္တရာယ် ရှိတယ်။

သင့်ကုမ္ပဏီရဲ့ AI assistant ယုံလို့ ရမရ ဆုံးဖြတ်ဖို့ အလွန် ရိုးစင်းတဲ့ test တစ်ခု ရှိတယ် - သင်ကိုယ်တိုင် အဖြေ သိထားတဲ့ မေးခွန်းတစ်ခု မေးကြည့်ပါ။ ဒီလောက်တောင် မှားရင်၊ သင်မသိတဲ့ မေးခွန်း ဖြေတဲ့အခါ ဘာနဲ့ ယုံမလဲ။

enterprise application အတွက် - Myanmar enterprise တွေရဲ့ data အခြေအနေမှာ ထူးခြားတဲ့ ပြဿနာ အနည်းငယ် ရှိပါတယ်။

ပထမက system မျိုးဆက် ထပ်နေခြင်းပါ။ ကုမ္ပဏီ အများအပြားမှာ တစ်ပြိုင်နက် ၁၅ နှစ် run ခဲ့တဲ့ ERP, လွန်ခဲ့တဲ့ ငါးနှစ်က မိတ်ဆက်တဲ့ CRM, မနှစ်က တင်တဲ့ cloud tool ရှိပြီး၊ system သုံးခုက "customer" ကို လုံးဝ မတူတဲ့ အဓိပ္ပာယ်နဲ့ သတ်မှတ်တယ် - ERP က tax ID သုံး၊ CRM က company name သုံး၊ marketing tool က email သုံး။ လူတစ်ယောက် ပေါင်းစပ်ဖို့ ကြားထဲက mapping rule ကို ဘယ်သူမှ ရှင်းရှင်း မပြောနိုင်ဘူး။

ဒုတိယက group subsidiary တွေ ကိုယ်စီ လုပ်နေခြင်းပါ။ customer တစ်ဦးတည်းက subsidiary သုံးခုမှာ account သီးသန့် ဖွင့်၊ ဈေး ကိုယ်စီ ညှိ၊ group level မှာ "ဒီ customer စုစုပေါင်း ဘယ်လောက် ပံ့ပိုးလဲ" လုံးဝ မမြင်ရ။ ဒီကိစ္စက AI မမိတ်ဆက်ခင် report မလှတာလောက်ပဲ ဖြစ်ပြီး၊ မိတ်ဆက်ပြီးရင် agent က ဈေးမှား ကို့တ်ပေးတဲ့ ကိစ္စ ဖြစ်လာပါလိမ့်မယ်။

တတိယက နာမည် variant ပြဿနာပါ။ full-width/half-width, "Co., Ltd." ပါမပါ, English name လား local name လား, "Myanmar" ထည့်မထည့် - English world မှာ မရှိတဲ့ ဒီပြဿနာတွေ Myanmar မှာ နေ့စဉ်ပါ။ ဒါ ဥရောပ/အမေရိကန် entity resolution tool ကို တိုက်ရိုက် သုံးရင် အကျိုးက မကြာခဏ မျှော်လင့်သလို မဖြစ်တဲ့ အကြောင်းရင်းလည်း ဖြစ်လို့၊ ကိုယ့် data နဲ့ လက်တွေ့ စမ်းသပ်ဖို့ မဖြစ်မနေ လိုပါတယ်။

ဒီ layer ကို ကိုင်တွယ်တဲ့ tool တွေ market မှာ များများ ရှိပါတယ် - Reltio က real-time နဲ့ agentic AI လမ်းကြောင်း၊ Semarchy က DataOps discipline ကို အဓိကထား၊ Profisee က Microsoft ecosystem ကို အနက်ရှိုင်း ချည်နှောင်၊ CluedIn က graph database သုံးပြီး pay-as-you-go နဲ့ အဆင့်နိမ့်။ matching ကိုယ်တိုင်ကို အထူးလုပ်တာကတော့ Senzing နဲ့ Data Ladder ရှိပါတယ်။ ရွေးချယ်ရာမှာ ပထမ မေးခွန်းက function ယှဉ်တာ မဟုတ်ဘဲ "ကျွန်တော့် လက်ရှိ data stack နဲ့ ကိုက်မကိုက်" ပါ။

developer အတွက် - enterprise internal AI agent လုပ်နေရင်၊ ကျွန်တော် ထင်တဲ့ မဖြစ်မနေ လိုက်နာရမယ့် ဒီဇိုင်း ဥပဒေသ တစ်ခု ရှိတယ် - agent ဖတ်တဲ့ data တိုင်းက "ဒါ ဘယ်ကလာလဲ" ကို ဖြေနိုင်ရမယ်။

လက်တွေ့မှာ ဒါက အကြောင်းအရာ အနည်းငယ် ဆိုလိုတယ်။ tool က model ဆီ ပြန်ပေးတဲ့ content မှာ source mark ပါရမယ်။ agent ရဲ့ write action တိုင်းက ပြည့်စုံတဲ့ trail ချန်ရမယ်။ ပြီးတော့ အရေးအကြီးဆုံး - data conflict ဖြစ်တဲ့အခါ (customer တစ်ဦးတည်းမှာ credit limit နှစ်ခု ကွဲနေ) agent က ကိုယ်တိုင် တစ်ခု မရွေးဘဲ လူကို ရပ်မေးသင့်တယ်။

ဒီ design က agent ကို "နည်းနည်း ထုံသလို" ဖြစ်စေမယ်၊ ဘာလို့လဲဆိုတော့ သူက "ကွဲပြားတဲ့ data နှစ်ခု တွေ့တယ်၊ အတည်ပြုပေးပါ" လို့ မကြာခဏ ပြောမှာမို့။ ဒါပေမဲ့ ဒီ ထုံမှုက မှန်တဲ့ ထုံမှုပါ။ ကိုယ်တိုင် ခန့်မှန်းတဲ့ agent ကသာ တကယ့် risk ဖြစ်တယ်။

အနာဂတ် ဖွံ့ဖြိုးမှု လမ်းကြောင်း

လမ်းကြောင်း နှစ်ခု တွေ့ရတယ်။

ပထမ၊ MDM လို မူလက IT internal ကိစ္စလို့ ရှုမြင်ခံရတာက AI ရဲ့ ကြိုတင်လိုအပ်ချက် ဖြစ်လာနေတယ်။ အရင်က MDM project အခက်ဆုံးက မမြင်ရတဲ့ အရာအတွက် ဘာလို့ ပိုက်ဆံ သုံးရမလဲ boss ကို သဘောပေါက်စေဖို့ပါ။ အခု ပြောပုံက "agent မှားတဲ့ data ကိုင်ရင် ကိစ္စတက်မယ်" ဖြစ်လာပြီး၊ ဒီ အကြောင်းပြချက်က အများကြီး ပိုအားရှိပါတယ်။

ဒုတိယ၊ tool ကိုယ်တိုင်က "agent အတွက် governed context ပေးတာ" ဆီ ပြောင်းနေတယ်။ ရိုးရာ MDM ရဲ့ output က လူကြည့်ဖို့ golden record ဖြစ်ပြီး၊ အခု output က agent ခေါ်ဖို့ data service ပါ။ ဒီ ပြောင်းလဲမှုက ဒီ market ကို ပြန်လည် သတ်မှတ်မယ်၊ batch processing ပဲ လုပ်တဲ့ tool အဟောင်း အုပ်စုကိုလည်း ဖယ်ရှားပစ်မယ်။

ဒါပေမဲ့ ရေအေးလေး လောင်းမယ် - tool က governance ပြဿနာ မဖြေရှင်းနိုင်ပါ။ "customer data ကို ဘယ်သူ့ version အတိုင်း အခြေခံ" "field definition ဘယ်သူ ဆုံးဖြတ်" "မှားရင် ဘယ်သူ တာဝန်ယူ" - ဒီ သုံးခုက organizational politics ဖြစ်ပြီး software function မဟုတ်ပါ။ platform ဝယ်ပြီး အာဏာရှိတဲ့ data governance role မရှိရင် project က အဆုံးမရှိတဲ့ cross-department coordination meeting ဖြစ်သွားမယ်။ ဒါ MDM project ကျရှုံးတဲ့ အဖြစ်များဆုံး အကြောင်းရင်းဖြစ်ပြီး နှစ်ပေါင်း နှစ်ဆယ် မပြောင်းပါ။

TheAI Academy အနှစ်ချုပ်နဲ့ သုံးသပ်ချက်

အစပိုင်းက စက်ရုံ ဥပမာဆီ ပြန်လာမယ်။ သူတို့ နောက်ပိုင်း လုပ်တာ အလွန်ရိုးရှင်းတယ် - ခြောက်ပတ် သုံးပြီး ERP ထဲက customer master ကို တစ်ခါ dedup နဲ့ normalize လုပ်၊ "tax ID က တစ်ခုတည်းသော identifier" ဆိုတဲ့ rule ချ၊ ပြီးတော့ finance department ကို customer master ရဲ့ ပိုင်ရှင်အဖြစ် သတ်မှတ်။

နောက်တစ်ခါ သရုပ်ပြတော့၊ ဂဏန်း မှန်သွားတယ်။

သုံးသပ်ချက် - AI project ရဲ့ အောင်ရှုံးဟာ ၈၀ ရာခိုင်နှုန်း model မဖွင့်ခင်မှာ ဆုံးဖြတ်ခံရတယ်။ သင့် customer data မှာ version တစ်ခုတည်းသာ ရှိကြောင်း အရင် သေချာစေ၊ ပြီးမှ ဘယ် model သုံးမလဲ ပြောပါ။

Myanmar စာဖတ်သူများအတွက် တိကျတဲ့ အကြံ - နောက်ပတ်ကတည်းက စလုပ်နိုင်တဲ့ သုံးခု ပြောမယ် -

ပထမ၊ "ကိုယ့်မေးကိုယ်ဖြေ test" တစ်ခါ လုပ်ပါ။ သင်ကိုယ်တိုင် အဖြေမှန် သိတဲ့ operational မေးခွန်း ငါးခု ရွေးပြီး ကုမ္ပဏီ AI tool ဒါမှမဟုတ် database ကို တိုက်ရိုက် မေး/စစ်။ မှားတဲ့ အဲဒီ မေးခွန်းတွေက သင့်ရဲ့ data ပေါက်ပြဲပါ။ ဒီကိစ္စက budget မလို၊ နေ့လယ်ခင်းတစ်ခုနဲ့ ပြီးနိုင်ပါတယ်။

ဒုတိယ၊ "single source of truth" ကို အရင် သတ်မှတ်၊ ပြီးမှ tool ဝယ်တာ ပြော။ customer data ကို ERP အခြေခံလား CRM အခြေခံလား။ product data ကို ဘယ်သူ့ အခြေခံလား။ ဒီ ဆုံးဖြတ်ချက်က ပိုက်ဆံ မကုန်ပေမဲ့ နောက်က အားလုံးရဲ့ ကြိုတင်လိုအပ်ချက်ပါ။ ဆုံးဖြတ်လို့ မရရင် ဘာ system ဝယ်ဝယ် အသုံးမဝင်ပါ။

တတိယ၊ scope ကို သေး။ "ကုမ္ပဏီတစ်ခုလုံး data governance" project မဖွင့်ပါနဲ့၊ အဲဒါ သုံးနှစ်ကြာပြီး ပြီးမြောက်ဖို့ မသေချာပါ။ agent အသုံးအများဆုံး data domain (များသောအားဖြင့် customer) တစ်ခု ရွေး၊ သုံးလနဲ့ သန့်ရှင်းတဲ့ version ထုတ်၊ တန်ဖိုးကို သက်သေပြ၊ ပြီးမှ ချဲ့။

နောက်ထပ်ဖတ်ရန် - site ပေါ်က AI agent observability နဲ့ governance က agent တင်ပြီးနောက် ဘယ်လို monitor မလဲ ပြောပြီး၊ ဒီဆောင်းပါးရဲ့ "တင်ခင်" နဲ့ ကွက်တိ ဆက်စပ်ပါတယ်။ AI ထုတ်တဲ့ code ကို ဘယ်သူ verify မလဲ က တူညီတဲ့ logic ကို development ဘက်မှာ ပြောတဲ့ version ပါ။

အချက်အလက် ရင်းမြစ်

• McKinsey: The State of AI (Global Survey)
• Gartner Magic Quadrant for Master Data Management Solutions (vendor website များ ပြန်လည်ဖော်ပြ)
• Semarchy တရားဝင် survey ရှင်းလင်းချက်

public information အရ စုစည်းထားပြီး၊ survey ဂဏန်း အသီးသီးက မူရင်း report ကို အခြေခံပါတယ်။