เมื่อฝ่ายขาย ฝ่ายปฏิบัติการ และฝ่ายการเงินตอบคำถามเดียวกันด้วยตัวเลขคนละชุด ปัญหาไม่ได้อยู่ที่รายงานอย่างเดียว ธุรกิจยังไม่ตกลงว่าข้อมูลใดเป็นข้อมูลหลัก ใครดูแล และสถานะแต่ละคำหมายถึงอะไร
มุมมองนี้มาจากโจทย์ที่ Enersys เคยทำ ทั้งการรวมข้อมูลจากหลายแพลตฟอร์มอีคอมเมิร์ซเข้า Odoo เพื่อวางเป็น Business OS และงาน Odoo ในธุรกิจการผลิตที่เชื่อมระบบธุรกิจกับ MES เรามอง Odoo เป็นฐานข้อมูลธุรกิจที่เชื่อมรายการกับการทำงานของคน แต่คำว่า “ฐานข้อมูลธุรกิจ” ในบทความนี้ไม่ได้หมายความว่าต้องย้ายข้อมูลทุกชนิดมาไว้ใน Odoo หรือใช้ Odoo แทนคลังข้อมูลทุกแบบ หมายถึงการทำให้ข้อมูลหลักและสถานะงานที่ทีมต้องใช้ร่วมกันมีความหมาย เจ้าของ และประวัติที่ตรวจสอบได้
เริ่มจากคำถามที่ธุรกิจถามซ้ำ
ลองรวบรวมคำถามที่ต้องหาคำตอบทุกวัน เช่น ลูกค้ารายนี้อยู่ขั้นตอนไหน ของพร้อมส่งเท่าใด ใบสั่งซื้อใดรออนุมัติ งานใดยังวางบิลไม่ได้ หรือยอดค้างเกิดจากรายการใด จากนั้นตรวจว่าทีมเปิดระบบหรือไฟล์กี่แห่งกว่าจะตอบได้
คำถามเหล่านี้ช่วยกำหนดขอบเขตข้อมูลได้ดีกว่าการเริ่มจากคำว่า “ต้องการแดชบอร์ด” เพราะแดชบอร์ดที่สวยก็ยังตอบผิดได้ หากสถานะต้นทางไม่ชัดหรือแต่ละทีมบันทึกข้อมูลคนละจังหวะ
เลือกคำถามหนึ่งข้อแล้วไล่กลับไปถึงรายการต้นทาง ดูว่าใครสร้าง ใครตรวจ ใครแก้ และเหตุการณ์ใดทำให้สถานะเปลี่ยน งานนี้จะเปิดให้เห็นว่าปัญหาอยู่ที่ข้อมูลขาด ขั้นตอนซ้ำ หรือความหมายไม่ตรงกัน
กำหนดข้อมูลหลักและเจ้าของ
ข้อมูลหลัก เช่น ลูกค้า สินค้า ผู้ขาย หน่วยนับ เงื่อนไขชำระเงิน และผังบัญชี ถูกใช้ซ้ำในหลายกระบวนการ หากไม่มีเจ้าของ คนแต่ละทีมอาจสร้างข้อมูลใหม่เพื่อให้งานของตนเดินต่อ แล้วความซ้ำจะไปปรากฏในรายงานปลายทาง
การมีเจ้าของข้อมูลไม่ได้แปลว่ามีคนคนเดียวกรอกทุกอย่าง เจ้าของมีหน้าที่กำหนดว่าข้อมูลใดจำเป็น ใครมีสิทธิ์สร้างหรือแก้ วิธีตรวจรายการซ้ำ และเมื่อใดต้องทบทวน กติกานี้ควรเข้าใจได้โดยผู้ใช้ ไม่ควรอยู่เฉพาะในเอกสารเทคนิค
Odoo อาจเป็นระบบหลักของข้อมูลบางประเภท ขณะที่ข้อมูลอีกประเภทอยู่ในระบบเฉพาะทาง การออกแบบที่ดีไม่บังคับให้ระบบเดียวเป็นเจ้าของทุกอย่าง แต่ระบุให้ชัดว่าแต่ละข้อมูลเริ่มจากที่ใด ส่งต่ออย่างไร และระบบใดมีสิทธิ์ตัดสินค่าปัจจุบัน
ให้สถานะบอกว่างานอยู่กับใคร
สถานะที่ดีไม่ใช่ป้ายสำหรับจัดสีบนหน้าจอ แต่บอกได้ว่างานผ่านเงื่อนไขใดแล้ว ใครต้องทำต่อ และหลักฐานใดรองรับการเปลี่ยนสถานะ เช่น “รออนุมัติ” ควรระบุได้ว่ารอใคร “พร้อมวางบิล” ควรมีเงื่อนไขที่ทีมขายและการเงินเข้าใจตรงกัน
หากสถานะเปลี่ยนได้โดยไม่มีข้อมูลประกอบ ระบบจะกลายเป็นที่บันทึกความเห็นย้อนหลัง ผู้ใช้จะสร้างช่องทางนอกระบบเพื่อถามว่าเกิดอะไรขึ้น และรายงานจะนับรายการที่มีชื่อสถานะเดียวกันแต่ความหมายต่างกัน
ก่อนเพิ่มสถานะใหม่ ให้ถามว่ามีการตัดสินใจใดเกิดขึ้น ใครรับผิดชอบ และรายงานใดใช้สถานะนี้ หากตอบไม่ได้ สถานะนั้นอาจเป็นเพียงรายละเอียดที่เพิ่มภาระการบันทึก
เก็บประวัติให้ตอบคำถามได้
ฐานข้อมูลธุรกิจต้องช่วยตอบว่าใครทำอะไร เมื่อใด และข้อมูลเปลี่ยนเพราะเหตุใด ไม่ใช่เก็บเฉพาะค่าล่าสุด ประวัติที่จำเป็นอาจรวมการเปลี่ยนผู้รับผิดชอบ การอนุมัติ การแก้จำนวน หรือการเชื่อมโยงเอกสารต้นทางกับรายการถัดไป
ไม่ได้หมายความว่าต้องเก็บทุกการคลิก ธุรกิจควรเลือกเหตุการณ์ที่กระทบการเงิน ลูกค้า สต็อก หรือข้อผูกพัน แล้วกำหนดให้มีหลักฐานพออธิบายการตัดสินใจ การเก็บมากเกินไปโดยไม่มีวัตถุประสงค์ทำให้ค้นยากและเพิ่มภาระด้านข้อมูลส่วนบุคคล
เชื่อมระบบโดยไม่ทำลายความหมายของข้อมูล
เมื่อ Odoo เชื่อมกับเว็บไซต์ ช่องทางขาย ระบบขนส่ง ธนาคาร หรือเครื่องมือเฉพาะทาง การเชื่อมต้องรักษาทั้งรูปแบบฟิลด์และความหมายทางธุรกิจ ตัวอย่างเช่น “ชำระแล้ว” ในระบบหนึ่งอาจหมายถึงลูกค้าจ่ายเงิน ส่วนอีกระบบอาจหมายถึงกระทบยอดและรับเงินจริงแล้ว หากส่งสถานะเดียวกันโดยไม่แปลงความหมาย งานถัดไปอาจเริ่มผิดเวลา
เอกสารเชื่อมระบบควรระบุเจ้าของข้อมูล เงื่อนไขการเปลี่ยนสถานะ รหัสอ้างอิง และวิธีรับมือเมื่อรายการส่งไม่สำเร็จ เมื่อกติกาเหล่านี้เปิดให้ทีมธุรกิจตรวจได้ การเชื่อมต่อจะไม่เป็นกล่องดำที่ต้องรอผู้พัฒนาอธิบายทุกครั้ง
เตรียมข้อมูลให้ใช้กับ AI อย่างมีขอบเขต
องค์กรที่อยากให้ AI ช่วยตอบคำถามหรือเตรียมร่างจากข้อมูล Odoo ควรเริ่มจากสิทธิ์และความหมายของข้อมูลก่อน AI ต้องรู้ว่าจะอ่านข้อมูลชุดใด คำตอบอ้างอิงรายการใด และเรื่องใดต้องให้คนตรวจหรืออนุมัติ
หากข้อมูลลูกค้าซ้ำ สถานะไม่ตรงกัน หรือไม่มีเจ้าของ AI จะตอบจากความไม่ชัดเจนนั้นได้เร็วขึ้น แต่ไม่ได้ทำให้ข้อมูลน่าเชื่อถือขึ้น การจัดฐานข้อมูลธุรกิจจึงเป็นงานเตรียมความพร้อมของกระบวนการ ไม่ใช่เพียงโครงการทำความสะอาดข้อมูลก่อนเปิด AI
เช็กลิสต์ฐานข้อมูลธุรกิจ
- คำถามทางธุรกิจสำคัญแต่ละข้อใช้ข้อมูลจากระบบใด และใครรับรองความหมาย
- ข้อมูลหลักประเภทใดมีเจ้าของ กติกาการสร้าง และวิธีจัดการรายการซ้ำ
- สถานะแต่ละค่าบอกเงื่อนไข ผู้รับผิดชอบ และงานขั้นถัดไปได้หรือไม่
- เหตุการณ์ใดต้องเก็บประวัติเพื่ออธิบายการตัดสินใจหรือกระทบยอด
- เมื่อเชื่อมระบบ ความหมายของข้อมูลและสถานะถูกแปลงไว้ตรงไหน
- หากนำข้อมูลไปใช้กับ AI ใครกำหนดสิทธิ์ แหล่งอ้างอิง และจุดอนุมัติ
เริ่มจากคำถามที่ผู้บริหารถามซ้ำหนึ่งข้อ แล้วไล่ข้อมูลย้อนกลับถึงเจ้าของและรายการต้นทาง หากทีมตอบความหมายของแต่ละค่าได้ตรงกัน Odoo ก็กำลังทำหน้าที่เป็นฐานข้อมูลการทำงานร่วมกัน หากยังตอบไม่ตรงกัน นั่นคือจุดที่ควรแก้ก่อนเพิ่มรายงานหรือเครื่องมือใหม่
คุยเรื่องการวาง Odoo เป็นฐานข้อมูลธุรกิจกับทีม Enersys