ในโลกของ Software Development มีหลักการหนึ่งที่ Developer หลายคนน่าจะคุ้นเคยดี คือ
DRY — Don’t Repeat Yourself
แนวคิดง่าย ๆ คือ เราไม่ควรสร้าง Logic หรือเขียนสิ่งเดิมซ้ำไปซ้ำมา หากสามารถออกแบบให้ส่วนหนึ่งของระบบถูกนำกลับมาใช้ซ้ำได้อย่างเหมาะสม
ตัวอย่างเช่น หากระบบมีการคำนวณภาษีแบบเดียวกันในหลายหน้าจอ การเขียน Logic การคำนวณภาษีแยกไว้ทุกจุดอาจทำให้ระบบดูเหมือนทำงานได้ในช่วงแรก แต่เมื่อกฎการคำนวณเปลี่ยน เราจะต้องตามแก้หลายตำแหน่ง และมีโอกาสที่แต่ละจุดจะให้ผลลัพธ์ไม่เหมือนกัน
Developer จึงพยายามสร้าง Single Source of Truth และนำ Component, Function หรือ Business Logic กลับมาใช้ซ้ำ แทนการสร้างสิ่งเดิมขึ้นมาใหม่ทุกครั้ง
แต่แนวคิด DRY ไม่ได้มีประโยชน์เฉพาะตอนเขียน Code
สำหรับ IMOTIF เรามองว่าหลักคิดเดียวกันนี้สามารถนำมาใช้กับการวางระบบ ERP ได้เช่นกัน และเป็นที่มาของแนวทางที่เราเรียกว่า
Standard-First Odoo Implementation
Standard-First หมายถึง ก่อนที่จะพัฒนา Customization เราจะเริ่มจากคำถามว่า
“Odoo Standard ทำเรื่องนี้ได้อยู่แล้วหรือไม่?”
ไม่ใช่เริ่มต้นจาก
“ลูกค้าต้องการแบบนี้ เราต้องเขียนเพิ่มกี่ Manday?”
ความแตกต่างของสองคำถามนี้มีผลต่อ Architecture และ Total Cost of Ownership ของระบบ ERP ในระยะยาวอย่างมาก
DRY กับ ERP Implementation เกี่ยวข้องกันอย่างไร?
ลองนึกภาพองค์กรที่กำลังเปลี่ยนจากระบบเดิมมาใช้ Odoo ERP
ในระบบเดิม บริษัทอาจมีขั้นตอนการทำงานเฉพาะของตัวเอง เช่น
Sales สร้างเอกสารในระบบหนึ่ง
Warehouse บันทึกข้อมูลอีกครั้งใน Excel
Accounting นำข้อมูลชุดเดียวกันไปกรอกในโปรแกรมบัญชี
Management ทำ Excel อีกชุดหนึ่งเพื่อสรุปรายงาน
ข้อมูลชุดเดียวกันจึงถูกสร้างและดูแลซ้ำหลายครั้ง
นี่คือปัญหาแบบเดียวกับที่หลัก DRY พยายามแก้ใน Software Development
ERP ที่ออกแบบดีจึงไม่ใช่เพียงการนำ Software ใหม่เข้ามาแทน Software เก่า แต่ควรลดการสร้างข้อมูลและ Business Logic ซ้ำซ้อนภายในองค์กรด้วย
ตัวอย่าง Flow ของ Odoo อาจเป็น
Quotation → Sales Order → Delivery → Invoice → Payment → Accounting
ข้อมูลจาก Sales Order ไม่จำเป็นต้องถูกพิมพ์ใหม่ทุกขั้นตอน แต่สามารถไหลต่อไปยัง Inventory, Accounting และ Reporting ได้
นี่คือ DRY ในระดับ Business Process และ Enterprise Data
ปัญหาเกิดขึ้นเมื่อ ERP ถูก Custom มากเกินไป
Customization ไม่ใช่สิ่งที่ผิด
ในหลายธุรกิจ Customization เป็นสิ่งจำเป็น เพราะแต่ละองค์กรมี Competitive Advantage, Business Rules หรือข้อกำหนดเฉพาะที่ Software Standard ไม่สามารถรองรับได้ทั้งหมด
ปัญหาเกิดขึ้นเมื่อทุก Requirement ถูกตีความว่าเป็น Requirement สำหรับการพัฒนา Software
ตัวอย่างเช่น ผู้ใช้งานบอกว่า
“ระบบเดิมของเรามีหน้าจอแบบนี้”
แล้ว Implementation Team สร้างหน้าจอใหม่ใน Odoo ให้เหมือนระบบเดิมทันที
คำถามที่ควรถามก่อนคือ
ทำไม Process เดิมจึงถูกออกแบบแบบนั้น?
และ
Odoo Standard มีวิธีแก้ Business Problem เดียวกันอยู่แล้วหรือไม่?
หาก Odoo มี Standard Workflow ที่สามารถตอบโจทย์ได้ การสร้าง Module ใหม่ขึ้นมาเพื่อทำสิ่งเดียวกันอาจกลายเป็นการ “Repeat” สิ่งที่ ERP มีอยู่แล้ว
เราอาจเรียกปัญหานี้ว่า
Don’t Repeat the ERP.
จาก DRY สู่ Standard-First
แนวทาง Standard-First ของ IMOTIF จึงไม่ได้หมายความว่า
“ห้าม Custom Odoo”
แต่หมายความว่า
ใช้ Standard ให้เต็มความสามารถก่อน และ Custom เฉพาะส่วนที่สร้างคุณค่าทางธุรกิจหรือมีความจำเป็นจริง
ก่อนพัฒนา Requirement หนึ่ง IMOTIF จะพิจารณาเป็นลำดับดังนี้
Business Requirement → Odoo Standard → Configuration → Process Adjustment → Integration → Customization
กล่าวคือ เราเริ่มต้นจากการทำความเข้าใจว่า Business ต้องการผลลัพธ์อะไร ไม่ใช่เพียงต้องการหน้าจอหรือปุ่มอะไร
จากนั้นจึงตรวจสอบว่า Odoo Standard รองรับหรือไม่
หากรองรับ เราจะพิจารณา Configuration ก่อน
หาก Standard Process แตกต่างจาก Process ปัจจุบันเล็กน้อย เราจะพิจารณาว่าองค์กรสามารถปรับ Process เข้าหา Best Practice ของระบบได้หรือไม่
หากข้อมูลหรือความสามารถอยู่ในระบบอื่นอยู่แล้ว การ Integration อาจเหมาะสมกว่าการสร้างใหม่
และเมื่อวิธีเหล่านี้ไม่สามารถตอบ Business Requirement ได้เพียงพอ จึงเข้าสู่ Customization
ตัวอย่าง: ลูกค้าต้องการ Approval Workflow
สมมติองค์กรมี Requirement ว่า Purchase Order มากกว่า 500,000 บาท ต้องได้รับอนุมัติก่อน
วิธีคิดแบบ Custom-First อาจเริ่มจาก
“สร้าง State ใหม่ เพิ่มปุ่ม Approve เพิ่มสิทธิ์ User และเขียน Logic”
แต่ Standard-First จะเริ่มจากการตรวจสอบก่อนว่า Odoo มี Approval หรือ Purchase Approval Mechanism ที่สามารถ Configuration ให้ตอบ Requirement ได้หรือไม่
ถ้า Standard ทำได้ 90% และอีก 10% เป็นเพียงการปรับ Process เล็กน้อย การ Custom ระบบทั้งหมดอาจไม่ใช่ทางเลือกที่เหมาะสมที่สุด
ในทางกลับกัน หากบริษัทมี Approval Matrix ซับซ้อน เช่น
Amount + Department + Project + Product Category + Budget Owner
และ Standard ไม่สามารถรองรับ Business Control ที่จำเป็นได้ การ Custom ในกรณีนี้ก็มีเหตุผลทางธุรกิจชัดเจน
ดังนั้นคำถามไม่ใช่
Custom หรือไม่ Custom
แต่คือ
Customization นี้สร้าง Business Value มากกว่าต้นทุนและ Technical Debt ที่เพิ่มขึ้นหรือไม่
Customization ทุกบรรทัดมีต้นทุนในอนาคต
ต้นทุนของ Customization ไม่ได้จบในวันที่ Development เสร็จ
Code ที่เพิ่มเข้ามาจะต้องถูก
Maintain
Test
Debug
Document
Secure
และตรวจสอบ Compatibility เมื่อ Upgrade Odoo Version
ยิ่งระบบ Custom มากเท่าไร จำนวนสิ่งที่องค์กรต้องดูแลในระยะยาวก็มีแนวโน้มเพิ่มขึ้นตามไปด้วย
ดังนั้น Manday Development 10 วันในวันนี้ ไม่ได้หมายความว่าต้นทุนของ Requirement นั้นมีเพียง 10 วันตลอดอายุระบบ
นี่คือเหตุผลที่ IMOTIF มอง Maintainability และ Upgradeability เป็นส่วนหนึ่งของ ERP Architecture ตั้งแต่วันแรก
Standard-First ไม่ได้แปลว่า Generic-First
อีกความเข้าใจผิดที่พบได้คือ หากใช้ Standard มาก ระบบจะไม่เหมาะกับธุรกิจของเรา
ในความเป็นจริง เราควรแยก Requirement ออกเป็นสองประเภท
Commodity Process คือกระบวนการที่แทบทุกองค์กรต้องมี เช่น Accounting, Purchasing, Inventory Movement, User Permission หรือพื้นฐานของ Sales Process
กับ
Differentiating Process คือกระบวนการที่ทำให้ธุรกิจแตกต่างจากคู่แข่ง เช่น Pricing Model เฉพาะ, Production Formula, Project Cost Control, Commission Logic หรือ Customer Experience บางประเภท
เราไม่จำเป็นต้องลงทุนสร้าง Software ใหม่เพื่อทำ Commodity Process ทุกอย่าง
แต่ควรเก็บงบประมาณและ Development Capacity ไว้กับส่วนที่สร้างความแตกต่างให้ธุรกิจ
นี่เป็นแนวคิดเดียวกับ Software Engineering ที่ Developer ไม่ควรเขียนทุก Library ขึ้นมาใหม่ด้วยตัวเอง
Reuse what is proven. Build what makes you different.
Single Source of Truth สำคัญกว่าแค่ลด Code
DRY ในบริบทของ ERP ยังมีอีกมิติหนึ่งที่สำคัญมาก คือ Data
องค์กรจำนวนมากไม่ได้มีปัญหาเพราะไม่มีข้อมูล แต่มีปัญหาเพราะมีข้อมูลเดียวกันหลายชุด
Sales มี Excel ของตัวเอง
Warehouse มีอีกไฟล์
Accounting มีอีกระบบ
Management มี Dashboard อีกชุด
สุดท้ายคำถามง่าย ๆ อย่าง
“ยอดขายจริงเดือนนี้เท่าไร?”
อาจได้คำตอบหลายตัวเลข
ERP Architecture ที่ดีจึงควรพยายามทำให้ข้อมูลหลักมี Source ที่ชัดเจน และให้ระบบอื่น Consume หรือ Integrate จาก Source นั้น แทนการสร้าง Master Data หรือ Business Logic ซ้ำโดยไม่จำเป็น
แนวคิดนี้ยิ่งสำคัญมากขึ้นในยุค AI
เพราะ AI ที่ฉลาดเพียงใดก็ไม่สามารถสร้างคำตอบทางธุรกิจที่น่าเชื่อถือได้ หาก Source Data ข้างหลังไม่สอดคล้องกัน
Standard-First จึงเป็น Foundation ของ AI-Ready ERP
เมื่อองค์กรต้องการต่อยอด ERP ไปสู่ AI, Automation หรือ AI Agent ปัญหาที่สำคัญไม่ได้อยู่ที่ว่าเลือก Large Language Model ตัวไหนเพียงอย่างเดียว
แต่คือ
AI จะเชื่อข้อมูลชุดไหน?
หาก Customer, Product, Inventory, Cost และ Accounting มีหลาย Source และมี Logic ซ้ำกัน AI จะต้องรับมือกับความไม่สอดคล้องเหล่านั้นด้วย
ในทางกลับกัน หาก ERP ถูกออกแบบให้มี Business Process และ Data Structure ที่ชัดเจน การต่อยอดไปสู่ AI จะง่ายขึ้น
ตัวอย่างเช่น AI สามารถตอบคำถาม
“สินค้าตัวไหน Stock ต่ำกว่าระดับที่ควรมี?”
“Project ไหนเริ่มมี Cost เกิน Budget?”
“ลูกค้ารายไหนมียอดขายลดลงจากไตรมาสก่อน?”
หรือ
“Invoice ไหนเลยกำหนดชำระแล้ว?”
ได้อย่างมีบริบทมากขึ้น เพราะ AI ไม่ได้ทำงานอยู่เหนือข้อมูลที่กระจัดกระจายโดยไม่มี Source ที่ชัดเจน
สำหรับ IMOTIF เราจึงมองว่า AI Transformation เริ่มต้นจาก Data และ Process Architecture ที่ดี
ไม่ใช่เริ่มจาก Chatbot
วิธีที่ IMOTIF ใช้พิจารณา Odoo Customization
ก่อนตัดสินใจพัฒนา Requirement เราพยายามตอบคำถามสำคัญ เช่น
- Odoo Standard รองรับ Requirement นี้อยู่แล้วหรือไม่?
- สามารถแก้ด้วย Configuration ได้หรือไม่?
- สามารถปรับ Business Process โดยไม่กระทบ Operation ได้หรือไม่?
- Requirement นี้เป็น Competitive Advantage หรือเป็นเพียง Process เดิมที่องค์กรคุ้นเคย?
- สามารถ Integration กับระบบที่ทำหน้าที่นี้ได้ดีอยู่แล้วหรือไม่?
- หากต้อง Custom จริง จะกระทบ Maintenance และ Version Upgrade อย่างไร?
- Business Value ที่ได้คุ้มกับ Total Cost of Ownership หรือไม่?
เมื่อผ่านคำถามเหล่านี้แล้วจึงควรตัดสินใจว่าจะ Use Standard, Configure, Integrate หรือ Customize
ERP Implementation ที่ดีไม่ควรวัดจากจำนวน Feature ที่สร้าง
โครงการ ERP บางโครงการอาจดูน่าประทับใจเพราะมี Custom Module จำนวนมาก
แต่จำนวน Customization ไม่ได้เป็นตัววัดคุณภาพของ Implementation
บางครั้งระบบที่มี Custom Code น้อยกว่า แต่ผู้ใช้งานสามารถทำงานได้ครบ ข้อมูลเชื่อมโยงกัน และสามารถ Upgrade Version ได้ง่ายกว่า อาจเป็น Architecture ที่ดีกว่าในระยะยาว
สำหรับ IMOTIF เราจึงไม่ได้ตั้งเป้าว่า
“จะเขียน Odoo ให้ได้มากที่สุด”
แต่ตั้งคำถามว่า
“เราจะใช้ Odoo ให้เกิดประโยชน์สูงสุด โดยสร้างสิ่งใหม่เฉพาะจุดที่ธุรกิจต้องการจริงได้อย่างไร?”
นี่คือความสัมพันธ์ระหว่างหลักการ DRY — Don’t Repeat Yourself ใน Software Development กับแนวคิด Standard-First Odoo Implementation ที่เราใช้ในการออกแบบระบบ ERP
เพราะ Software ที่ดีไม่ใช่ Software ที่มี Code มากที่สุด
และ ERP ที่ดี ก็ไม่ใช่ ERP ที่ Custom มากที่สุดเช่นกัน
Use the Standard. Extend with Purpose. Build for the Long Term.
ต้องการประเมินว่า Odoo ของคุณ Custom มากเกินไปหรือไม่?
หากองค์กรของคุณใช้งาน Odoo อยู่แล้ว แต่พบปัญหา เช่น ระบบ Custom จำนวนมาก, Upgrade Version ยาก, Workflow ซับซ้อน, Partner เดิมไม่ได้ดูแลต่อ หรือไม่แน่ใจว่าสิ่งที่พัฒนาไปสามารถใช้ Odoo Standard ทดแทนได้หรือไม่
IMOTIF มีบริการ Odoo Audit & Assessment เพื่อวิเคราะห์ Existing System, Business Process, Customization และแนวทางปรับปรุงระบบ โดยยึดหลัก Standard-First
เป้าหมายไม่ใช่การลด Customization ให้เหลือศูนย์ แต่คือการทำให้ทุก Customization ที่ยังอยู่ในระบบ มีเหตุผลทางธุรกิจที่ชัดเจนและคุ้มค่าที่จะดูแลต่อไป
IMOTIF — Odoo ERP, Software Engineering & AI Integration
