Future ERP - 5: Conversation with AI

---

ตอนที่ 5 - ข้อมูลคือข้อเท็จจริง 

ไม่ใช่แค่สิ่งที่โปรแกรมอยากรู้

ในตอนก่อนหน้า เราได้พูดถึงการเปลี่ยนผ่านแนวคิดของ ERP จากซอฟต์แวร์ที่ควบคุมกระบวนการภายในองค์กร ไปสู่ความเป็นโครงสร้างกลางที่สามารถประสานความร่วมมือระหว่างองค์กรได้มากขึ้น พร้อมทั้งมองเห็นความเป็นไปได้ที่ ERP อาจไม่ได้หมายถึงผลิตภัณฑ์ของบริษัทใดบริษัทหนึ่งอีกต่อไป แต่อาจหมายถึง โครงสร้างพื้นฐาน ที่เปิดรับการพัฒนาและแบ่งปันกันได้ในระดับ ecosystem

ในตอนนี้ ผมอยากชวนผู้อ่านมาพิจารณา "หัวใจ" ของระบบ ERP อีกส่วนหนึ่งที่เรามักพูดถึงกันน้อยเกินไป นั่นคือ ข้อมูล (Data)

Table Normalization ใช้มองโลกที่รู้แล้ว

ถ้าใครเคยพัฒนา ERP มาก่อน หรือเคยมีส่วนร่วมกับการออกแบบ schema ของฐานข้อมูล เราจะคุ้นชินกับแนวทาง Relational Database ที่ใช้วิธีการจัดการข้อมูลโดยการแบ่งเป็น table พร้อมกำหนดความสัมพันธ์ (relation) ระหว่าง table เหล่านั้น และมักจะมีเป้าหมายในการ "ทำให้ข้อมูลไม่ซ้ำซ้อน" หรือที่เรียกกันว่า Normalization

แนวทางนี้ดีมากสำหรับโลกที่มีโครงสร้างชัดเจน โลกที่เรารู้แล้วว่าอยากจัดการอะไร รู้แล้วว่าอะไรคือ fact และอะไรคือสิ่งที่ไม่จำเป็นต้องเก็บ 

แต่เมื่อโลกเริ่มซับซ้อนขึ้น ข้อมูลที่เรายังไม่แน่ใจว่าจะเอาไปใช้อย่างไร กลับกลายเป็นสิ่งที่ ERP ไม่สามารถรองรับได้ง่ายนัก

ERP จึงมักเก็บเฉพาะสิ่งที่รู้จักดีแล้วเท่านั้น  ซึ่งทำให้พลาดโอกาสในการใช้ประโยชน์จาก "fact ที่ยังไม่มีโครงสร้าง"

Fact กับ Data ไม่ใช่สิ่งเดียวกันเสมอไป

ในเชิงแนวคิด ข้อมูล (data) ที่อยู่ในระบบ ERP มักเกิดจากการ "บันทึก" โดยมนุษย์หรือระบบ เพื่อวัตถุประสงค์บางอย่าง เช่น การบันทึกคำสั่งซื้อ เพื่อให้ออกใบกำกับภาษี หรือการบันทึกใบรับของ เพื่อให้สามารถทำบัญชีได้

แต่ในความเป็นจริง ทุกๆ การทำธุรกรรม มีข้อมูลอีกมากมายที่อาจเกิดขึ้น แต่ไม่เคยถูกบันทึกไว้ใน ERP เช่น

• ข้อความพูดคุยระหว่างฝ่ายขายกับลูกค้า

• การเปลี่ยนใจหรือแก้คำสั่งซื้อหลายครั้ง

• ข้อมูลสินค้าที่ยังไม่เคยขาย

• สถานะของ supply chain ที่เปลี่ยนตลอดเวลา

สิ่งเหล่านี้คือ "fact" ที่มีอยู่จริง แต่ยังไม่ใช่ "data" ที่ระบบสามารถประมวลผลได้ จึงไม่ถูกรับรู้ในมุมมองของ ERP

ERP ต้องการข้อมูลสะอาด

แน่นอนว่า ERP ที่ดีต้องการข้อมูลที่ "สะอาด" และ "เป็นระบบ" เพื่อให้สามารถควบคุมกระบวนการได้อย่างแม่นยำ เช่น ต้องมีรหัสสินค้า ต้องตั้งหน่วยนับ ต้องกำหนดประเภทภาษี ทุกอย่างต้องอยู่ในรูปแบบที่รู้จักได้

แต่นั่นคือเหตุผลที่ ERP ยุคดั้งเดิมไม่สามารถใช้ประโยชน์จากข้อมูลที่ยังไม่แน่ชัด หรือยังไม่ถูกนิยาม (เช่น ข้อความ, รูปภาพ, โลเคชัน, ความรู้สึก) ได้ดีนัก

เราจึงเริ่มเห็นแนวโน้มที่ ERP ต้องทำงานร่วมกับระบบอื่นๆ ที่สามารถจัดการข้อมูล "ที่ยังไม่เป็นระเบียบ" ได้ เช่น ระบบ AI, ระบบวิเคราะห์ข้อมูลแบบ Big Data, หรือแม้แต่ระบบที่เก็บข้อมูลแบบ semi-structured เช่น NoSQL

ERP as Data Infrastructure?

หากย้อนกลับไปดูว่าทำไม Relational Database จึงเป็นรากฐานของ ERP ในยุคก่อน เราจะพบว่าเพราะมันตอบโจทย์ "การจัดระเบียบข้อมูล" ได้ดี 

แต่ในยุคที่โลกต้องการ "การเปิดรับข้อมูลจากทุกทิศทาง" และ "การแยก fact ออกจาก format" เราอาจต้องเริ่มตั้งคำถามว่า ERP ที่ทำหน้าที่ประมวลผล ควรแยกออกจากระบบที่ทำหน้าที่เก็บข้อเท็จจริงหรือไม่

บางที ERP ในอนาคตอาจทำหน้าที่เป็น View Layer ของข้อมูลที่ถูกรวบรวมจากหลากหลายแหล่ง (รวมถึงแหล่งที่ ERP ไม่ได้ควบคุมโดยตรง) และทำหน้าที่สรุป วิเคราะห์ ควบคุม เฉพาะในบริบทที่กำหนด

หรือในทางกลับกัน ERP อาจลดขนาดลงจนกลายเป็นเพียงระบบ "จัดการความรู้ที่ยืนยันแล้ว" (Certified Fact) โดยปล่อยให้การเก็บและแปลงข้อมูลดิบเป็นหน้าที่ของระบบอื่นใน ecosystem

ข้อสังเกตส่งท้าย

หากเรายอมรับว่า "ข้อมูลที่ใช้ควบคุม" ไม่จำเป็นต้องเหมือน "ข้อเท็จจริงทั้งหมด"

การออกแบบระบบ ERP ก็อาจไม่จำเป็นต้องทำทุกอย่างอีกต่อไป 

เราอาจเห็น ERP ที่เล็กลง แต่ฉลาดขึ้น  เชื่อมต่อมากขึ้น ยืดหยุ่นมากขึ้น

---

เบื้องหลังบทสนทนา

ผมเริ่มทำซอฟต์แวร์ตั้งแต่สมัยที่โปรแกรมบัญชีใช้ Btrieve เป็น database ข้อมูลจะมีส่วนที่เหมือนกันเป็นโครงสร้างร่วมที่ตายตัวและส่วนที่ยืดหยุ่นแตกต่างกันโดยมีรหัสนำของแต่ละ record บ่งบอกชนิดของข้อมูล

เป็นยุคก่อนที่เราจะเปลี่ยนวิธีมองข้อมูลเป็น table ต้องมี column เท่ากันทุกแถว และ SQL เป็นภาษาในโลก database ที่นักพัฒนาซอฟต์แวร์ยอมรับร่วมกัน บางทีก็รู้สึกว่าเป็นศาสนาหรือความเชื่อที่ไม่อาจท้าทายที่จะเลือกใช้ database แบบอื่น

ในอีกมุมหนึ่งสำหรับโปรเจคท์ทั่วไปการเลือกเทคโนโลยีมักขึ้นอยู่กับทักษะของนักพัฒนาในทีมด้วย จึงทำให้ SQL เป็นเอกฉันท์

การนำเสนอแนวคิดที่แตกต่างจากสิ่งที่คนส่วนใหญ่ที่เติบโตมาจึงยาก

จากประสบการณ์ของผมเอง พบว่า document data model สำหรับ ERP ทำให้งานประมวลผลข้อมูลภายหลังง่ายและมีต้นทุนต่ำต่อการนำไปใช้ต่อ เช่น การสร้างรายงานเฉพาะ หรือ aggreation report สามารถทำโดยไม่จำเป็นต้องใช้ผู้เชี่ยวชาญ database ใช้เวลาน้อยกว่า เพราะไม่ต้องเสียเวลากับการทำความเข้าใจความสัมพันธ์ของ table ที่ซับซ้อน

เมื่อเล่าข้อสังเกตนี้ออกไป AI ช่วยขยายความและตั้งคำถามต่อไปไกลกว่าที่ผมคิดเสียอีก

Database เป็นหัวใจสำคัญของ ERP และผมสังเกตว่า ERP ระดับโลกมี database engine ของตัวเอง ต่อมาเมื่อมี Relational database และ SQL กลายเป็นมาตรฐานภาษาที่ใช้ติดต่อกับ database โดยเฉพาะใน ERP ด้วย . ถึงแม้ Relational database จะมีข้อดีมากมาย แต่ผมตั้งข้อสังเกตดังนี้ วิธีคิดที่ออกแบบ schema กำหนด table และ normalization เป็นการมองโลกในยุคที่ "รู้และเข้าใจ" ดีอยู่แล้ว จึง optimize หรือคัดกรอง fact ให้เหลือเพียง data ใน table ที่มีโครงสร้างและความสัมพันธ์แบบไม่ยืดหยุ่น เมื่อโลกมีมิติของข้อมูลซับซ้อน เมื่อถูกออกแบบให้อยู่ใน layer เดียวกัน ระหว่างข้อมูลที่ ERP สนใจใช้เพื่อประมวลผล กับข้อมูลที่เป็น fact ของธุรกรรม . ERP ในยุคเริ่มต้น ถูกออกแบบให้เพียงรับใช้ผู้บริหาร ด้วยขีดจำกัดของคอมพิวเตอร์สมัยนั้น จึงเลือกเก็บเฉพาะข้อมูลที่สนใจ ต่อมาเมื่อ ERP ถูกขยายให้ครอบคลุมกว้างขึ้นในระดับปฏิบัติงานขั้นตอนต่างๆ ข้อมูลก็เริ่มซับซ้อนมากขึ้นเรื่อยๆ จนผมไม่แน่ใจว่ามีใครเคยเจ็บปวดกับการออกแบบข้อมูลแบบ table บ้างไหม เมื่อเจอกับข้อมูลในโลกยุคใหม่ที่ยังไม่แน่ใจว่าควรสนใจชิ้นส่วนไหนของ fact บ้าง . หากโลกที่ fact ไม่ได้อยู่ในกระดาษ สามารถเข้าถึงได้สะดวกรวดเร็วเช่น บน cloud วิธีคิดเกี่ยวกับการได้มาของข้อมูลที่ใช้ควบคุมและประมวลผลสำหรับ ERP จะเปลี่ยนไปหรือไม่

คุณกำลังชี้ไปที่ประเด็นลึกระดับ "แก่นของระบบ ERP" อย่างแท้จริงครับ - นั่นคือ วิธีคิดเรื่องข้อมูล (data thinking) ที่ซ่อนอยู่เบื้องหลังการออกแบบ ERP ซึ่งเรามักมองว่าเป็นเรื่องเทคนิค แต่จริง ๆ แล้วมันคือ ชุดของสมมุติฐานทางธุรกิจ + ข้อจำกัดเทคโนโลยี + ความเข้าใจมนุษย์ต่อข้อมูล ณ เวลานั้น

สาระสำคัญในสิ่งที่คุณตั้งข้อสังเกต

ERP ยุคแรก = "ระบบที่ optimize การเก็บเฉพาะข้อมูลที่คิดว่าจำเป็นแล้ว"

เพราะเทคโนโลยี (processor, storage, memory) ยังไม่รองรับการเก็บ fact ทั้งหมด

จึงต้อง คัด fact → กรอง → ทำ normalization → บันทึกเฉพาะ data ที่สามารถประมวลผลได้ง่าย

กล่าวอีกทางหนึ่ง

Table schema ใน ERP 

ไม่ใช่ representation ของ fact ทั้งหมด 

แต่เป็นผลลัพธ์จากการตัดสินใจว่าจะเก็บอะไรเท่านั้น 

(และนี่คือจุดเจ็บเมื่อโลกเปลี่ยน แต่ schema ไม่เปลี่ยน)