ERP Custom เหมาะกับธุรกิจที่มีกระบวนการสำคัญซึ่งระบบมาตรฐานรองรับได้ไม่พอ ส่วน ERP สำเร็จรูปเหมาะเมื่อฟังก์ชันที่มีอยู่ครอบคลุมงานหลักและองค์กรปรับวิธีทำงานให้สอดคล้องกันได้ การตัดสินใจจึงควรเริ่มจากงานที่ต้องทำจริง ความพร้อมของข้อมูล และต้นทุนตลอดการใช้งาน มากกว่าดูจำนวนฟังก์ชันหรือราคาวันแรกเพียงอย่างเดียว
โจทย์ที่พบบ่อยคือฝ่ายขายมีเงื่อนไขราคาหลายระดับ คลังมีหน่วยนับต่างจากการขาย และฝ่ายบัญชีใช้โปรแกรมอีกตัวอยู่แล้ว หากเลือก ERP โดยดูเฉพาะหน้าจอสาธิต อาจพบภายหลังว่าพนักงานยังต้องใช้ Excel เป็นตัวกลาง บทความนี้ช่วยแยกว่าความต้องการใดตั้งค่าได้ ความต้องการใดควรปรับกระบวนการ และส่วนใดมีเหตุผลพอที่จะพัฒนาเพิ่ม
จุดตัดสินใจสำคัญ: ระบบที่เหมาะต้องรองรับงานตั้งแต่ต้นจนจบ และทีมต้องดูแลต่อได้ การมีฟังก์ชันมากไม่ได้ช่วย หากเอกสารยังหลุดระหว่างแผนก
ERP สำเร็จรูปและ ERP Custom ต่างกันอย่างไร
ERP สำเร็จรูปเป็นผลิตภัณฑ์ที่มีชุดฟังก์ชันและกติกาการทำงานให้เลือกใช้ตามรุ่น การตั้งค่า และส่วนเสริม ส่วน ERP Custom เป็นระบบที่ออกแบบหรือพัฒนาตามขอบเขตเฉพาะขององค์กร ทั้งสองแนวทางยังต้องทำงานวิเคราะห์ ตั้งค่า ย้ายข้อมูล ทดสอบ และอบรมผู้ใช้
ระบบมาตรฐานบางผลิตภัณฑ์ปรับแบบฟอร์ม ขั้นอนุมัติ และเชื่อมต่อข้อมูลได้มาก ขณะที่ระบบพัฒนาเฉพาะบางโครงการอาจมีขอบเขตเพียงงานขายและคลัง จึงไม่ควรตัดสินจากชื่อประเภท ให้ตรวจว่าความสามารถใดมีอยู่แล้ว ส่วนใดต้องซื้อเพิ่ม และส่วนใดต้องมีทีมพัฒนารับผิดชอบ
ERP Custom ไม่ได้หมายถึงต้องเขียนทุก Module ใหม่
ธุรกิจสามารถใช้โปรแกรมบัญชีหรือ ERP มาตรฐานในงานที่เหมาะสม แล้วพัฒนาส่วนเฉพาะ เช่น ระบบราคา Dealer หรือหน้าจอวางแผนผลิต เชื่อมกลับเข้าระบบหลักได้ แนวทางนี้เรียกได้ว่าเป็นระบบผสม ความคุ้มค่าขึ้นอยู่กับการแบ่งหน้าที่และต้นทุน Integration ของทั้งสองฝั่ง
เปรียบเทียบในเรื่องที่มีผลต่อการใช้งานจริง
| ประเด็น | ERP สำเร็จรูป | ERP Custom |
|---|---|---|
| กระบวนการ | ใช้ความสามารถมาตรฐานและการตั้งค่าของผลิตภัณฑ์ | ออกแบบตามกติกาที่ตกลงและทดสอบได้ |
| เริ่มใช้งาน | อาจเร็วเมื่อช่องว่างน้อยและข้อมูลพร้อม | ต้องเผื่อเวลาวิเคราะห์ ออกแบบ พัฒนา และตรวจรับ |
| ค่าใช้จ่าย | ตรวจค่าผู้ใช้ Module ส่วนเสริม และบริการ | ตรวจขอบเขตพัฒนา โครงสร้างพื้นฐาน และการดูแล |
| การอัปเดต | ตามรอบและนโยบายผู้ขาย ต้องทดสอบส่วนที่ปรับเพิ่ม | ต้องวางแผนอัปเดตระบบและส่วนประกอบเอง |
| การเชื่อมข้อมูล | ขึ้นกับ API สิทธิ์ใช้งาน และข้อจำกัดของรุ่น | ออกแบบการเชื่อมได้ตามขอบเขต แต่ยังมีข้อจำกัดปลายทาง |
| การเปลี่ยนผู้ดูแล | ตรวจสิทธิ์ส่งออกข้อมูลและเงื่อนไขคู่ค้า | ตรวจสิทธิ์ซอร์ส เอกสาร ระบบติดตั้ง และการส่งมอบ |
คำว่าเริ่มได้เร็วต้องมีเงื่อนไขประกอบ หากสินค้ามีรหัสซ้ำ ลูกค้าไม่มีรหัสกลาง หรือไม่มีคนตัดสินใจเรื่องขั้นอนุมัติ งานติดตั้งระบบมาตรฐานก็อาจล่าช้าได้ ในทางกลับกัน ระบบเฉพาะที่แบ่งขอบเขตระยะแรกชัดเจนสามารถเปิดใช้ทีละกระบวนการได้
ตรวจ Fit-Gap ด้วยงานจริงก่อนเลือก ERP
Fit-Gap คือการเปรียบเทียบกระบวนการที่ธุรกิจต้องใช้กับความสามารถของระบบที่กำลังพิจารณา ควรให้ผู้ขายหรือทีมพัฒนาสาธิตด้วยข้อมูลและข้อยกเว้นของธุรกิจ แทนการดูเฉพาะออร์เดอร์ที่ไม่มีปัญหา

เตรียมตัวอย่างหนึ่งรอบงานตั้งแต่รับคำสั่งซื้อ ตรวจเครดิต จองสินค้า ส่งบางส่วน ออกเอกสาร และรับคืน แล้วบันทึกผลเป็นสามกลุ่ม: ทำได้ตามมาตรฐาน ต้องตั้งค่าหรือปรับขั้นตอน และต้องพัฒนาเพิ่ม ระบุผลกระทบต่อฝ่ายอื่นด้วย เช่น การเปลี่ยนราคาย้อนหลังมีผลต่อบัญชีหรือยอดขายอย่างไร
- งานที่ต้องมี: หากทำไม่ได้จะรับออร์เดอร์ ส่งสินค้า หรือปิดงวดไม่ได้
- งานที่ช่วยลดภาระ: เช่น แจ้งเตือนติดตามเอกสารหรือกรอกข้อมูลอัตโนมัติ
- งานที่เลื่อนได้: รายงานเฉพาะรูปแบบที่ยังไม่จำเป็นต่อการเปิดใช้
- ข้อยกเว้น: การยกเลิก ส่งไม่ครบ คืนสินค้า หรือผู้อนุมัติไม่อยู่
ผลประเมินควรมีผู้รับผิดชอบและหลักฐาน ไม่ใช้คำว่า “ทำได้” โดยไม่มีรายละเอียดว่าต้องซื้ออะไรเพิ่ม ใช้เวลาเท่าไร และใครดูแลเมื่อผลิตภัณฑ์อัปเดต
ERP Custom กับการออกแบบ Workflow เฉพาะองค์กร
Workflow ที่ดีควรระบุสถานะ ผู้มีสิทธิ์เปลี่ยนสถานะ ข้อมูลที่ต้องมี และสิ่งที่เกิดขึ้นหลังการอนุมัติ เช่น ใบขอซื้อที่ผ่านอนุมัติแล้วจึงสร้าง PO ได้ แต่การอนุมัติขอซื้อยังไม่ใช่การรับสินค้าเข้าคลัง

ตัวอย่างสถานการณ์สมมติ: บริษัทค้าส่งมีราคาตามสัญญาลูกค้า วงเงินเครดิต และการส่งจากหลายคลัง หากกติกาเหล่านี้เป็นหัวใจของธุรกิจ ระบบเฉพาะอาจช่วยให้ฝ่ายขายทำงานจากหน้าจอเดียว แต่ต้องกำหนดว่าใครแก้ราคาได้ เมื่อเครดิตเกินต้องส่งให้ใคร และกรณีส่งบางส่วนจะเหลือยอดค้างอย่างไร
ข้อผิดพลาดคือย้ายข้อยกเว้นทุกอย่างจากวิธีทำงานเดิมเข้าระบบโดยไม่ทบทวน บางขั้นตอนเกิดขึ้นเพราะข้อมูลกระจัดกระจาย เมื่อมีข้อมูลกลางแล้วอาจลดงานได้ จึงควรออกแบบกระบวนการที่ต้องการใช้จริงก่อนกำหนดหน้าจอ
สถาปัตยกรรมของระบบผสมควรแบ่งหน้าที่อย่างไร
ระบบผสมต้องมีเจ้าของข้อมูลที่ชัดเจน เช่น ERP ดูแลคำสั่งขายและสินค้า โปรแกรมบัญชีดูแลรายการทางบัญชี ส่วนระบบขาย B2B ดูแลประสบการณ์ลูกค้า แต่รายการราคาที่ใช้ขายต้องมีแหล่งอ้างอิงเดียวกัน
เมื่อคำสั่งขายผ่านเงื่อนไข ระบบสร้างเอกสารและส่งข้อมูลให้ปลายทาง พร้อมรหัสอ้างอิงและสถานะการส่ง หากปลายทางไม่ตอบควรคงรายการไว้ในคิวและตรวจสอบก่อนส่งใหม่ การแบ่งขอบเขตแบบนี้ช่วยติดตามว่าปัญหาเกิดในงานขาย การส่งข้อมูล หรือการรับข้อมูลทางบัญชี
ควรตรวจตั้งแต่ต้นว่า API ปลายทางรองรับเอกสารใด มีค่าบริการ ข้อจำกัดการเรียก และสภาพแวดล้อมทดสอบหรือไม่ หากไม่มี API การส่งไฟล์ตามรูปแบบที่ควบคุมได้อาจเป็นทางเลือก แต่ความถี่และภาระตรวจสอบต่างจากการเชื่อมอัตโนมัติ
ตัวอย่าง Fit-Gap ที่ช่วยแยกเหตุผลการพัฒนา
สมมติบริษัทจัดจำหน่ายขายสินค้าตามราคาสัญญารายลูกค้า มีส่วนลดตามจำนวน และต้องตรวจเครดิตก่อนยืนยันออร์เดอร์ ให้ตรวจทีละเงื่อนไขว่าระบบมาตรฐานตั้งค่าได้หรือไม่ หากส่วนลดมาตรฐานทำได้อยู่แล้ว ไม่จำเป็นต้องเขียนกลไกราคาใหม่ทั้งชุด
ช่องว่างอาจอยู่เฉพาะการอนุมัติราคานอกสัญญาที่ต้องให้ผู้จัดการสองแผนกร่วมรับรอง ในกรณีนี้ให้เปรียบเทียบการปรับขั้นตอน การใช้ส่วนขยายที่รองรับ และการพัฒนาเฉพาะ พร้อมตรวจผลต่อเอกสารขาย การยกเลิก และรายงาน ไม่ประเมินเฉพาะฟอร์มขออนุมัติหนึ่งหน้า
ข้อสรุปที่ใช้งานได้ควรบอกว่า “ใช้มาตรฐานในงานใด พัฒนาเพิ่มในงานใด และตรวจผลอย่างไร” การเขียนเพียงว่า ERP เดิมยืดหยุ่นไม่พอ ยังไม่ละเอียดพอสำหรับประเมินขอบเขตหรืองบ
Workflow โครงการและหลักฐานตรวจรับ
เริ่มจากสำรวจปัญหาและข้อมูล ทำ Fit-Gap ออกแบบหน้าจอหรือ Prototype ที่เกี่ยวข้อง แล้วพัฒนาหรือตั้งค่าตามขอบเขตที่รับรอง จากนั้นให้ผู้ใช้ทดสอบงานข้ามแผนกด้วยชุดข้อมูลเดียวกัน ซ้อมย้าย และเปิดใช้ตามแผนที่มีผู้ตัดสินใจ
หลักฐานตรวจรับควรระบุผลที่คาดหวัง เช่น ผู้ใช้สิทธิ์ปกติแก้ราคานอกเงื่อนไขไม่ได้ ผู้อนุมัติเห็นเหตุผลและประวัติ และเมื่อออร์เดอร์ถูกยกเลิก ระบบจัดการยอดจองได้ถูกต้อง การกดแต่ละปุ่มสำเร็จไม่เท่ากับกระบวนการจบสมบูรณ์
แยกข้อผิดพลาดออกจากความต้องการเพิ่มที่เกิดภายหลัง เมื่อกติกาธุรกิจเปลี่ยนให้บันทึกผลต่อเวลา งบ และการทดสอบที่ต้องทำใหม่ การจัดการเรื่องนี้ชัดช่วยให้ทั้งองค์กรและทีมพัฒนารู้ว่ากำลังรับรองงานส่วนใด
การส่งมอบและเปลี่ยนผู้ดูแลในอนาคต
ก่อนทำสัญญาต้องตกลงสิทธิ์ในข้อมูล ซอร์ส ส่วนประกอบภายนอก และเอกสารให้ตรงกับรูปแบบโครงการ การรับมอบซอร์สอย่างเดียวอาจยังเปิดระบบไม่ได้ หากไม่มีขั้นตอนติดตั้ง การตั้งค่าสภาพแวดล้อม หรือสิทธิ์บริการที่ต้องใช้
สำหรับผลิตภัณฑ์มาตรฐานให้ตรวจรูปแบบส่งออกข้อมูลและเงื่อนไขเลิกใช้ สำหรับระบบเฉพาะให้ตรวจเอกสารกติกาธุรกิจ การติดตั้ง การสำรอง และการรับช่วงต่อ พร้อมช่องทางรายงานปัญหาและเงื่อนไขดูแล ไม่จำเป็นต้องใช้รูปแบบส่งมอบเดียวกันทุกโครงการ แต่ต้องรู้ภาระของแต่ละทางเลือกก่อนลงทุน
ต้นทุนรวมที่ต้องใช้เปรียบเทียบ
ต้นทุน ERP ไม่ได้จบที่ค่าลิขสิทธิ์หรือค่าพัฒนา ให้เปรียบเทียบช่วงเวลาที่เท่ากันและปริมาณใช้งานใกล้เคียงกัน เช่น จำนวนผู้ใช้ สาขา เอกสาร และระบบที่ต้องเชื่อม พร้อมเขียนสมมติฐานให้ตรวจได้
- ค่าเริ่มโครงการ: วิเคราะห์ ตั้งค่า พัฒนา เชื่อมต่อ ย้ายข้อมูล และอบรม
- ค่าใช้ต่อเนื่อง: ลิขสิทธิ์ Hosting สำรองข้อมูล Monitoring และบริการดูแล
- ค่าเปลี่ยนแปลง: เพิ่มสาขา กติกา เอกสาร ผู้ใช้ หรือเชื่อมระบบใหม่
- ภาระทีมภายใน: เวลาจัดข้อมูล ทดสอบ รับรองยอด และช่วยผู้ใช้
- ค่าออกจากระบบ: ส่งออกข้อมูล ส่งมอบเอกสาร และเปลี่ยนผู้ดูแล
สำหรับงานรับพัฒนา ERP ของ Zairosoft ราคาเริ่มต้นที่ 500,000 บาทตามข้อมูลบริการที่กำหนดไว้ งบจริงต้องประเมินจากขอบเขตและเงื่อนไขของโครงการ ควรระบุในใบเสนอราคาว่ารวมการย้ายข้อมูล Integration และการดูแลระยะใด ไม่ใช้ราคาเริ่มต้นแทนงบทุกโครงการ
ประโยชน์ทางธุรกิจควรวัดด้วยอะไร
กำหนดผลที่ต้องการก่อนเลือกเครื่องมือ เช่น ลดการคีย์ซ้ำระหว่างขายกับบัญชี ลดเวลารออนุมัติ หรือเห็นยอดค้างส่งได้ทันรอบทำงาน แล้วเก็บค่าปัจจุบันเพื่อใช้เปรียบเทียบหลังเปิดใช้
ตัวชี้วัดที่มีประโยชน์ ได้แก่ เวลาตั้งแต่รับออร์เดอร์ถึงพร้อมส่ง จำนวนรายการที่ต้องแก้ด้วยมือ ความคลาดเคลื่อนของสต็อก และเวลาปิดงานประจำวัน ต้องกำหนดวิธีนับและเจ้าของตัวเลขด้วย จึงจะรู้ว่าระบบช่วยงานจริงหรือเพียงย้ายภาระจากแผนกหนึ่งไปอีกแผนก
ประโยชน์ทางเทคนิคและข้อแลกเปลี่ยน
ระบบที่ออกแบบดีช่วยรวมรหัสอ้างอิง ลดการแก้ข้อมูลข้ามฐานโดยตรง และเพิ่มการตรวจสอบย้อนหลัง ERP Custom เปิดโอกาสให้สร้างหน้าจอตามงานเฉพาะและแยกส่วนที่เปลี่ยนบ่อยได้ แต่ทุกความยืดหยุ่นต้องมีต้นทุนทดสอบ เอกสาร และการดูแลตามมา
ระบบมาตรฐานอาจมีเครื่องมือผู้ดูแลและแนวทางอัปเดตพร้อมกว่า แต่การปรับลึกอาจทำให้ทดสอบอัปเดตยาก ควรถามว่าจุดที่ปรับใช้ส่วนขยายที่ผู้ขายรองรับหรือแก้ภายในผลิตภัณฑ์ และจะตรวจความเข้ากันได้อย่างไรเมื่อเปลี่ยนรุ่น
ความปลอดภัยต้องตรวจในทุกแนวทาง
ตรวจสิทธิ์ตามหน้าที่และขอบเขตข้อมูล เช่น ฝ่ายขายเห็นลูกค้าที่รับผิดชอบ ส่วนผู้อนุมัติราคาเห็นคำขอที่อยู่ในวงเงิน ไม่ให้ผู้ใช้ทุกคนมีสิทธิ์แก้ต้นทุน ส่งออกฐานลูกค้า หรือย้อนสถานะเอกสาร
เรื่องที่ควรมีคือบัญชีผู้ใช้รายบุคคล การยืนยันตัวตนที่เหมาะกับความเสี่ยง ประวัติการแก้ข้อมูล การแยกสิทธิ์ผู้ดูแลกับผู้ใช้งาน และการสำรองที่ซ้อมกู้ได้ สำหรับระบบบน Cloud ต้องตรวจความรับผิดชอบของผู้ขายกับองค์กร ไม่สรุปว่าปลอดภัยเพราะเป็นบริการออนไลน์เพียงอย่างเดียว
รองรับการเติบโตต้องทดสอบที่งานหนักจริง
จำนวนผู้ใช้เป็นเพียงส่วนหนึ่งของภาระระบบ รายงานสิ้นเดือน การนำเข้าราคา และการสั่งสินค้าพร้อมกันอาจใช้ทรัพยากรต่างกัน ให้ระบุจำนวนเอกสารและเวลาตอบสนองที่ยอมรับได้ในงานหลัก
การแยกงานรายงานหนักและการส่งข้อมูลเข้าคิวช่วยให้หน้าจอหลักไม่ต้องรอทั้งหมด แต่ยังต้องควบคุมความถูกต้องของรายการและแสดงเวลาที่ข้อมูลอัปเดตล่าสุด หากเลือกแพ็กเกจมาตรฐานให้ตรวจเพดานพื้นที่ ผู้ใช้ และการเรียก API เมื่อธุรกิจเพิ่มสาขา
ข้อผิดพลาดที่ทำให้เลือก ERP ไม่คุ้ม
การเลือกจากหน้าจอสวย การนับ Module หรือการขอให้ทำเหมือนระบบเดิมทุกจุด ทำให้มองข้ามงานระหว่างแผนก อีกปัญหาคือระบุเพียง “เชื่อมบัญชีได้” โดยไม่มีรายการเอกสาร เงื่อนไขยกเลิก และแผนตรวจยอด
แก้ด้วยการใช้ชุดทดสอบเดียวกันเปรียบเทียบทุกแนวทาง ให้คนทำงานจริงเข้าร่วม และกำหนดขอบเขตระยะแรกที่จบกระบวนการหนึ่งได้ หากเริ่มแค่หน้าจอรับออร์เดอร์แต่ไม่เชื่อมคลัง งานคีย์ซ้ำอาจยังเท่าเดิม
เช็กลิสต์ก่อนเลือกผู้พัฒนาและระบบ
- ระบุงานหลักและข้อยกเว้นพร้อมตัวอย่างเอกสารจริง
- แยกการตั้งค่ามาตรฐาน งานปรับกระบวนการ และงานพัฒนาเพิ่ม
- ยืนยันสิทธิ์เข้าถึงและส่งออกข้อมูลเมื่อเปลี่ยนผู้ให้บริการ
- ตกลงหลักฐานตรวจรับ UAT และผู้รับรองแต่ละกระบวนการ
- ตรวจต้นทุน Integration รวมถึงค่าบริการของระบบปลายทาง
- วางแผนการอบรม การดูแล และการรับแจ้งปัญหาหลังเปิดใช้
- กำหนดสิทธิ์ในซอร์ส เอกสาร และขั้นตอนติดตั้งตามสัญญา
แนวโน้มที่ควรใช้เป็นเกณฑ์เลือกในระยะยาว
ความสามารถเชื่อมต่อและส่งออกข้อมูลมีผลต่อทางเลือกในอนาคตมากกว่ารายการฟังก์ชันเฉพาะช่วงเวลา ระบบที่แยกส่วนและมีกติกาข้อมูลชัดช่วยเพิ่มช่องทางขาย Dashboard หรือระบบช่วยทำงานได้ง่ายขึ้น แต่การมี API ไม่ได้แปลว่าจะเชื่อมได้ทุกกรณีโดยไม่มีงานออกแบบ
หากต้องการเพิ่ม AI ควรเริ่มจากงานช่วยค้นหา สรุป หรือเสนอข้อมูลที่ตรวจสอบได้ก่อน การให้ AI อนุมัติเอกสารหรือบันทึกธุรกรรมต้องมีขอบเขตสิทธิ์และเงื่อนไขรับรอง ไม่ควรใช้ความสามารถ AI เป็นเหตุผลหลักแทนการตรวจความถูกต้องของ ERP
สรุปการเลือก ERP ให้เหมาะกับธุรกิจ
เลือก ERP สำเร็จรูปเมื่อมาตรฐานรองรับงานหลักและองค์กรพร้อมใช้กระบวนการร่วมกัน เลือก ERP Custom เมื่อช่องว่างกระทบความสามารถสำคัญของธุรกิจและมีเหตุผลคุ้มกับการดูแล ส่วนระบบผสมเหมาะเมื่อแยกหน้าที่ได้ชัดและควบคุมการเชื่อมข้อมูลได้
ก่อนตัดสินใจ ให้ทำ Fit-Gap ทดสอบข้อยกเว้น และประเมินต้นทุนรวม หากกำลังเตรียมโครงการ อ่านต่อเรื่อง Excel to ERP และ ERP เชื่อมบัญชี เพื่อประเมินงานข้อมูลและ Integration ที่มักมีผลต่องบจริง
คำถามที่พบบ่อยเกี่ยวกับ ERP Custom
ERP Custom ออกแบบตามกระบวนการและขอบเขตเฉพาะขององค์กร ส่วน ERP สำเร็จรูปมีความสามารถมาตรฐานให้ตั้งค่าและเลือกใช้ ทั้งสองแบบยังต้องเตรียมข้อมูล ทดสอบ อบรม และดูแลหลังเปิดใช้
ไม่จำเป็นเสมอไป ให้ดูว่าระบบมาตรฐานรองรับงานหลักได้เพียงใด หากข้อยกเว้นสำคัญยังต้องทำด้วยมือมากและมีผลต่อธุรกิจ จึงค่อยประเมินการพัฒนาเฉพาะหรือระบบผสม
ขึ้นกับข้อมูลและขอบเขต แม้ผลิตภัณฑ์พร้อมใช้ ยังอาจต้องตั้งค่าโครงสร้างบริษัท สิทธิ์ ภาษี สินค้า ยอดตั้งต้น และทดสอบกระบวนการก่อนเปิดใช้จริง
ควรดูค่าใช้จ่ายรวมในช่วงเวลาที่เท่ากัน รวมค่าลิขสิทธิ์ พัฒนา ย้ายข้อมูล Integration โครงสร้างพื้นฐาน และดูแล เพื่อไม่ให้ราคาเริ่มต้นกลบภาระหลังเปิดใช้
ทำได้เมื่อระบบปลายทางรองรับช่องทางที่เหมาะสม ต้องตรวจ API หรือรูปแบบนำเข้า เอกสารที่รองรับ ค่าบริการ และเงื่อนไขการส่งใหม่ก่อนประเมินงาน
ใช้ Workflow จริง ตัวอย่างเอกสาร กติกาอนุมัติ สิทธิ์ และข้อยกเว้น เช่น ส่งบางส่วน คืนสินค้า และยกเลิกเอกสาร จากนั้นตรวจว่าทำได้ตามมาตรฐาน ตั้งค่าเพิ่ม หรือต้องพัฒนา
ต้องดูแล Integration เพิ่มและกำหนดเจ้าของข้อมูล หากสองระบบแก้ข้อมูลเดียวกันโดยไม่มีกติกา อาจเกิดยอดไม่ตรงและติดตามปัญหายาก
ตรวจความเข้าใจงานจริง วิธีตรวจรับ สิทธิ์ในข้อมูลและซอร์สตามสัญญา เอกสารส่งมอบ แผนสำรองและกู้คืน รวมถึงผู้รับผิดชอบดูแลหลังเปิดใช้


