จาก ERP ที่เก็บข้อมูล สู่ ERP ที่รักษาที่มาของความจริง
เมื่อ AI สามารถสร้างมุมมองจากข้อมูลได้ไม่จำกัด สิ่งที่สำคัญอาจไม่ใช่การสร้าง Report ให้มากขึ้น แต่คือการออกแบบว่า Report เหล่านั้นจะกลับไปหาความจริงได้อย่างไร
มีคำถามหนึ่งที่ผมเริ่มสงสัยจากการทำ ERP มานานพอสมควร
เราควรเก็บอะไรไว้ในระบบ เพื่อให้วันหนึ่งเรายังสามารถตอบได้ว่า “ตัวเลขนี้มาจากไหน”
ฟังดูเหมือนเป็นคำถามธรรมดา
แต่เมื่อเริ่มคิดถึงมันจริง ๆ คำตอบกลับไม่ง่าย
เพราะในระบบธุรกิจ สิ่งที่เกิดขึ้นกับสิ่งที่เราบันทึกไม่ได้เป็นเรื่องเดียวกันเสมอไป
และสิ่งที่เราบันทึกก็ไม่ได้หมายความว่าจะเป็น “ความจริง” ทั้งหมด
จาก KPI มาสู่คำถามว่า เราเลือกอะไรไม่ให้หายไป
ผมเริ่มต้นความคิดนี้จากเรื่อง KPI
ตัวเลขมีข้อดีอย่างหนึ่งที่น่าสนใจมาก
มันทำหน้าที่เป็นภาษากลาง
เมื่อคนสองคนใช้คำว่า “ผลงานดี” ไม่เหมือนกัน
เราสามารถเปลี่ยนมันเป็น 80 คะแนน แล้วความกำกวมบางอย่างก็หายไปทันที
นี่คือพลังของการทำให้ "วัดค่า" ได้
แต่เมื่อเราถามต่อว่า
แล้วเราควรวัดอะไร?
ปัญหาก็เริ่มขึ้น
GDP เป็นตัวอย่างคลาสสิก เราใช้มันเป็นไม้บรรทัดของเศรษฐกิจ ทั้งที่ระบบบัญชีประชาชาติถูกออกแบบมาเพื่อวัดกิจกรรมทางเศรษฐกิจ ไม่ใช่เพื่อเป็นเครื่องวัดความเป็นอยู่ที่ดีทั้งหมด
KPI ในองค์กรก็มีปัญหาในลักษณะเดียวกัน
สิ่งที่เราวัดได้ง่าย อาจไม่ใช่สิ่งที่เราสนใจจริงที่สุด
และสิ่งที่เราวัดได้ยาก
อาจถูกละเลยไป
แต่ในยุคที่พลังประมวลผลมีจำกัด การเลือกว่าจะเก็บอะไรและคำนวณอะไรเป็นสิ่งที่หลีกเลี่ยงไม่ได้
ERP ก็มีประวัติศาสตร์แบบเดียวกัน
ใน ERP เรามักเริ่มต้นจากคำถามว่า
เอกสารใบนี้ต้องบันทึกข้อมูลอะไรบ้าง?
คำตอบมักเป็น field
วันที่
เลขที่
ลูกค้า
สินค้า
จำนวน
ราคา
ภาษี
เพราะเรารู้แล้วว่าจะเอาข้อมูลไปทำอะไร
แต่ลองคิดกลับด้าน
เมื่อเราได้รับใบกำกับภาษีหนึ่งใบ เราอาจเลือกเก็บเฉพาะข้อมูลที่จำเป็นต่อการยื่นภาษี
ส่วนรายละเอียดอื่นเก็บเป็น PDF หรือรูปภาพไว้
เมื่อหลายปีก่อน ผมเคยทำระบบลักษณะนี้ให้สำนักบัญชี
งานของระบบไม่ใช่การทำ ERP เต็มรูปแบบ
แต่เป็นการตัดให้เหลือเฉพาะข้อมูลที่จำเป็น สำหรับภาษีซื้อ-ขายในแต่ละเดือน
ข้อมูลที่ต้องใช้ยื่นภาษีถูกบันทึกเป็น structured data
ส่วนเอกสารจริงถูก scan เก็บไว้
ตอนนั้นผมมองมันเป็นเพียงการออกแบบระบบให้เหมาะกับงาน
แต่เมื่อกลับมามองวันนี้ ผมคิดว่ามันมี principle ที่น่าสนใจกว่านั้นอยู่
เราไม่ได้เลือกว่าจะ เก็บหรือไม่เก็บข้อมูล
เราเลือกว่าจะ
“แปลงข้อมูลอะไรให้เป็นความจริง ที่ระบบสามารถประมวลผลได้ในตอนนี้”
และเก็บสิ่งอื่นไว้เป็นหลักฐานสำหรับคำถามในอนาคต
ปัญหาเริ่มขึ้นเมื่อ “ข้อมูล” ถูกเข้าใจว่าเป็น “ความจริง”
สมมติผู้ขายออกใบกำกับภาษีผิดพลาด
พนักงานพบก่อนส่งให้ลูกค้า
จึงแก้แล้วพิมพ์ใหม่
ในโลกของคนทำงาน ไม่มีใครคิดว่าธุรกิจเพิ่งมีธุรกรรมสองรายการ
เรารู้ว่า
ใบแรกผิดใบที่สองคือฉบับที่ถูกต้อง
แต่ถ้าเราพยายามออกแบบระบบโดยคิดว่า
ทุกสิ่งที่เคยเกิดขึ้นต้องกลายเป็น immutable business event
เราจะเริ่มเจอความขัดแย้งกับ common sense ของธุรกิจ
ใบแรก “เคยมีอยู่จริง”
แต่ไม่ได้หมายความว่าใบแรกคือ business truth ที่องค์กรยึดถือ
ตรงนี้ทำให้ผมเริ่มแยกสองคำออกจากกัน
Activity กับ Evidence
Logs ไม่ใช่ Evidence
Log บอกว่าเกิดอะไรขึ้นในระบบ
เช่น
10:01 User created invoice A001
10:02 User changed customer name
10:03 User printed document
10:04 User replaced document
ทั้งหมดนี้มีประโยชน์
แต่สิ่งเหล่านี้ไม่ได้หมายความว่าเป็นความจริงทางธุรกิจทั้งหมด
Log บอกว่า
“มี activity นี้เกิดขึ้น”
ไม่ได้แปลว่า
“ธุรกิจยอมรับ activity นี้เป็นความจริงที่ใช้ยึดถือ”
นี่เป็นความแตกต่างเล็ก ๆ แต่สำคัญมาก
Evidence คือสิ่งที่ธุรกิจใช้ยืนยันความจริง
ใบกำกับภาษีฉบับที่ถูกต้องอาจเป็น evidence
ใบส่งของอาจเป็น evidence
Bank statement อาจเป็น evidence
สัญญาอาจเป็น evidence
แม้แต่ accounting entry ที่ ERP สร้างขึ้น ก็อาจเป็น evidence ในอีกบริบทหนึ่งได้เช่นกัน
Evidence จึงไม่จำเป็นต้องหมายถึง “เอกสารต้นฉบับ”
ผมเริ่มมองมันว่า
Evidence คือสิ่งที่เราสามารถใช้ยึดโยงคำกล่าวอ้างทางธุรกิจกลับไปยังสิ่งที่เกิดขึ้นได้
และตรงนี้ทำให้ Evidence ต่างจาก Event Sourcing
Event Sourcing มีแนวคิดที่ทรงพลังมาก คือเก็บการเปลี่ยนแปลงของ application state เป็น sequence ของ events เพื่อให้สามารถ reconstruct state ในอดีตได้ (martinfowler.com)
แต่สำหรับ ERP ผมไม่แน่ใจว่าเราจำเป็นต้องทำทุกอย่างให้เป็น Event Sourcing
เพราะ
Event ที่ระบบรับรู้ ไม่จำเป็นต้องเป็น Evidence ของความจริงภายนอก
ระบบอาจรู้ว่าผู้ใช้สร้างใบกำกับขึ้นมา
แต่เอกสารต้นฉบับต่างหากที่อาจเป็นหลักฐานว่าเกิดธุรกรรมขึ้นจริง
ดังนั้นผมไม่อยากให้ ERP กลายเป็นระบบที่เก็บ event ทุกอย่าง เพียงเพราะเรากลัวว่าจะสูญเสีย history
สิ่งที่ผมอยากให้มันรักษาคือ
สิ่งที่ยังสามารถใช้พิสูจน์ที่มาของความจริงได้
จาก Evidence สู่ Provenance
ถ้า Evidence เป็นสิ่งที่เราใช้ยืนยันความจริง
คำถามต่อไปคือ
แล้วตัวเลขหนึ่งตัวเกิดจาก Evidence อะไร?
ตรงนี้เกิดคำว่า provenance
ในวงการข้อมูล แนวคิดนี้มีมานานแล้ว
W3C PROV อธิบาย provenance ผ่านความสัมพันธ์ ระหว่าง entities, activities และ agents รวมถึงเวลาและการเปลี่ยนแปลงของสิ่งเหล่านั้น (W3C)
ใน database ก็มีการศึกษาว่า output หนึ่ง มาจากข้อมูลต้นทางใด และเกิดขึ้นเพราะข้อมูลอะไรบ้าง
ดังนั้น provenance ไม่ใช่แนวคิดใหม่
สิ่งที่ผมกำลังลองคิดคือ
ถ้าเอาแนวคิดนี้มาเป็นแกนของ ERP จะเกิดอะไรขึ้น?
ผมเริ่มเห็น ERP เป็นสองชั้น
ชั้นแรกผมอยากเรียกว่า
Provenance Store
มันไม่ใช่ database ที่เก็บทุก event ของระบบ
และไม่ใช่ document archive อย่างเดียว
แต่เป็นพื้นที่ที่รักษาความสัมพันธ์ระหว่าง
Logs
Evidence
Revision
Commit
Lineage
เวลา
ความสัมพันธ์ระหว่างหลักฐาน
พูดง่าย ๆ คือ
เก็บสิ่งที่ทำให้เราย้อนกลับไปอธิบายที่มาของความจริงได้
ส่วนชั้นที่สองคือ
View Studio
หน้าที่ของมันไม่ใช่แค่สร้าง Report
แต่มันสร้าง View of Truth
จาก Evidence ที่มีอยู่
Logs
│
│
▼
┌──────────────┐
│ │
│ Provenance │
│ Store │
│ │
│ Logs │
│ Evidence │
│ Revision │
│ Commit │
│ Lineage │
└──────┬───────┘
│
▼
┌──────────────┐
│ View Studio │
└──────┬───────┘
│
┌───────────┼───────────┐
▼ ▼ ▼
Tax GL Stock
View View View
นี่ต่างจาก ERP แบบเดิมพอสมควร
เพราะ “Truth” ไม่จำเป็นต้องมี View เดียว
ใบกำกับหนึ่งใบอาจมีหลายความหมาย
สำหรับฝ่ายภาษี:
ฐานภาษีเท่าไร?
สำหรับบัญชี:
จะลงบัญชีอย่างไร?
สำหรับคลัง:
สินค้าเข้ากี่หน่วย?
สำหรับผู้บริหาร:
Supplier รายนี้มีต้นทุนสูงขึ้นหรือไม่?
สำหรับ auditor:
ตัวเลขนี้มาจากเอกสารอะไร?
ไม่มี view ใดผิด
แต่ละ view ตอบคำถามคนละแบบ
ดังนั้นแทนที่จะพยายามสร้าง
Single Source of Truth
ผมเริ่มคิดว่า ERP อาจต้องการ
Single Source of Provenance
แล้วอนุญาตให้มี
Many Views of Truth
สำนักบัญชีทำให้แนวคิดนี้ชัดขึ้นอีก
สมมติ ERP ของผู้ประกอบการสร้าง Accounting View
Invoice
↓
Accounting View
Dr. Expense 100,000
Dr. Input VAT 7,000
Cr. AP 107,000
สำหรับ ERP นี่คือ View
แต่เมื่อส่งข้อมูลนี้ไปยังสำนักบัญชี มันอาจกลายเป็น Evidence ของสำนักบัญชี
จากนั้นสำนักบัญชีอาจสร้าง Tax View ของตัวเอง
ERP
│
│ Accounting View
▼
Accounting Firm
│
│ Tax View
▼
Tax Filing
นี่ทำให้ integration ระหว่างองค์กรไม่ได้เป็นเพียง
“ระบบ A ส่งข้อมูลให้ระบบ B”
แต่กลายเป็น
“View ของระบบหนึ่ง กลายเป็น Evidence ที่ระบบถัดไปใช้สร้าง View ของตัวเอง”
และ provenance สามารถข้าม boundary ขององค์กรได้
งานด้าน provenance ก่อนหน้านี้เองก็มีแนวคิดของ provenance store ที่เชื่อมกันผ่าน view links เพื่อให้แต่ละฝ่ายสามารถอ้างถึงมุมมองของ interaction ที่อีกฝ่ายบันทึกไว้ได้ (ePrints)
แล้ว AI เข้ามาตรงไหน?
ผมคิดว่า AI ไม่ควรเข้ามาเป็นเจ้าของความจริง
AI ควรอยู่ถัดจาก Provenance Store
มันอ่าน Evidence
แล้วสร้าง View
Provenance Store
│
Evidence + Lineage
│
▼
AI
│
▼
View of Truth
คำถามที่เราเคยถาม Report Engine ว่า
“เอา column ไหนมาแสดง?”
อาจกลายเป็นคำถามว่า
“จาก evidence ที่มีอยู่ คุณช่วยอธิบายว่าทำไมกำไรเดือนนี้ลดลงได้หรือไม่?”
AI อาจตอบ:
กำไรลดลง 12%
แต่คำตอบที่มีคุณค่ากว่าคือ:
กำไรลดลง 12% จากยอดขายกลุ่ม A ลดลง 8% และต้นทุนนำเข้าสินค้ากลุ่ม B เพิ่มขึ้น 14% อ้างอิง invoice 1,284 รายการ และ purchase documents 147 รายการ มี 7 รายการที่ classification ยังไม่ชัดเจน
ตรงนี้ AI ไม่ได้เพียงสร้างคำตอบ
มันสร้าง View พร้อม Provenance
แล้วเราสามารถให้ AI ตรวจ AI ได้หรือไม่?
ผมคิดว่าได้ และนี่อาจเป็นสิ่งที่น่าสนใจที่สุด
ให้ AI สองตัวอ่าน Evidence เดียวกัน
Evidence
/ \
▼ ▼
AI-A AI-B
│ │
▼ ▼
View-A View-B
\ /
\ /
▼ ▼
Compare
│
▼
Differences
ถ้า AI ทั้งสองตัวเห็นตรงกัน นั่นไม่ได้หมายความว่า “ถูกแน่นอน”
แต่ถ้าเห็นไม่ตรงกัน เรารู้ว่าควรตรวจตรงไหน
เช่น
AI-A จัดรายการนี้เป็น Expense AI-B จัดเป็น Inventory
แล้วทั้งสองตัวสามารถชี้กลับไปยัง Evidence เดียวกัน
นักบัญชีจึงไม่จำเป็นต้องเริ่มจาก transaction หลายพันรายการ
แต่เริ่มจาก
“ทำไมสอง interpretation นี้ถึงต่างกัน?”
นี่อาจเปลี่ยน economics ของการตรวจสอบได้
จาก
ตรวจทุกอย่าง
ไปสู่
ตรวจความแตกต่างและความไม่แน่นอน
แน่นอนว่าไม่ควรสรุปว่า AI สองตัวเห็นตรงกันแล้วเท่ากับการ audit ตามกฎหมาย เพราะ audit เป็นกระบวนการและความรับผิดชอบทางวิชาชีพอีกเรื่องหนึ่ง
แต่ในระดับระบบ เราสามารถสร้าง machine verification ขึ้นมาเป็นชั้นหนึ่งก่อนถึง human judgment ได้
และงานด้าน AI provenance ที่กำลังพัฒนาในปัจจุบันก็เริ่มให้ความสำคัญกับการ trace จาก agent decision กลับไปยัง context, inputs และขั้นตอนที่เกี่ยวข้องแล้ว (arXiv)
สิ่งที่ผมคิดว่าเปลี่ยนไปจริง ๆ
ในยุคก่อน AI เรามักต้องออกแบบ Report ล่วงหน้า
เพราะการสร้าง report มีต้นทุน
เราจึงถามว่า
ผู้ใช้ต้องการรายงานอะไร?
แล้วสร้างมันไว้
นี่ทำให้ ERP มี Report จำนวนมาก
แต่รายงานเหล่านั้นล้วนสะท้อนคำถามที่เราเคยคิดว่าสำคัญ
AI เปลี่ยนสมการนี้
ต้นทุนในการสร้าง View ลดลงมาก
เราอาจไม่จำเป็นต้องสร้างทุก View ล่วงหน้า
ผู้ใช้สามารถถามคำถามใหม่กับ Evidence เดิม
AI สร้าง View ขึ้นมา
ถ้าเป็นประโยชน์ก็เก็บเป็น official view
ถ้าไม่ใช่ก็ทิ้งไป
Question
↓
AI-generated View
↓
Verify
↓
Useful?
┌─┴─┐
No Yes
│ │
ทิ้ง Publish
ดังนั้นสิ่งที่มีมูลค่ามากขึ้นจึงไม่ใช่ Report
แต่เป็น ความสามารถในการสร้าง Report ใหม่จาก Evidence เดิม
และนี่ทำให้ผมกลับไปคิดถึง KPI อีกครั้ง
KPI ไม่ได้ผิด
Report ก็ไม่ได้ผิด
Dashboard ก็ไม่ได้ผิด
ปัญหาเกิดขึ้นเมื่อเราเอา
View of Truth
ไปเท่ากับ
Truth
KPI เป็นเพียงมุมมองหนึ่ง
GDP ก็เป็นมุมมองหนึ่ง
Accounting View ก็เป็นมุมมองหนึ่ง
Tax View ก็เป็นมุมมองหนึ่ง
เมื่อคำถามเปลี่ยน View ก็อาจต้องเปลี่ยน
สิ่งที่ไม่ควรเปลี่ยนง่าย ๆ คือ
หลักฐานที่ทำให้เราย้อนกลับไปตรวจสอบได้ว่า View นั้นมาจากอะไร
ERP ในอนาคตอาจไม่ใช่ “ระบบที่รู้ทุกอย่าง”
ผมคิดว่านี่เป็นจุดที่ต่างจากความฝันของ Enterprise Software แบบเดิม
เราเคยพยายามออกแบบ ERP ให้มีข้อมูลที่ structured และสมบูรณ์ที่สุด
เพราะเราต้องรู้ล่วงหน้าว่าจะเอาข้อมูลไปทำอะไร
แต่ถ้า AI สามารถตีความข้อมูลใหม่ในอนาคตได้
คำถามอาจเปลี่ยนเป็น:
เราไม่จำเป็นต้องรู้วันนี้ว่า พรุ่งนี้จะถามอะไร แต่เราต้องไม่ทำลายหลักฐาน ที่ทำให้พรุ่งนี้ยังสามารถถามคำถามนั้นได้
นี่เป็นเหตุผลที่ผมเริ่มสนใจคำว่า Provenance Store
มันไม่ใช่การเก็บอดีตไว้เพราะเรากลัวข้อมูลหาย
แต่เป็นการรักษา ความสามารถในการตีความอดีตใหม่
จาก ERP ที่บันทึกธุรกรรม สู่ ERP ที่รักษาความสามารถในการอธิบาย
ถ้าต้องสรุป architecture ที่ผมกำลังคิดอยู่ในขณะนี้ ผมจะเขียนเพียงเท่านี้:
BUSINESS WORLD
│
┌──────────┴──────────┐
▼ ▼
Logs Evidence
what happened what we stand by
│ │
└──────────┬──────────┘
▼
Provenance Store
│
┌──────┴──────┐
│ │
lineage context
│ │
└──────┬──────┘
▼
View Studio
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Tax View GL View Management
│ │ │
└─────────────┼─────────────┘
▼
AI / Human
ผมไม่ได้คิดว่า architecture นี้ควรถูกนำไปใช้กับ ERP ทุกระบบทันที
และผมไม่ได้คิดว่ามันเป็นชื่อเรียก architecture ที่มีมาตรฐานอยู่แล้ว
ตรงกันข้าม แนวคิดพื้นฐานจำนวนมากมีอยู่ในโลกของ data provenance, lineage, event sourcing และ semantic/analytical views มานานแล้ว (W3C)
แต่สิ่งที่ผมสนใจคือการเอาแนวคิดเหล่านั้นกลับมาถามใหม่ว่า
ถ้าเราตัดความผูกพันกับ Report แบบเดิมออกจาก ERP แล้วออกแบบระบบโดยถือว่า “Provenance” เป็นสิ่งที่ต้องรักษา และ “View” เป็นสิ่งที่สร้างใหม่ได้ตลอดเวลา จะเกิด ERP แบบไหนขึ้นมา?
บางที AI ไม่ได้ทำให้ ERP ฉลาดขึ้นเพราะมันสามารถสร้างคำตอบได้มากขึ้น
แต่เพราะมันทำให้เรา ไม่จำเป็นต้องตัดสินล่วงหน้าอีกต่อไปว่า “อะไรคือสิ่งที่ควรสนใจ”
สิ่งที่เราต้องออกแบบให้ดีขึ้นกลับเป็นคำถามที่ตรงกันข้าม:
เมื่อเรายังไม่รู้ว่าอนาคตจะสนใจอะไร เราจะรักษาอะไรไว้ เพื่อให้อนาคตยังสามารถกลับมาถามเราได้?
และสำหรับผม ณ ตอนนี้ คำตอบเริ่มต้นคือ
Logs บอกว่าเกิดอะไรขึ้น Evidence บอกว่าอะไรที่เรายึดถือเป็นความจริง Provenance บอกว่าความจริงนั้นมีที่มาอย่างไร และ View Studio ทำให้เรามองความจริงชุดเดียวกันได้หลายแบบ
นี่อาจเป็นจุดที่ ERP ควรเริ่มออกแบบใหม่ในยุค AI.
ความคิดเห็น