โปรเจกต์ ERP: ทำไมถึงบานปลาย ล่าช้า และไม่เป็นไปตามที่คาด

ทุกปี บริษัทในไทย ญี่ปุ่น และทั่วเอเชียตะวันออกเฉียงใต้ต่างทุ่มงบประมาณหลายล้านบาทไปกับระบบ ERP โดยคาดหวังว่าจะได้การดำเนินงานที่คล่องตัวขึ้น มองเห็นข้อมูลแบบ real-time และประหยัดต้นทุนในระยะยาว แต่หลายรายกลับได้ผลตรงกันข้าม

จากข้อมูลที่รวบรวมมา มากกว่า 50% ของการติดตั้ง ERP ใช้งบเกิน ใช้เวลาเกิน หรือทั้งคู่ บางโปรเจกต์ไม่เคยถูกนำไปใช้งานจริงอย่างเต็มรูปแบบเลยด้วยซ้ำ ปัญหาไม่ได้อยู่ที่ตัวซอฟต์แวร์เป็นหลัก แต่อยู่ที่โครงสร้างองค์กร สัญญา และกระบวนการที่พังตั้งแต่ก่อนจะเขียนโค้ดบรรทัดแรก

บทความนี้รวบรวม pain points ที่พบบ่อยที่สุดในการพัฒนาและติดตั้ง ERP เพื่อให้คุณมองเห็นสัญญาณเตือนก่อนที่มันจะกลายเป็นต้นทุนที่จ่ายไปแล้ว

1. Requirements ที่เปลี่ยนตลอดเวลา

โปรเจกต์ ERP ใช้เวลานาน การติดตั้งขนาดกลางทั่วไปใช้เวลา 6–18 เดือน ในช่วงเวลานั้น ความต้องการทางธุรกิจเปลี่ยน ผู้มีส่วนได้ส่วนเสียใหม่เข้ามา และ "ฟีเจอร์เล็กน้อย" ก็สะสมพอกพูน

ผลที่ได้คือ scope creep — หนึ่งในสาเหตุหลักที่ทำให้งบ ERP บานปลาย สิ่งที่เริ่มต้นเป็นโปรเจกต์ที่กำหนดชัดเจนกลายเป็นเป้าหมายที่ขยับตลอด และ vendor ที่ตกลงราคาคงที่ไว้ก็ต้องเลือกระหว่างการตัด scope หรือกลับมาขอเงินเพิ่ม

ปัญหาที่ลึกกว่านั้น: องค์กรส่วนใหญ่ไม่ได้เข้าใจกระบวนการของตัวเองอย่างถ่องแท้ก่อนเริ่มโปรเจกต์ workflow จริงอยู่ในหัวคน ไม่ได้อยู่ในเอกสาร และช่องว่างนั้นมักโผล่ขึ้นมาในเวลาที่แย่ที่สุด

2. งาน Integration ที่ถูกประเมินต่ำเสมอ

ไม่มี ERP ไหนทำงานแบบโดดเดี่ยว ระบบต้องเชื่อมต่อกับระบบเงินเดือน เครื่องจักรในโรงงาน ฐานข้อมูลเดิม แพลตฟอร์ม e-commerce API ของภาครัฐ และบางครั้งซอฟต์แวร์อายุสิบปีที่ไม่เคยถูกออกแบบมาให้คุยกับระบบอื่น

งาน integration คือจุดที่โปรเจกต์ ERP สูญเสียเวลาและเงินโดยที่ไม่มีใครสังเกตเห็น vendor เสนอราคาสำหรับตัว ERP เอง ไม่ใช่สำหรับเวลาหลายสัปดาห์ที่ต้องใช้ reverse-engineer API ที่ไม่มีเอกสาร หรือสร้าง connector ให้กับระบบ SCADA ที่ยังรันบน Windows XP

คำถามที่ต้องถาม vendor ก่อนเซ็นสัญญา: ขอรายละเอียดทุกระบบที่ต้องเชื่อมต่อ ใครรับผิดชอบแต่ละ connector และจะเกิดอะไรขึ้นเมื่อ API ของบุคคลที่สามเปลี่ยนหลัง go-live

3. ข้อมูลสกปรกที่ไม่มีใครอยากเป็นเจ้าของ

การย้ายข้อมูลจากระบบเก่าไปยัง ERP ใหม่ฟังดูตรงไปตรงมา แต่แทบจะไม่เคยเป็นแบบนั้น

ข้อมูลทางธุรกิจจริง โดยเฉพาะในบริษัทที่ดำเนินงานมา 10 ปีขึ้นไป มักเต็มไปด้วยข้อมูลซ้ำ ความไม่สอดคล้อง field ที่หายไป และรูปแบบที่ครั้งหนึ่งสมเหตุสมผลแต่ไม่ตรงกับ schema สมัยใหม่ การทำความสะอาดข้อมูลใช้เวลานานกว่าที่ประเมินมาก และไม่มีใครอยากรับผิดชอบงานนี้

ยิ่งไปกว่านั้น ข้อมูลไม่ดีที่เข้าไปในระบบใหม่ไม่ได้หายไปไหน มันโผล่ขึ้นมาเป็นจำนวนสินค้าคงคลังที่ผิด รายงานการเงินที่คลาดเคลื่อน และข้อมูลลูกค้าที่กรอกครึ่งภาษาไทยครึ่งภาษาอังกฤษ

กฎเบื้องต้น: ตั้งงบเวลาสำหรับการย้ายและทำความสะอาดข้อมูลให้เท่ากับที่ใช้พัฒนาระบบ โปรเจกต์ส่วนใหญ่ตั้งงบไว้แค่หนึ่งในสิบของนั้น

4. การ Customize ที่กลายเป็นกับดัก

ทุกธุรกิจมีกระบวนการที่เป็นเอกลักษณ์ vendor ERP รู้เรื่องนี้ดีและเสนอการปรับแต่ง แต่การ customize มากเกินไปสร้างกับดักระยะยาว

เมื่อ vendor ออก version ใหม่ module ที่ปรับแต่งของคุณอาจพัง การอัปเกรดกลายเป็นเรื่องแพง บางครั้งเป็นไปไม่ได้เลย คุณก็ติดอยู่กับ platform version เก่า จ่ายค่า maintenance สำหรับโค้ดที่มีแค่หนึ่งหรือสองคนเท่านั้นที่เข้าใจ

แนวทางที่ดีกว่าคือแยกแยะระหว่าง การปรับแต่งกระบวนการหลัก (คุ้มค่าที่จะทำ) กับ การปรับแต่งตามความชอบ (แทบไม่คุ้มกับต้นทุนระยะยาว) โปรเจกต์ส่วนใหญ่ไม่ได้แยกแยะเรื่องนี้จนกว่าจะสายเกินไป

5. คนไม่ใช้ระบบ

นี่คือรูปแบบความล้มเหลวของ ERP ที่ถูกรายงานน้อยที่สุด ระบบ go-live ใช้งานได้ในทางเทคนิค แต่ไม่มีใครใช้อย่างถูกต้อง

ผู้ใช้งานปลายทางหา workaround สเปรดชีต Excel กลับมาใหม่ ข้อมูลหยุดถูกกรอกเข้า ERP เพราะ "วิธีเดิมเร็วกว่า" ภายในหนึ่งปี บริษัทกำลังรันระบบขนานกัน ทั้ง ERP และ shadow system ซึ่งทำลายจุดประสงค์ทั้งหมด

สาเหตุหลักแทบทุกครั้งคือการบริหารการเปลี่ยนแปลงและการฝึกอบรมที่ไม่เพียงพอ สิ่งเหล่านี้เป็นรายการแรกที่ถูกตัดเมื่องบตึง และเป็นความผิดพลาดที่แพงที่สุดเมื่อมองย้อนกลับไป

6. ความเสี่ยงจาก Vendor และพาร์ทเนอร์

การเลือกพาร์ทเนอร์ติดตั้งที่ผิดทำให้ ERP ล้มเหลวมากพอๆ กับการเลือกซอฟต์แวร์ที่ผิด

รูปแบบที่เป็นสัญญาณเตือนความเสี่ยง:

พาร์ทเนอร์ชนะสัญญาด้วยราคาต่ำสุด ไม่ใช่ความเหมาะสมกับงาน
ทีมไม่มีประสบการณ์ในอุตสาหกรรมของคุณหรือสภาพแวดล้อมกฎหมายท้องถิ่น
การสนับสนุนหลัง go-live ถูกกำหนดไว้คลุมเครือหรือตั้งราคาแยกต่างหาก
project manager เปลี่ยนระหว่างโปรเจกต์

สำหรับบริษัทในไทยและเอเชียตะวันออกเฉียงใต้ ความรู้ด้านกฎหมายท้องถิ่นมีความสำคัญมาก ทั้งรูปแบบรายงาน VAT การปฏิบัติตาม BOI การจัดการข้อมูลตาม PDPA การเชื่อมต่อศุลกากร และข้อกำหนดเฉพาะอุตสาหกรรมที่ทีม offshore ทั่วไปจะไม่รู้

7. ROI ที่ไม่มีใครวัดผล

โปรเจกต์ ERP ถูกอนุมัติด้วยการประมาณ ROI ทั้งการประหยัดแรงงาน ลดข้อผิดพลาด รายงานที่เร็วขึ้น แต่หลัง go-live แทบไม่มีใครกลับมาวัดว่าการประมาณนั้นเป็นจริงหรือไม่

เรื่องนี้สำคัญเพราะมันหมายความว่าข้อผิดพลาดเดิมถูกทำซ้ำ โปรเจกต์ ERP ต่อไปในองค์กรเดียวกันก็ได้รับการประมาณที่มองโลกในแง่ดีเหมือนเดิม ต้นทุน integration ที่ถูกประเมินต่ำเหมือนเดิม และช่วงทดสอบที่ถูกเร่งรัดเหมือนเดิม

บริษัทที่ทำ ERP ได้ดีมองว่ามันเป็นการลงทุนด้านการดำเนินงานอย่างต่อเนื่อง ไม่ใช่โปรเจกต์ครั้งเดียว พวกเขาวัด adoption ติดตามการปรับปรุงกระบวนการ และให้ vendor รับผิดชอบต่อผลลัพธ์ ไม่ใช่แค่การส่งมอบ

สิ่งที่ต้องทำก่อนเริ่มต้น

ถ้าคุณกำลังประเมินโปรเจกต์ ERP อยู่ตอนนี้ pain points ข้างต้นไม่ใช่สิ่งที่หลีกเลี่ยงไม่ได้ แต่ต้องมีการบรรเทาเชิงรุก ไม่ใช่แค่ความหวัง

ก่อนเซ็นสัญญา ขอคำตอบที่ชัดเจนสำหรับคำถามเหล่านี้:

ใครเป็นเจ้าของงาน data migration และเกณฑ์การยอมรับข้อมูลสะอาดคืออะไร?
scope ของ integration คืออะไร และมีข้อสมมติฐานอะไรเกี่ยวกับ API บุคคลที่สามบ้าง?
การสนับสนุนหลัง go-live ใน 90 วันแรกเป็นอย่างไร?
การเปลี่ยนแปลง scope จัดการตามสัญญาอย่างไร?
พาร์ทเนอร์ติดตั้งของคุณมีอ้างอิงในอุตสาหกรรมและสภาพแวดล้อมกฎหมายของคุณหรือไม่?

ที่ Simplico เราช่วยองค์กรประเมิน กำหนดขอบเขต และส่งมอบระบบซอฟต์แวร์ด้วยการประเมินความซับซ้อนอย่างตรงไปตรงมา ไม่ใช่การขายที่มองโลกในแง่ดีเกินจริง หากคุณกำลังวางแผนโครงการ ERP และต้องการการตรวจสอบทางเทคนิคที่สมจริงก่อนตัดสินใจ ติดต่อเราได้เลย