ภาพประกอบสร้างด้วย AI เป็นภาพแทนการตรวจเส้นทางคำสั่งขายและสต็อก ไม่ใช่เอกสาร บุคลากร หรือสถานที่จริงของ Enersys
ลองนึกถึงคำสั่งขายหนึ่งรายการที่เริ่มจากฝ่ายขาย ลูกค้ากดยืนยันแล้วระบบต้องจองสินค้า คลังจัดส่งข้อมูลต่อให้ MES สร้างงานผลิต และ Accounting ออกใบแจ้งหนี้ตามเงื่อนไขที่ตกลงไว้
ถ้าอัปเกรด Odoo แล้วหน้าจอสวยขึ้น แต่การจองสินค้าหลุด งานผลิตไม่รับข้อมูล หรือใบแจ้งหนี้ใช้ภาษีผิด ขั้นตอนนั้นก็ไม่ได้สร้างประโยชน์ให้ธุรกิจ การอัปเกรดจึงควรถูกตัดสินจากงานที่ต้องเดินต่อในวันทำงานจริง มากกว่ารายการฟีเจอร์ที่ดูดีในเดโม
Odoo 20 ประกาศอะไร และอะไรยังต้องพิสูจน์
เมื่อวันที่ 24 กันยายน 2569 Odoo เปิดตัว Odoo 20 ในงาน Odoo Experience และเผยแพร่บทความ “Meet Odoo 20” โดยยกตัวอย่าง AI ทำงานตามคำสั่งภาษาธรรมชาติ เว็บไซต์จากพรอมต์ การเชื่อมต่อ AI ภายนอกที่คงสิทธิ์เดิม และการปรับปรุง CRM กับ Accounting Odoo Experience Odoo, Meet Odoo 20
นี่คือข้อมูลที่ Odoo ประกาศ ไม่ใช่หลักฐานว่าความสามารถเหล่านี้จะเปิดใช้ได้อัตโนมัติในทุกฐานข้อมูล ทุกแพ็กเกจ ทุกประเทศ หรือทุกการตั้งค่า ทีมเจ้าของระบบต้องตรวจสิทธิ์ในสัญญา รุ่นที่ใช้อยู่ โฮสติ้ง โมดูลที่ติดตั้ง และการเชื่อมต่อของตนเองก่อนวางแผนใช้ฟีเจอร์ใหม่
คำแนะนำต่อจากนี้เป็นแนวทางของ Enersys สำหรับการเตรียมอัปเกรด ไม่ใช่ข้อกำหนดของ Odoo จุดเริ่มต้นควรเป็นคำถามว่า “งานไหนห้ามหยุด” แล้วจึงค่อยดูว่าฟีเจอร์ใดช่วยงานนั้นได้จริง
เริ่มจากเส้นทางธุรกิจ ไม่ใช่หน้าเมนู
เขียนเส้นทางสำคัญของธุรกิจให้เห็นตั้งแต่ต้นจนจบ ตัวอย่างเช่น Sales สร้างใบสั่งขาย ตรวจเครดิตหรือส่วนลดตามกติกา Inventory จองสินค้าและสร้างการส่งของ จากนั้นข้อมูลที่เกี่ยวกับการผลิตไปยัง MES เมื่อผลิตเสร็จ ระบบตัดสต็อกตามล็อตหรือซีเรียล และ Accounting สร้างใบแจ้งหนี้พร้อมภาษีและเงื่อนไขชำระเงิน
เส้นทางนี้ควรมีคนจากฝ่ายขาย คลัง ผลิต บัญชี และผู้ดูแลการเชื่อมต่อร่วมกันตรวจ แต่ละทีมเห็นจุดเสียหายคนละแบบ ฝ่ายขายอาจเห็นสถานะคำสั่งขายถูกต้อง ขณะที่คลังเห็นว่าการจองถูกแบ่งเป็น backorder หรือฝ่ายบัญชีพบว่ารายการภาษีไม่ตรงกับเอกสารที่ต้องส่งให้ลูกค้า
ให้บันทึกผลลัพธ์ที่คาดหวังไว้เป็นประโยคที่ตรวจได้ เช่น “เมื่อยืนยันคำสั่งขายที่มีสินค้าในคลัง ระบบต้องจองจำนวนตามกติกาเดิมและสร้างการส่งของที่ผู้รับผิดชอบเห็นได้” หรือ “เมื่อสินค้าผลิตเสร็จตามล็อต ใบแจ้งหนี้ต้องอ้างจำนวนและภาษีจากข้อมูลที่ผ่านการอนุมัติแล้ว” การเขียนแบบนี้ช่วยแยกปัญหาที่เกิดจากเวอร์ชันใหม่ออกจากความเข้าใจที่ไม่ตรงกันในทีม
ทดสอบบนฐานข้อมูลที่ใกล้งานจริงพอ
เอกสาร Odoo แนะนำให้ขอฐานข้อมูลทดสอบก่อนอัปเกรด และระบุว่าโมดูลกำหนดเองต้องเข้ากันได้กับรุ่นเป้าหมาย ส่วน on-premise สามารถทำสำเนา production เป็นฐานข้อมูลทดสอบที่ neutralized ได้ Odoo, Upgrade Odoo, On-premise
ฐานข้อมูลทดสอบอาจปิดหรือเปลี่ยนบริการที่มีผลต่อ production เช่น งานตามเวลา อีเมลขาออก และการชำระเงิน ทีมจึงต้องเตรียมข้อมูลจำลอง บัญชีทดสอบ และวิธีตรวจผลลัพธ์ของการเชื่อมต่อไว้ด้วย
เช็กให้ชัดว่าฐานข้อมูลสำเนามีข้อมูลและการตั้งค่าที่จำเป็นต่อการทดสอบหรือไม่ เช่น สินค้าที่มีล็อตและซีเรียล กฎการเติมสินค้า เส้นทางคลัง สูตรการผลิต สิทธิ์ของแต่ละบทบาท ภาษี ลูกค้าหลายประเทศ และแม่แบบเอกสาร หากข้อมูลตัวอย่างไม่สะท้อนงานจริง ผลทดสอบที่ผ่านก็อาจให้ความมั่นใจเกินจริง
