โครงการ ERP ที่ล้มเหลวมักไม่ได้ล้มตอนเขียนโค้ด แต่ล้มตั้งแต่ยังไม่เริ่ม เพราะเตรียมตัวไม่พอ เช็กลิสต์นี้รวมสิ่งที่เราอยากให้ลูกค้าทุกรายเตรียมก่อนคิกออฟ
ใครต้องทำอะไร ตกลงกันก่อน
โครงการ ERP ล้มเพราะความคลุมเครือเรื่องบทบาทมากกว่าเรื่องเทคนิค ตารางนี้ใช้เป็นจุดตั้งต้นได้
| งาน | ฝั่งคุณ | ฝั่งผู้ให้บริการ |
|---|---|---|
| ตัดสินใจเรื่องกระบวนการธุรกิจ | รับผิดชอบ | ให้คำแนะนำ |
| ออกแบบระบบและเอกสารออกแบบ | ตรวจและอนุมัติ | รับผิดชอบ |
| ทำความสะอาดข้อมูลตั้งต้น | รับผิดชอบ | ให้เทมเพลตและตรวจ |
| ตั้งค่าระบบและพัฒนาเพิ่ม | ตรวจรับ | รับผิดชอบ |
| ทดสอบ UAT | รับผิดชอบ | เตรียมสภาพแวดล้อมและแก้บั๊ก |
| อบรมผู้ใช้ | จัดคนและเวลา | รับผิดชอบ |
| ตัดสินใจว่าพร้อม Go-Live หรือไม่ | รับผิดชอบ | ให้ข้อมูลประกอบ |
| ดูแลหลัง Go-Live | แจ้งปัญหา | รับผิดชอบ ตาม SLA |
สังเกตว่างานที่ตัดสินใจเรื่องธุรกิจเป็นของคุณทั้งหมด ผู้ให้บริการที่ดีจะไม่ตัดสินใจแทน และถ้าเจอเจ้าที่ยินดีตัดสินใจให้ทุกเรื่อง นั่นคือสัญญาณอันตราย ไม่ใช่บริการที่ดี
ก่อนเริ่มโครงการ
1. ระบุปัญหาที่ต้องแก้เป็นข้อ ๆ
เขียนออกมาเป็นประโยคที่วัดได้ เช่น “ปิดงบใช้เวลา 25 วัน อยากลดเหลือ 10 วัน” หรือ “สต๊อกในระบบต่างจากของจริงเกิน 8%” ไม่ใช่ “อยากได้ระบบที่ทันสมัย” เพราะข้อความแบบหลังวัดผลไม่ได้และทำให้ขอบเขตบานปลาย
2. ตั้งเจ้าของโครงการหนึ่งคน
ต้องเป็นคนที่รู้ธุรกิจ มีเวลาให้โครงการอย่างน้อย 30% ของเวลางาน และมีอำนาจตัดสินใจแทนบริษัทได้ ถ้าทุกเรื่องต้องรอเจ้าของบริษัทที่ยุ่งตลอด โครงการจะยืดออกไปเรื่อย ๆ
3. ตั้งตัวแทนจากทุกแผนกที่เกี่ยวข้อง
ให้คนที่ ทำงานจริง เข้าร่วม ไม่ใช่แค่หัวหน้าแผนก เพราะคนที่คีย์ข้อมูลทุกวันจะรู้ข้อยกเว้นที่หัวหน้าไม่รู้ และคนกลุ่มนี้แหละที่จะเป็นคนบอกว่าระบบใหม่ใช้ได้จริงหรือไม่
4. ตัดสินใจเรื่องเวอร์ชันและการโฮสต์
เลือกระหว่าง Community กับ Enterprise และเลือกว่าจะใช้คลาวด์หรือติดตั้งเอง สองเรื่องนี้ส่งผลกับสถาปัตยกรรมทั้งโครงการ จึงควรจบก่อนเริ่ม อ่านเพิ่มที่ Odoo Community vs Enterprise
5. กำหนดขอบเขตเฟสแรกให้แคบ
เลือกโมดูลที่แก้ปัญหาเจ็บที่สุด 2–3 โมดูล อย่าพยายามทำทุกอย่างพร้อมกัน เฟสแรกที่สำเร็จภายใน 3 เดือนสร้างความเชื่อมั่นได้มากกว่าเฟสใหญ่ที่ลากยาว 1 ปี
6. จัดระเบียบข้อมูลตั้งต้น
เตรียมและทำความสะอาดข้อมูลเหล่านี้ล่วงหน้า
- รายชื่อลูกค้าและผู้ขาย พร้อมเลขประจำตัวผู้เสียภาษีและที่อยู่ที่ถูกต้อง
- รหัสสินค้า ชื่อ หน่วยนับ และราคาขาย
- ยอดคงเหลือสต๊อกล่าสุดพร้อมต้นทุน
- ลูกหนี้และเจ้าหนี้คงค้าง
- ผังบัญชีและยอดยกมา
ทุกชั่วโมงที่ใช้ทำความสะอาดข้อมูลตอนนี้ ประหยัดเวลาโครงการได้หลายเท่า
ระหว่างโครงการ
7. ยึดกระบวนการมาตรฐานก่อน
ทุกครั้งที่ขอปรับแต่ง ให้ถามว่า “ถ้าเราทำตามวิธีมาตรฐานของ Odoo จะเสียอะไร” หลายครั้งคำตอบคือไม่เสียอะไรเลย นอกจากความเคยชิน การปรับแต่งทุกจุดคือต้นทุนทั้งตอนทำและตอนอัปเกรด
8. บันทึกทุกข้อตกลงเป็นเอกสาร
สิ่งที่คุยกันในห้องประชุมแล้วไม่ได้เขียนไว้ จะกลายเป็นข้อขัดแย้งในภายหลังเสมอ ควรมีเอกสารออกแบบระบบที่ทั้งสองฝ่ายเซ็นรับก่อนเริ่มพัฒนา
9. ทดสอบด้วยข้อมูลจริง
การทดสอบด้วยข้อมูลสมมติจะไม่เจอปัญหาจริง ให้ใช้เอกสารจริงของเดือนที่ผ่านมา แล้วเดินให้ครบวงจรตั้งแต่ใบเสนอราคาจนถึงรับชำระและลงบัญชี
UAT ที่ได้ผลทำอย่างไร
การทดสอบที่คนส่วนใหญ่ทำคือเปิดหน้าจอทีละหน้าแล้วดูว่าปุ่มกดได้ไหม ซึ่งไม่เจอปัญหาจริงเลย
ทดสอบเป็นกระบวนการ ไม่ใช่เป็นหน้าจอ เลือกเอกสารจริงของเดือนที่ผ่านมามา 10–20 ชุด แล้วเดินให้ครบวงจร ตั้งแต่ใบเสนอราคา ใบสั่งขาย จัดของ ส่งของ ออกใบกำกับภาษี รับชำระ จนถึงรายการบัญชี แล้วเทียบตัวเลขปลายทางกับของจริง
ต้องทดสอบเคสยกเว้นด้วย เพราะนี่คือที่ที่ระบบพัง ไม่ใช่เคสปกติ
- ลูกค้าจ่ายบางส่วน แล้วจ่ายส่วนที่เหลือเดือนถัดไป
- ลูกค้าคืนของบางรายการหลังออกใบกำกับภาษีแล้ว
- ส่งของไม่ครบ ต้องทยอยส่ง
- ให้ส่วนลดพิเศษที่ไม่อยู่ในรายการราคา
- ยกเลิกเอกสารที่อนุมัติไปแล้ว
- จ่ายเงินให้ผู้ขายรวมหลายใบในเช็คใบเดียว พร้อมหักภาษี ณ ที่จ่าย
ให้คนที่ทำงานจริงเป็นคนทดสอบ ไม่ใช่หัวหน้าหรือฝ่ายไอที เพราะคนที่คีย์ทุกวันจะสะดุดกับสิ่งที่คนอื่นมองข้าม
บันทึกผลเป็นลายลักษณ์อักษร ว่าเคสไหนผ่าน เคสไหนไม่ผ่านและเพราะอะไร รายการนี้คือเกณฑ์ตัดสินว่าพร้อม Go-Live หรือยัง ไม่ใช่ความรู้สึก
10. วางแผนอบรมแยกตามบทบาท
เซลล์ไม่ต้องเรียนการปิดงบ และบัญชีไม่ต้องเรียนการจัดของ อบรมแยกตามหน้าที่ใช้เวลาน้อยกว่าและได้ผลกว่าการรวมทุกคนไว้ห้องเดียว ควรมีคู่มือสั้น ๆ และวิดีโอให้ทบทวนด้วย
ก่อนและหลัง Go-Live
11. เตรียมแผนวันขึ้นระบบ
ต้องตอบให้ได้ว่า
- ตัดยอดข้อมูลเก่าวันไหน
- ระหว่างช่วงเปลี่ยนผ่านจะออกเอกสารจากระบบไหน
- ใครเป็นผู้อนุมัติว่าข้อมูลยกมาถูกต้อง
- ถ้าเกิดปัญหาใหญ่ แผนสำรองคืออะไร
12. กำหนดเกณฑ์วัดความสำเร็จ
ตกลงกันตั้งแต่ต้นว่าอะไรคือ “สำเร็จ” เช่น ออกใบกำกับภาษีจากระบบได้ 100% ภายในเดือนแรก หรือความคลาดเคลื่อนของสต๊อกต่ำกว่า 2% ภายในไตรมาสแรก การมีตัวเลขทำให้ทุกฝ่ายรู้ว่าโครงการจบเมื่อไร
เวลาและงบไปอยู่ตรงไหน
ตัวเลขนี้เป็นสัดส่วนโดยประมาณจากโครงการขนาด SME ที่ขอบเขตชัดเจน ใช้เป็นกรอบตรวจว่าใบเสนอราคาที่ได้มาสมเหตุสมผลไหม
| กิจกรรม | สัดส่วนเวลาโครงการ | หมายเหตุ |
|---|---|---|
| วิเคราะห์กระบวนการและออกแบบ | 20–25% | ตัดตรงนี้แล้วจะไปเจ็บทีหลัง |
| ตั้งค่าระบบ | 15–20% | |
| พัฒนาเพิ่มและเอกสารไทย | 25–35% | ก้อนที่แปรผันมากที่สุด |
| ย้ายข้อมูล | 10–15% | ขึ้นกับความสะอาดของข้อมูลเดิม |
| ทดสอบ UAT | 10–15% | มักถูกบีบให้สั้นลงเป็นอย่างแรก |
| อบรม | 10–15% | ห้ามตัด |
ถ้าใบเสนอราคาไหนมีสัดส่วนวิเคราะห์และอบรมรวมกันต่ำกว่า 20% ให้ถามกลับว่าตัดอะไรออกไป เพราะสองก้อนนี้คือสิ่งที่แยกการวางระบบออกจากการติดตั้งซอฟต์แวร์
แผนวัน Go-Live แบบชั่วโมงต่อชั่วโมง
ข้อ 11 บอกว่าต้องมีแผน ส่วนนี้คือหน้าตาของแผนที่ใช้ได้จริง ปรับตามธุรกิจคุณได้
| ช่วงเวลา | ทำอะไร | ใครรับผิดชอบ |
|---|---|---|
| ก่อน 7 วัน | หยุดสร้างข้อมูลหลักใหม่ในระบบเก่า | หัวหน้าแต่ละแผนก |
| ก่อน 3 วัน | นับสต๊อกจริงทั้งคลัง | ฝ่ายคลัง |
| ก่อน 1 วัน | สำรองฐานข้อมูลทั้งสองระบบ ทดสอบกู้คืน | ผู้ให้บริการ |
| วัน Go-Live เช้า | นำเข้ายอดคงเหลือชุดสุดท้าย | ผู้ให้บริการ |
| วัน Go-Live เที่ยง | บัญชีตรวจงบทดลอง เซ็นรับ | ฝ่ายบัญชี |
| วัน Go-Live บ่าย | เปิดให้ใช้จริง ทีมประกบหน้างาน | ทุกฝ่าย |
| สิ้นวัน | ตรวจว่าเอกสารที่ออกวันนี้ถูกต้องทุกใบ | เจ้าของโครงการ |
ข้อที่คนลืมบ่อยที่สุดคือข้อแรก ถ้ายังเปิดลูกค้าใหม่หรือสินค้าใหม่ในระบบเก่าจนถึงวันสุดท้าย ข้อมูลที่นำเข้าไปแล้วจะไม่ครบ แล้วต้องมาไล่เก็บทีหลัง
30 วันแรกหลัง Go-Live
โครงการไม่ได้จบที่วันขึ้นระบบ ช่วงนี้คือช่วงที่ตัดสินว่าระบบจะถูกใช้จริงหรือถูกทิ้ง
สัปดาห์ที่ 1 มีคนตอบคำถามได้ทันทีอยู่หน้างาน ไม่ใช่ให้ส่งอีเมลรอ คำถามส่วนใหญ่เป็นเรื่องเล็กที่ถ้าไม่มีคนตอบภายในสิบนาที พนักงานจะเลิกใช้แล้วกลับไปใช้ Excel
สัปดาห์ที่ 2 เริ่มเก็บรายการสิ่งที่ต้องปรับ แยกเป็นสามกอง คือ บั๊กที่ต้องแก้ทันที ความไม่สะดวกที่รอได้ และคำขอฟีเจอร์ใหม่ที่ต้องเข้าคิวเฟสถัดไป การแยกสามกองนี้ป้องกันขอบเขตบานปลายได้ดีที่สุด
สัปดาห์ที่ 3 ปิดงบเดือนแรกด้วยระบบใหม่ โดยมีผู้ให้บริการประกบ นี่คือบททดสอบจริงที่ควรเผื่อเวลาไว้มากกว่าปกติ
สัปดาห์ที่ 4 ทบทวนการอบรมรอบสอง ตอนนี้ทีมมีคำถามจริงแล้ว การอบรมรอบนี้ให้ผลตอบแทนสูงกว่ารอบแรกมาก แต่เป็นรอบที่ถูกตัดออกบ่อยที่สุด
จากนั้นวัดผลเทียบกับเกณฑ์ในข้อ 12 แล้วตัดสินว่าเฟสถัดไปควรทำอะไร
ความเสี่ยงที่ควรเขียนไว้ตั้งแต่วันแรก
| ความเสี่ยง | สัญญาณเตือน | ทำอะไรก่อนสาย |
|---|---|---|
| เจ้าของโครงการไม่มีเวลา | เลื่อนประชุมเกินสองครั้งติด | ยกระดับให้ผู้บริหารตัดสิน หรือเปลี่ยนคน |
| ขอบเขตบานปลาย | มีคำขอใหม่ทุกสัปดาห์ | ล็อกเอกสารออกแบบ ของใหม่เข้าคิวเฟส 2 |
| ข้อมูลเดิมสกปรกกว่าที่คาด | นำเข้าทดสอบแล้ว error เกิน 10% | หยุดพัฒนา ทุ่มคนไปทำความสะอาดก่อน |
| ทีมต่อต้านระบบใหม่ | คนไม่มาอบรม หรือยังใช้ Excel คู่ | หาสาเหตุจริง มักเป็นเพราะระบบทำบางอย่างไม่ได้ |
| ผู้ให้บริการส่งงานช้า | พลาดหมุดหมายแรก | คุยทันทีที่พลาดครั้งแรก อย่ารอครั้งที่สาม |
อย่ารอให้ปัญหาชัดเจนก่อนค่อยพูด ทุกความเสี่ยงในตารางนี้แก้ง่ายมากตอนเพิ่งเริ่ม และแก้ยากมากตอนผ่านไปสามเดือน
สิ่งที่ควรหลีกเลี่ยง
- ขึ้นระบบวันที่ 1 มกราคม พร้อมปิดงบปีเก่า ควรเลือกช่วงที่ทีมบัญชีว่างที่สุด
- ให้ที่ปรึกษาตัดสินใจเรื่องธุรกิจแทนคุณ เราแนะนำได้ แต่คนที่รู้ว่าธุรกิจต้องการอะไรคือคุณ
- ปล่อยให้ระบบเก่าและใหม่ทำงานคู่กันนาน ๆ เพราะสุดท้ายคนจะกลับไปใช้ของเก่า
- ตัดงบอบรมเป็นอย่างแรกเมื่อเงินไม่พอ ควรตัดขอบเขตโมดูลแทน
สรุป
ความสำเร็จของโครงการ Odoo วัดกันที่การเตรียมตัวมากกว่าความสามารถของซอฟต์แวร์ ถ้าคุณทำ 12 ข้อนี้ครบก่อนเริ่ม โอกาสที่โครงการจะจบตามเวลาและงบจะสูงขึ้นมาก
ถ้าจะเลือกทำแค่สามข้อจากทั้งหมด ให้เลือก ข้อ 2 (ตั้งเจ้าของโครงการ) ข้อ 5 (จำกัดขอบเขตเฟสแรก) และ ข้อ 6 (จัดระเบียบข้อมูล) สามข้อนี้อธิบายความต่างระหว่างโครงการที่จบตามแผนกับโครงการที่ลากยาวได้เกือบทั้งหมด
อยากให้เราช่วยประเมินความพร้อมของทีมคุณก่อนเริ่ม? นัดคุยกับเราได้ ครั้งแรกไม่มีค่าใช้จ่าย หรืออ่านต่อเรื่อง ย้ายข้อมูลจาก Excel มา Odoo ซึ่งลงรายละเอียดข้อ 6 และข้อ 11 อย่างละเอียด
คำถามที่พบบ่อย
โครงการ Odoo ล้มเหลวเพราะอะไรมากที่สุด?
จากที่เราเจอ สาเหตุอันดับหนึ่งไม่ใช่เรื่องเทคนิค แต่คือการไม่มีเจ้าของโครงการฝั่งลูกค้าที่มีอำนาจตัดสินใจ ทำให้ข้อสรุปเปลี่ยนไปมาและงานไม่จบ รองลงมาคือการเปิดโมดูลพร้อมกันมากเกินไปในเฟสแรก
ฝั่งเราต้องใช้คนกี่คนและกี่ชั่วโมง?
อย่างน้อยต้องมีเจ้าของโครงการหนึ่งคนที่ให้เวลาราว 30% ของเวลางานตลอดโครงการ และตัวแทนแต่ละแผนกที่ให้เวลาราว 10–15% ช่วงเก็บกระบวนการและช่วงทดสอบ UAT ตัวเลขนี้คือต้นทุนจริงที่ไม่อยู่ในใบเสนอราคา ถ้าไม่กันเวลาไว้ตั้งแต่ต้น โครงการจะยืดเพราะรอคำตอบจากฝั่งคุณ
UAT ต้องทดสอบอะไรบ้าง
ทดสอบเป็นกระบวนการเต็มวงจรด้วยเอกสารจริงของเดือนที่ผ่านมา ไม่ใช่ทดสอบทีละหน้าจอ เช่น ใบเสนอราคาไปจนถึงรับชำระและลงบัญชี แล้วเทียบตัวเลขปลายทางกับของจริง พร้อมทดสอบเคสยกเว้นที่เกิดจริงในธุรกิจ เช่น จ่ายบางส่วน คืนของ หรือส่วนลดพิเศษ
ควรใช้เวลาเตรียมตัวนานแค่ไหนก่อนเริ่ม?
โดยทั่วไป 2–4 สัปดาห์ก็เพียงพอสำหรับการจัดระเบียบข้อมูล ตั้งทีม และสรุปเป้าหมาย ซึ่งเป็นการลงทุนที่คุ้มมาก เพราะช่วยลดเวลาระหว่างโครงการได้มากกว่านั้นหลายเท่า