Corporate → BI → AI: ทำไมกระดุมเม็ดแรกของ AI Transformation คือ Data

เวลาเข้าไปคุยกับองค์กร ผมมักได้ยินอยู่สองประโยคครับ

ประโยคแรกคือ
“อยากทำ Dashboard ให้ผู้บริหารเห็นข้อมูลได้ง่ายขึ้น”

อีกประโยคที่ช่วงหลังได้ยินบ่อยขึ้นมากคือ
“อยากเอา AI มาใช้กับบริษัท”

ฟังดูเหมือนเป็นคนละ Project กัน เรื่องหนึ่งคือ BI อีกเรื่องคือ AI

แต่พอคุยลงไปอีกหน่อย เช่น Revenue ที่ผู้บริหารดูทุกเดือนมาจากระบบไหน, Customer คนเดียวกันมีรหัสอยู่กี่ชุด, Stock Available นับสินค้าระหว่างทางด้วยหรือไม่ หรือเวลาฝ่ายขายกับบัญชีพูดคำว่า “ยอดขาย” หมายถึงตัวเลขเดียวกันหรือเปล่า

สุดท้ายบทสนทนามักย้อนกลับมาที่เรื่องเดิมครับ

Data

ไม่ใช่ว่าบริษัทไม่มีข้อมูลนะครับ หลายบริษัทมีข้อมูลเยอะมากด้วยซ้ำ ทั้ง ERP, CRM, POS, Excel, Google Sheets, ระบบโรงงาน หรือ Dashboard ที่ทำไว้หลายปีแล้ว

ปัญหาคือข้อมูลเหล่านั้นอาจยังไม่ได้ถูกจัดให้อยู่ในสภาพที่ คนในองค์กรเข้าใจตรงกัน และ AI สามารถเข้าใจต่อได้อย่างถูกต้อง

ตรงนี้เป็นที่มาของ Framework ที่เราใช้เวลาคุยกับลูกค้าที่ Data Story ซึ่งเราเรียกว่า CBA

C — Corporate
B — Business Intelligence
A — Artificial Intelligence

มันไม่ได้ถูกออกแบบมาให้เป็นคำศัพท์ใหม่ที่ซับซ้อนอะไรครับ เราใช้มันเพื่อช่วยอธิบายเรื่องง่าย ๆ ว่า ก่อนจะพาองค์กรไปถึง AI เราต้องจัดกระดุมเม็ดแรกของ Data ให้ถูกก่อน

C — Corporate: ก่อนใช้ Data ต้องรู้ก่อนว่า Data ของเราหมายถึงอะไร

คำว่า Corporate ใน CBA ไม่ได้หมายถึงการสร้าง Data Warehouse ขนาดใหญ่ก่อนทุกครั้ง

สิ่งที่เราสนใจมากกว่าคือ

ข้อมูลที่สำคัญต่อธุรกิจขององค์กรมีอยู่ที่ไหน ใครเป็นเจ้าของ และทุกคนเข้าใจมันเหมือนกันหรือไม่

ตัวอย่างง่าย ๆ คือคำว่า Revenue

ฝ่ายหนึ่งอาจมองจาก Sales Order
อีกฝ่ายมองจาก Invoice ที่ Post แล้ว
Finance อาจดูตามหลักการรับรู้รายได้
ส่วน Dashboard อีกตัวอาจดึงจาก POS

ทุกตัวเลขอาจ “ถูก” ตามบริบทของมัน แต่ถ้าไม่มีการนิยามว่าในการตัดสินใจเรื่องนี้ Revenue หมายถึงตัวไหน บริษัทก็จะมีความจริงหลายชุด

ตอนมีแต่คนใช้ข้อมูล ปัญหานี้อาจจบด้วยการโทรถามกันว่า

“เลขตัวไหนถูกครับ?”

แต่ถ้า AI เข้ามาใช้ข้อมูลด้วย ปัญหาเดิมจะเร็วขึ้นมาก เพราะ AI สามารถ Query วิเคราะห์ และสร้างคำตอบได้ภายในไม่กี่วินาที

Microsoft อธิบายทิศทางนี้ไว้ค่อนข้างตรงว่า เมื่อ Model AI เริ่มเข้าถึงได้ทั่วไปมากขึ้น ความแตกต่างขององค์กรจะอยู่ที่การนำ Model เหล่านั้นมาเชื่อมกับ ข้อมูล ความเชี่ยวชาญ และ Business Context ที่เป็นขององค์กรเอง แหล่งอ้างอิง

Databricks ก็เดินไปในทิศทางเดียวกัน โดยเพิ่มชั้นสำหรับเก็บนิยามทางธุรกิจ เช่น คำศัพท์ Entity และ Acronym ของบริษัท เพื่อให้ Agent ใช้ “ความหมายที่องค์กรกำหนด” เป็น Context ในการ Reason แทนการเดาจาก Schema เพียงอย่างเดียว แหล่งอ้างอิง

ดังนั้น Corporate Data Foundation ในมุมของผมจึงมีเรื่องพื้นฐานประมาณนี้:

Source → Definition → Owner → Relationship → Business Rule → Permission → Quality → Freshness

ไม่จำเป็นต้องทำทุกอย่างทั่วทั้งบริษัทพร้อมกัน

แต่ Data ที่เกี่ยวข้องกับเรื่องที่เรากำลังจะตัดสินใจ ต้องตอบคำถามเหล่านี้ให้ได้

B — Business Intelligence: ทำให้คนเห็นธุรกิจผ่านข้อมูลชุดเดียวกัน

เมื่อ Data เริ่มมีความหมายตรงกัน ชั้นถัดไปคือ BI

หลายปีที่ผ่านมาเวลาเราพูดถึง BI เรามักนึกถึง Dashboard ก่อน ซึ่งไม่ได้ผิดครับ Dashboard ยังสำคัญมาก

แต่ผมคิดว่าเป้าหมายจริง ๆ ของ BI ไม่ใช่การมีกราฟสวยขึ้น

เป้าหมายคือทำให้คนในองค์กรสามารถ เห็นสถานการณ์ เข้าใจสาเหตุ และตัดสินใจจากข้อมูลชุดเดียวกัน

เช่น ผู้บริหารเห็นว่าสินค้ากลุ่มหนึ่งกำลังจะ Stock-out

คำถามถัดไปไม่ใช่แค่ว่า

“เหลือกี่ชิ้น?”

แต่เป็น

“เกิดจากอะไร?”
“สาขาไหนเสี่ยงที่สุด?”
“ของกำลังมาไหม?”
“ย้ายจากสาขาอื่นได้หรือเปล่า?”
“ถ้าไม่ทำอะไร เราจะเสียยอดขายเท่าไร?”

ตรงนี้คือช่วงที่ Data เริ่มเปลี่ยนจาก Record ไปเป็น Business Insight

และสิ่งที่น่าสนใจมากในปีนี้คือ Platform BI รายใหญ่กำลังเอา Semantic Layer ซึ่งเดิมใช้ทำให้ Dashboard มีนิยาม Metric ตรงกัน ไปใช้เป็นฐานของ AI ด้วย

Google Cloud ระบุว่า Looker ใช้ Semantic Layer เป็น Trusted Foundation สำหรับทั้งผู้ใช้และ AI Agent โดย Metric, Business Logic และ Governance ชุดเดียวสามารถใช้กับ Dashboard และ Agent ได้ แหล่งอ้างอิง

Databricks ก็ประกาศ Business Semantics ในลักษณะใกล้กัน คือกำหนด Metric, Dimension และ Rule ครั้งเดียวที่ Data Layer แล้วให้ Dashboard, SQL, Notebook และ AI Agent ใช้นิยามเดียวกัน แหล่งอ้างอิง

ผมคิดว่านี่เป็นประเด็นสำคัญมาก

เพราะในอดีตเราอาจสร้าง BI ชุดหนึ่ง แล้ววันหนึ่งพอองค์กรอยากทำ AI ก็เริ่มทำ Data Preparation ใหม่อีกรอบ

แต่ในอนาคต สิ่งที่ควรเกิดคือ

Data ชุดเดียวควรสามารถอธิบายธุรกิจให้คนเห็นผ่าน BI และอธิบายธุรกิจให้ AI เข้าใจได้ด้วย

A — Artificial Intelligence: AI ต้องการมากกว่าแค่ Connection เข้า Database

พอพูดถึง AI ในองค์กร คำถามแรกมักกลายเป็นเรื่อง Model

ใช้ ChatGPT หรือ Gemini?
ใช้ Model ใหญ่หรือ Model เล็ก?
ทำ RAG หรือ Agent?
ต่อ MCP ไหม?

คำถามเหล่านี้สำคัญ แต่ผมมองว่ายังไม่ใช่คำถามแรก

คำถามแรกจริง ๆ คือ

AI ตัวนี้จะใช้ข้อมูลอะไร และมันเข้าใจข้อมูลนั้นเหมือนที่ธุรกิจเข้าใจหรือยัง

Google Cloud อธิบายปัญหานี้ไว้ชัดว่า LLM อาจอ่านข้อความได้ดี แต่เมื่อต้องเจอกับ Enterprise Database ดิบ โมเดลอาจต้องเดาความสัมพันธ์ของ Schema ซึ่งนำไปสู่ Query ที่คาดเดาไม่ได้ Metric ที่ไม่สอดคล้องกัน และคำตอบที่ไม่น่าเชื่อถือ จึงต้องมี Governed Semantic Layer อยู่ระหว่างข้อมูลดิบกับ AI แหล่งอ้างอิง

Snowflake ก็ให้ภาพคล้ายกัน โดยวาง Semantic View เป็น “contract” สำหรับคำตอบของ Agent เพื่อให้ Business Definition, RBAC และ Auditability อยู่ในระบบเดียวกัน แหล่งอ้างอิง

ลองกลับมาที่เรื่อง Stock เมื่อสักครู่ครับ

ถ้า AI จะช่วยวิเคราะห์ Stock-out จริง ๆ มันต้องรู้มากกว่าเลข Inventory

มันอาจต้องเข้าใจว่า

• Available Stock คำนวณอย่างไร

• Safety Stock ของแต่ละ SKU เท่าไร

• Lead Time Supplier ใช้ค่าไหน

• Purchase Order ไหน Confirm แล้ว

• สาขาไหนสามารถ Transfer ของให้กันได้

• Margin ของสินค้านี้เท่าไร

• User คนนี้มีสิทธิ์ดู Cost หรือไม่

• AI มีสิทธิ์แค่แนะนำ หรือสร้าง Transfer Order ได้เลย

นี่คือจุดที่ AI เริ่มต้องการ Business Context

และยิ่ง Agent สามารถลงมือทำ Action ได้ เรื่องนี้ก็ยิ่งสำคัญขึ้น

Google Cloud เรียกแนวทางใหม่นี้ว่า Agentic BI ซึ่ง Agent ไม่ได้เพียงตอบคำถาม แต่สามารถ Trigger downstream action โดยอิงกับ Semantic Layer และ Governance ขององค์กรได้ แหล่งอ้างอิง

ลองมองเรื่องเดียวผ่าน CBA

เพื่อให้เห็นภาพ ผมขอยกตัวอย่าง Inventory แบบเดียวตั้งแต่ต้นจนจบ

C — Corporate

เราจัดให้รู้ว่า

Product คืออะไร
SKU ไหนซ้ำกัน
Stock แต่ละ Location มาจากไหน
Sales ใช้ Transaction ใด
Available Stock นิยามอย่างไร
Lead Time มาจากไหน
ใครเป็น Data Owner

ข้อมูลเริ่มมีภาษาเดียวกัน

B — Business Intelligence

จาก Data เหล่านั้น เราสามารถสร้าง

ABC / XYZ
Stock Aging
Slow-moving
Stock-out Risk
Inventory Turnover
Branch Comparison

ผู้บริหารจึงเริ่มเห็นว่า เกิดอะไรขึ้น

A — Artificial Intelligence

AI สามารถดูข้อมูลเหล่านั้นต่อได้ว่า

สินค้าตัวนี้กำลังเสี่ยง Stock-out
สาเหตุคือ Demand เพิ่มขึ้นผิดปกติ
PO ใหม่จะมาไม่ทัน
อีกสาขามี Stock เกินความต้องการ

จากนั้น Agent อาจเสนอว่า

ควร Transfer 120 ชิ้นจากสาขา B ไปสาขา A

แล้วส่งให้คนอนุมัติ

นี่คือเส้นทาง

Data → Visibility → Insight → Recommendation → Action

แต่ทุกอย่างเริ่มจาก Data Foundation เดิม

แล้วต้องเตรียม Data ทั้งบริษัทก่อนทำ AI หรือไม่?

ไม่ครับ

ผมคิดว่านี่เป็นความเข้าใจผิดอีกด้านหนึ่ง

ถ้าเราบอกองค์กรว่า

“ก่อนทำ AI ต้องจัด Data ทั้งบริษัทให้เสร็จก่อน”

โครงการอาจไม่เริ่มสักที

วิธีที่ Practical กว่าคือเริ่มจาก Business Question หนึ่งเรื่อง

เช่น

“ทำไมสินค้าของเราถึง Stock-out บ่อย?”

แล้วค่อยเดินย้อนกลับ

ต้องใช้ Data อะไร?
Data อยู่ที่ไหน?
นิยามตรงกันไหม?
ใครเป็น Owner?
ข้อมูลเชื่อถือได้แค่ไหน?
Dashboard ต้องแสดงอะไร?
AI จะช่วยตรงไหน?
สุดท้ายใครเป็นคนตัดสินใจ?

นี่คือวิธีที่เราอยากใช้ CBA

ไม่ใช่สร้าง Architecture ใหญ่ก่อนแล้วค่อยหาว่าจะเอาไปทำอะไร

แต่เริ่มจากปัญหาธุรกิจ แล้วจัด Data เท่าที่จำเป็นให้สามารถเดินจาก Corporate → BI → AI ได้

Microsoft เองเสนอขั้นตอนคล้ายกันในบริบทของ AI-ready Data Foundation คือการรวม Data, เตรียมและ Harmonize ข้อมูล, เพิ่ม Semantic Meaning และจึงให้ Agent ใช้ Context เหล่านั้นในการลงมือทำ แหล่งอ้างอิง

ก่อนเลือก Tool ลองถาม Business Question ให้ชัดก่อน

ช่วงนี้ Tool เปลี่ยนเร็วมากครับ

วันนี้เราพูดถึง ChatGPT, Gemini, Copilot
อีกไม่กี่เดือน Landscape อาจเปลี่ยนอีก

แต่ Revenue ยังต้องมีความหมาย
Customer ยังต้องมี Owner
Inventory ยังต้องรู้ว่าตัวเลขมาจากไหน
Permission ยังต้องมี
Business Process ยังต้องมีคนรับผิดชอบ

Microsoft เพิ่งพูดประเด็นนี้ชัดในปลายเดือนกันยายนว่า เมื่อ Model กลายเป็นสิ่งที่เข้าถึงได้มากขึ้น ความได้เปรียบขององค์กรจะอยู่ที่สิ่งที่ “เฉพาะตัว” กว่า Model นั่นคือ Data, Expertise และ Business Context ขององค์กรเอง แหล่งอ้างอิง

ผมเห็นด้วยกับแนวคิดนี้มาก

เพราะมันทำให้คำถามของ AI Transformation เปลี่ยนจาก

“เราจะใช้ Model ตัวไหนดี?”

เป็น

“เราจะทำอย่างไรให้ความรู้และข้อมูลของบริษัทพร้อมให้ AI ใช้ได้อย่างถูกต้อง?”

กระดุมเม็ดแรก

ที่ Data Story เราจึงใช้ CBA เป็น Framework ง่าย ๆ เวลาเริ่มต้นคุยกับองค์กร

C — Corporate
จัดข้อมูลให้เข้าใจและเชื่อถือได้

B — Business Intelligence
เปลี่ยนข้อมูลให้คนมองเห็นและเข้าใจธุรกิจ

A — Artificial Intelligence
ให้ AI ใช้ Context นั้นในการ Reason แนะนำ และช่วยลงมือทำ

ทั้งสามตัวไม่ควรเป็น Project ที่แยกออกจากกัน

มันควรเป็นการเพิ่มระดับความสามารถในการใช้ Data Foundation ชุดเดียวกัน

และถ้าถามผมว่า ก่อนเริ่ม AI Transformation ควรถามอะไรเป็นคำถามแรก

ผมคงยังไม่ถามว่าใช้ AI ตัวไหนดีครับ

ผมจะถามก่อนว่า

ข้อมูลของเราพร้อมให้ทั้งคนและ AI เข้าใจตรงกันหรือยัง?

เพราะถ้ากระดุมเม็ดแรกติดผิด ต่อให้ระบบที่ตามมาฉลาดแค่ไหน เราก็ยังต้องย้อนกลับมาแก้ที่ Data อยู่ดี

Next in CBA Series

บทถัดไปเราจะลงลึกที่ตัว C — Corporate

“มี Data เยอะ ไม่ได้แปลว่า Data พร้อมใช้: Corporate Data Foundation คืออะไร?”

เราจะลองแยกกันว่า Data แบบไหนถือว่า “พร้อมใช้” จริง และองค์กรจำเป็นต้องจัด Data ทั้งหมดก่อนหรือไม่ ก่อนจะไปถึง BI และ AI

แหล่งอ้างอิง

• Google Cloud: Looker Semantic Layer และ Trusted AI

• Google Cloud: Agentic BI

• Databricks: Unity Catalog Business Semantics

• Databricks: Unity Catalog Pages และ Genie Ontology

• Microsoft: Data, Expertise และ Business Context

• Snowflake: Semantic Views สำหรับ AI