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