GO LIVE MDERP ระบบ ERP หลายบริษัท หลายสาขา แยกบัญชี สิทธิ์ และเอกสารตาม Branch
- โจทย์ของโครงการ GO LIVE
- รองรับ Multi-company และ Multi-branch
- กำหนดสิทธิ์ผู้ใช้งานตามบริษัทและสาขา
- เลขที่เอกสารแยกตาม Shop และ Branch
- บัญชีและข้อมูลทางการเงินแยกตามสาขา
- Sales และ Credit Limit
- Barcode, Serial Number และการติดตามสินค้า
- ปรับแบบฟอร์มเอกสารให้เหมาะกับองค์กร
- ขั้นตอนการ Implement จนถึง GO LIVE
- Business Value ที่ได้รับ
- VDO แนะนำ Multi-company บน MDERP
- คำถามที่พบบ่อย
- สรุป
องค์กรที่มี หลายบริษัทและหลายสาขา มักมี Requirement ที่ซับซ้อนกว่า ERP สำหรับบริษัทเดียว
ไม่ใช่เพียงการแยกข้อมูล ตาม Company แต่ยังต้องจัดการ Branch, User Permission, เลขที่เอกสาร, บัญชี, ลูกค้า, สินค้า, Stock และ Workflow ให้ตรงกับโครงสร้าง ขององค์กรจริง
โครงการนี้เป็นอีกหนึ่ง กรณีศึกษา GO LIVE ของทีม MDSoft ที่พัฒนาและต่อยอดระบบ ERP ให้รองรับ Multi-company และ Multi-branch พร้อม Requirement เฉพาะของลูกค้า ในหลายส่วน
ลูกค้ารายนี้ มีการใช้งาน ERP ร่วมกับ MDSoft อย่างต่อเนื่อง โดยเริ่มจาก Module พื้นฐาน ก่อนขยายขอบเขต และพัฒนาระบบเพิ่มเติม ตามการเติบโต ขององค์กร
แนวทางดังกล่าว เป็นหนึ่งในแนวคิดสำคัญ ของ ERP คือไม่จำเป็นต้อง เปิดทุก Feature ตั้งแต่วันแรก แต่สามารถวาง Roadmap และขยายระบบ ตาม Business Requirement ได้
หากต้องการดูภาพรวม MDERP สามารถอ่านเพิ่มเติมได้ที่ MDERP ระบบ ERP สำหรับธุรกิจไทย | ทางเลือก Odoo Enterprise จาก MDSoft
โจทย์ของโครงการ GO LIVE
Requirement หลัก ของโครงการนี้ คือการทำให้ระบบ ERP รองรับโครงสร้างองค์กร ที่มี หลายบริษัท และแต่ละบริษัท มีหลายสาขา
โดยแต่ละสาขา มีข้อมูลและข้อกำหนด บางส่วนที่ต้องแยกกัน ขณะที่ผู้บริหาร ยังต้องการให้ระบบ อยู่บน Platform เดียว เพื่อบริหารจัดการ และตรวจสอบข้อมูล ได้สะดวก
ขอบเขตที่พัฒนาขึ้น ครอบคลุม เช่น
- Multi-company
- Multi-branch
- บัญชีแยกตามสาขา
- User Permission ตามบริษัทและสาขา
- เลขที่เอกสารแยกตาม Shop / Branch
- เลข Invoice แยกตามสาขา
- Custom Print Form
- Credit Limit
- Barcode
- Serial Number
- วันหมดอายุ / วันรับประกันสินค้า
- Opening Balance
- Trial Balance
- รับชำระเงินเกิน
- Cheque Receive / Cheque Payment
รองรับ Multi-company และ Multi-branch
หนึ่งใน Requirement ที่สำคัญที่สุด คือการแยก Company ออกจาก Branch ให้ชัดเจน
เพราะหลายบริษัท ไม่ได้หมายความว่า แต่ละสาขา จะต้องเป็นบริษัท แยกกันเสมอไป
ในโครงการนี้ ระบบถูกออกแบบ ให้รองรับ หลายบริษัท และภายในแต่ละบริษัท สามารถมีหลายสาขา ตามโครงสร้าง ที่ลูกค้าใช้งานจริง
Company A → Branch A1 → Branch A2
Company B → Branch B1 → Branch B2
แนวทางนี้ ช่วยให้องค์กร สามารถแยก Transaction และข้อมูล ตามโครงสร้างจริง โดยไม่จำเป็นต้อง สร้างทุก Branch เป็น Company
สำหรับธุรกิจไทย เรื่อง Multi-company และ Multi-branch ควรวิเคราะห์แยกกัน เพราะมีผลต่อ Permission, Stock, Document, Payment, Accounting และ Reporting
กำหนดสิทธิ์ผู้ใช้งานตามบริษัทและสาขา
เมื่อระบบมี หลายบริษัท และหลายสาขา สิ่งที่ตามมาคือ Access Control
ผู้ใช้งานบางคน ควรเห็นข้อมูล เฉพาะสาขาของตัวเอง ขณะที่บางตำแหน่ง อาจดูข้อมูล ได้หลายสาขา หรือหลายบริษัท
ระบบจึงถูกปรับ ให้สามารถกำหนด ได้ว่า User
- ใช้งาน Company ใดได้บ้าง
- ใช้งาน Branch ใดได้บ้าง
- เห็น Transaction ของสาขาใด
- ทำรายการในสาขาใดได้
ช่วยลดความเสี่ยง จากการเปิดดู หรือบันทึก Transaction ผิดบริษัท หรือผิดสาขา
เลขที่เอกสารแยกตาม Shop และ Branch
เลขที่เอกสาร เป็นอีก Requirement ที่มีความสำคัญ สำหรับองค์กร ที่มีหลายสาขา
ลูกค้าต้องการ ให้เอกสารบางประเภท สามารถรันเลข แยกตาม Shop หรือ Branch
รวมถึง Invoice ที่สามารถกำหนด Sequence แยกตามสาขาได้
แนวทางนี้ ช่วยให้ การตรวจสอบเอกสาร และการค้นหา Transaction ย้อนหลัง สอดคล้องกับ โครงสร้างธุรกิจ มากขึ้น
บัญชีและข้อมูลทางการเงินแยกตามสาขา
ในด้าน Accounting ลูกค้าต้องการ ให้การบันทึกบัญชี สามารถสัมพันธ์ กับ Branch ของ Transaction
นอกจากนี้ ยังมี Requirement ด้านข้อมูลทางบัญชี และการเงินเพิ่มเติม เช่น
- Opening Balance
- นำยอดยกมาเข้าระบบ
- นำข้อมูลไปใช้ใน Trial Balance
- รับชำระเงินเกินได้ตาม Workflow
- Cheque Receive
- Cheque Payment
ทำให้ข้อมูล การขาย, การรับเงิน และ Accounting สามารถทำงาน ต่อเนื่องกันได้ มากขึ้น
สำหรับ MDERP ปัจจุบันมีการพัฒนา ความสามารถด้าน Accounting Thailand เพิ่มเติมอีกหลายส่วน
อ่านรายละเอียดได้ที่ Odoo Accounting Thailand ระบบบัญชีไทยครบวงจร | MDERP by MDSoft
Sales และ Credit Limit
สำหรับงานขาย มี Requirement ด้าน Credit Limit ของลูกค้า
ระบบสามารถกำหนด วงเงินเครดิต สำหรับลูกค้า แต่ละราย เพื่อใช้เป็นข้อมูล ในการควบคุม การเปิด Order หรือ Transaction ตาม Workflow ที่องค์กรกำหนด
แนวคิดนี้ ช่วยให้ฝ่ายขาย สามารถใช้ข้อมูล ด้านเครดิต ร่วมกับข้อมูลลูกค้า ได้ภายใน ERP แทนการตรวจสอบ จากเอกสาร หรือระบบแยก
Barcode, Serial Number และการติดตามสินค้า
ในส่วนสินค้า มีการพัฒนา ให้รองรับ การสร้าง Barcode และค้นหาสินค้า จาก Barcode
ช่วยให้ผู้ใช้งาน ค้นหา Product ได้สะดวกขึ้น โดยเฉพาะ ธุรกิจที่มีสินค้า จำนวนมาก
Serial Number
สินค้าแต่ละชิ้น ยังสามารถใช้ Serial Number เพื่อระบุตัวสินค้า แบบรายชิ้น
Requirement ของโครงการ มีการนำ Serial Number ไปใช้ร่วมกับข้อมูล เช่น
- วันหมดอายุ
- วันรับประกันสินค้า
- การตรวจสอบข้อมูลของสินค้าแต่ละชิ้น
รวมถึง การเชื่อมไปยัง ระบบ Web สำหรับตรวจสอบข้อมูล ตาม Workflow ของโครงการ
ปรับแบบฟอร์มเอกสารให้เหมาะกับองค์กร
รูปแบบเอกสาร ของแต่ละองค์กร มักมี Requirement แตกต่างกัน
ในโครงการนี้ ลูกค้าต้องการ ความยืดหยุ่น ในการกำหนด รูปแบบเอกสาร ด้วยตัวเอง
จึงมีการออกแบบ การเชื่อมกับ OpenOffice สำหรับการจัดการ Print Template ตามสถาปัตยกรรม ของระบบที่ใช้งาน ในโครงการ
ช่วยให้ รูปแบบเอกสาร สามารถปรับ ให้สอดคล้องกับ การใช้งานขององค์กร ได้มากขึ้น
ขั้นตอนการ Implement จนถึง GO LIVE
การ Customize ERP ไม่ควรเริ่มจาก การเข้าไปแก้ระบบทันที เมื่อได้รับ Requirement
ทีม MDSoft ใช้กระบวนการพัฒนา ตามแนวทาง Software Development Life Cycle เพื่อให้ Requirement, Design, Development และ Testing เป็นไปในทิศทางเดียวกัน
Requirement Gathering → Business Analysis → Solution Design → Development / Configuration → Internal Test → Demo → UAT → Training → GO LIVE → Support
1. Requirement Gathering
เริ่มจาก การเก็บรายละเอียด ของ Business Process และ Requirement จากผู้ใช้งาน
2. Business Analysis
ทีมงานวิเคราะห์ว่า Requirement ใด สามารถใช้ Standard ERP ได้ และ Requirement ใด จำเป็นต้องพัฒนา เพิ่มเติม
3. Solution Design
ออกแบบ Workflow, Data Structure และรูปแบบ การทำงาน ให้ตรงกับ Business Process ของลูกค้า
4. Development และ Configuration
ใช้ระบบ ERP ที่มีอยู่เป็นฐาน และพัฒนา Feature เพิ่ม เฉพาะส่วน ที่จำเป็น
5. Testing
หลังพัฒนาเสร็จ ทีมงานทำการทดสอบ เพื่อให้มั่นใจว่า ระบบทำงาน ตาม Requirement ที่ตกลงกันไว้
6. Demo และ UAT
นำระบบ ให้ผู้ใช้งานจริง ตรวจสอบ และยืนยัน ก่อนเปิดใช้งาน
7. Training
จัดทำ คู่มือ, Video หรือ Remote Training ตามความเหมาะสม เพื่อเตรียมผู้ใช้งาน ก่อน GO LIVE
8. GO LIVE และ Support
เมื่อระบบ ผ่านการยืนยันแล้ว จึงเปิดใช้งานจริง และติดตาม การใช้งาน หลัง GO LIVE
Business Value ที่ได้รับ
| โจทย์ | แนวทางระบบ | Business Value |
|---|---|---|
| องค์กรมีหลายบริษัท | Multi-company | บริหารข้อมูลหลายบริษัทบน ERP เดียว |
| แต่ละบริษัทมีหลายสาขา | Multi-branch | แยก Transaction ตามโครงสร้างจริง |
| User ไม่ควรเห็นทุกสาขา | Branch Permission | ลดความเสี่ยงจากการเข้าถึงข้อมูลผิดขอบเขต |
| เลขที่เอกสารต้องแยก | Sequence by Shop / Branch | ตรวจสอบและค้นหาเอกสารได้ง่ายขึ้น |
| ต้องควบคุมเครดิตลูกค้า | Credit Limit | ช่วยควบคุมความเสี่ยงด้านการขายเชื่อ |
| สินค้ามี Serial และ Warranty | Serial Tracking | ติดตามสินค้าแต่ละชิ้นได้ละเอียดขึ้น |
| ต้องรับ-จ่ายด้วยเช็ค | Cheque Receive / Payment | รองรับ Workflow การเงินของธุรกิจ |
| มีข้อมูลบัญชีเดิม | Opening Balance | นำยอดตั้งต้นเข้าสู่ระบบและใช้ต่อกับรายงานบัญชี |
VDO แนะนำ Feature Multi-company บน MDERP
สามารถดูตัวอย่าง การทำงานของ ระบบ ERP สำหรับองค์กร ที่มีหลายบริษัท และบริษัทลูก ได้จาก VDO ของ MDSoft ด้านล่าง
คำถามที่พบบ่อย
Multi-company กับ Multi-branch เหมือนกันหรือไม่?
ไม่เหมือนกัน
Multi-company ใช้กับกรณี ที่องค์กรมี หลายบริษัท หรือหลาย Legal Entity
ส่วน Multi-branch เป็นการบริหาร หลายสาขา ภายในโครงสร้าง ของบริษัท ตาม Requirement ที่กำหนด
Odoo รองรับหลายบริษัทได้หรือไม่?
Odoo มีความสามารถ Multi-company และสามารถนำมา ออกแบบต่อยอด เพื่อรองรับ Business Process ของกลุ่มบริษัทได้
สำหรับ Requirement ด้าน Branch, Accounting, Permission, Document และ Tax ควรวิเคราะห์ เพิ่มเติม ตามโครงสร้าง ของแต่ละองค์กร
MDERP รองรับหลายสาขาได้หรือไม่?
MDERP มี Module และ Workflow สำหรับ Multi-branch ที่ MDSoft พัฒนาต่อยอด จาก Odoo Community
สามารถออกแบบ ให้ Branch เชื่อมกับ Sales, Purchase, Inventory, Accounting, Payment, Document Sequence และ Permission ตาม Scope ที่ Implement
สามารถกำหนดสิทธิ์ให้ User เห็นเฉพาะสาขาตัวเองได้หรือไม่?
สามารถออกแบบ Branch Permission เพื่อจำกัด ข้อมูลและ Transaction ตามสาขา ที่ User ได้รับอนุญาต
เลข Invoice สามารถแยกตามสาขาได้หรือไม่?
สามารถออกแบบ Document Sequence แยกตาม Branch หรือโครงสร้าง ที่องค์กรกำหนด ได้
สามารถย้ายข้อมูลบัญชีเดิมเข้าระบบได้หรือไม่?
สามารถทำ Data Migration ตาม Scope เช่น Master Data, Opening Balance, AR, AP, Stock หรือข้อมูลอื่น ตามโครงสร้าง ของระบบเดิม
สรุป GO LIVE MDERP Multi-company และ Multi-branch
กรณีศึกษานี้ แสดงให้เห็นว่า การวางระบบ ERP สำหรับองค์กร ที่มีหลายบริษัท และหลายสาขา ไม่ได้จบเพียง การเปิดใช้ Multi-company
แต่ต้องออกแบบ ให้หลายส่วน ทำงานสัมพันธ์กัน เช่น
การเก็บ Requirement และเข้าใจ Business Process จริง จึงมีความสำคัญ ต่อการออกแบบระบบ ให้ใช้งานได้ ในระยะยาว
ประสบการณ์ จากโครงการ Multi-company และ Multi-branch ลักษณะนี้ ยังถูกนำมา พัฒนาต่อยอด เป็น Module และ Workflow ของ MDERP สำหรับธุรกิจไทย ในปัจจุบัน
องค์กรของคุณมีหลายบริษัทหรือหลายสาขา?
MDSoft สามารถช่วย วิเคราะห์โครงสร้าง Company, Branch, Warehouse, User Permission, Document, Payment และ Accounting เพื่อประเมินว่า ส่วนใดใช้ Standard Odoo, ส่วนใดมี MDERP Module พร้อมใช้ และส่วนใดควร Customize เพิ่มเติม
บทความที่เกี่ยวข้อง
- Odoo คืออะไร? ระบบ ERP ทำอะไรได้บ้าง และเหมาะกับธุรกิจแบบไหน
- MDERP ระบบ ERP สำหรับธุรกิจไทย | ทางเลือก Odoo Enterprise จาก MDSoft
- เปรียบเทียบ MDERP กับ Odoo Enterprise | Feature ERP สำหรับธุรกิจไทย
- Odoo Accounting Thailand ระบบบัญชีไทยครบวงจร | MDERP by MDSoft
- MDSoft Odoo Service บริการ Odoo และ MDERP ครบวงจร