จาก ERP สู่ความล้มเหลว: เมื่อกลยุทธ์ กระบวนการ และคนไม่เดินไปพร้อมกัน

ทำไมองค์กรจึงอาจลงทุนกับระบบที่ดี แต่ยังไม่สามารถเปลี่ยนการทำงานและสร้างผลลัพธ์ทางธุรกิจได้ตามเป้าหมาย

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

 

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

 

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

สาเหตุที่ 1 ไม่มีเป้าหมายทางธุรกิจและเจ้าภาพระดับบริหารที่ชัดเจน

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

 

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

 

บทบาทของ Executive Sponsor จึงไม่ควรจำกัดอยู่ที่การอนุมัติงบประมาณหรือเข้าร่วมประชุมเปิดโครงการ ผู้สนับสนุนระดับบริหารต้องสื่อสารว่าเหตุใดองค์กรจึงต้องเปลี่ยน ตัดสินใจเมื่อเกิดความขัดแย้งข้ามฝ่าย และติดตามว่าผลลัพธ์ทางธุรกิจเกิดขึ้นจริงหรือไม่ นอกจากนี้ควรมี Steering Committee และ Process Owner ที่มีอำนาจกำหนดกระบวนการแบบต้นน้ำถึงปลายน้ำ ไม่ใช่รับผิดชอบเฉพาะหน้าที่ภายในแผนก

 

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

สาเหตุที่ 2 นำกระบวนการเดิมทั้งหมดไปใส่ในระบบใหม่

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

 

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

 

การทำ Requirement ที่ดีจึงต้องถามมากกว่าวิธีทำงานในปัจจุบัน ทีมงานควรถามว่าขั้นตอนนั้นมีวัตถุประสงค์อะไร ยังจำเป็นหรือไม่ ใครควรเป็นผู้รับผิดชอบ และสามารถใช้กระบวนการมาตรฐานของ ERP ได้เพียงใด แนวทาง Fit to Standard ช่วยให้องค์กรเริ่มจากแนวปฏิบัติมาตรฐาน แล้วระบุเฉพาะช่องว่างที่มีเหตุผลทางธุรกิจหรือข้อกำหนดทางกฎหมายรองรับ

 

ความต้องการควรถูกแบ่งอย่างน้อยสามกลุ่ม ได้แก่ สิ่งที่ระบบมาตรฐานรองรับ สิ่งที่แก้ได้ด้วยการตั้งค่า และสิ่งที่จำเป็นต้องพัฒนาเพิ่มเติมจริง การพัฒนาเพิ่มเติมแต่ละรายการควรมีเจ้าของเหตุผล ประโยชน์ที่คาดหวัง ค่าใช้จ่าย ผลกระทบต่อเวลา และภาระการดูแลระยะยาว พร้อมผ่านกระบวนการ Change Control เพื่อป้องกัน Scope Creep

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

สาเหตุที่ 3 เตรียมคนและข้อมูลช้ากว่าการเตรียมระบบ

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

ในด้านบุคลากร การอบรมเฉพาะวิธีกดหน้าจอก่อน Go live ไม่เพียงพอ ผู้ใช้จำเป็นต้องเข้าใจกระบวนการใหม่ บทบาทของตน ผลกระทบต่อหน่วยงานอื่น และวิธีจัดการกรณียกเว้น หาก Key User ไม่มีเวลาร่วมออกแบบและทดสอบ ความรู้เกี่ยวกับธุรกิจจะไม่ถูกส่งเข้าสู่ระบบอย่างครบถ้วน ขณะเดียวกัน หากผู้บริหารยังยอมให้ใช้วิธีเดิมควบคู่ไปโดยไม่มีกำหนด ผู้ใช้ย่อมไม่มีแรงจูงใจให้เปลี่ยนพฤติกรรม

การบริหารการเปลี่ยนแปลงควรประกอบด้วยการวิเคราะห์ผู้มีส่วนได้ส่วนเสีย การสื่อสารตามกลุ่มผู้ใช้ การประเมินผลกระทบของบทบาท การฝึกอบรมตามสถานการณ์จริง และเครือข่าย Key User หรือ Super User สำหรับช่วยเหลือหน้างานในช่วงเริ่มต้น การสื่อสารควรตอบคำถามของพนักงานให้ได้ว่า สิ่งใดจะเปลี่ยน เหตุใดจึงต้องเปลี่ยน และการเปลี่ยนแปลงจะช่วยให้งานของตนและองค์กรดีขึ้นอย่างไร

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

การย้ายข้อมูลจึงควรเป็นโครงการย่อยที่มี Data Owner เกณฑ์คุณภาพ และรอบทดลองย้ายข้อมูลหลายครั้ง องค์กรต้องกำหนดว่าจะย้ายข้อมูลใด ย้อนหลังกี่ปี ใครตรวจสอบ และจะกระทบยอดกับระบบเดิมอย่างไร User Acceptance Test ควรใช้ข้อมูลและสถานการณ์ใกล้เคียงการทำงานจริง รวมถึงกรณียกเว้น การอนุมัติ เอกสาร และรายงานสำคัญ ก่อน Go live ควรมีเกณฑ์ความพร้อมที่ทุกฝ่ายยอมรับร่วมกัน ไม่ใช่ตัดสินจากความรู้สึกว่าระบบน่าจะพร้อม

 

ความสำเร็จของ ERP ต้องวัดหลัง Go live

วัน Go live เป็นเพียงจุดเปลี่ยนผ่าน ไม่ใช่เส้นชัย ในช่วงแรกองค์กรควรติดตามปัญหา แยกปัญหาจากระบบ กระบวนการ ข้อมูล และทักษะผู้ใช้ พร้อมกำหนดผู้รับผิดชอบและเวลาการแก้ไขอย่างชัดเจน หลังระบบเริ่มมีเสถียรภาพ ควรกลับไปวัด KPI ตาม Business Case และทบทวนว่าฟังก์ชันใดยังไม่ได้ใช้เต็มประสิทธิภาพ

กล่าวโดยสรุป ERP จะประสบความสำเร็จเมื่อสามองค์ประกอบเดินไปพร้อมกัน ได้แก่ Strategy and Governance ที่กำหนดเป้าหมายและความรับผิดชอบ Process and Technology ที่ออกแบบกระบวนการและระบบให้เหมาะสม และ People and Data ที่ทำให้ผู้ใช้ยอมรับการเปลี่ยนแปลงบนข้อมูลที่น่าเชื่อถือ ความสำเร็จจึงไม่ควรวัดเพียงว่าระบบเปิดใช้งานได้หรือไม่ แต่ควรวัดว่าองค์กรทำงานดีขึ้น ใช้ข้อมูลชุดเดียวกัน และตัดสินใจได้เร็วและแม่นยำกว่าเดิมเพียงใด

 

ERP Readiness Checklist

 

แหล่งข้อมูลอ้างอิง

  • Idilbi, M. et al. Critical Success Factors for ERP Implementation. Procedia Computer Science, 2022. https://www.sciencedirect.com/science/article/pii/S1877050922006612
  • Chatzoglou, P. et al. Critical Success Factors for ERP Implementation in SMEs. Annals of Computer Science and Information Systems. https://annals-csis.org/Volume_2/pliks/63.pdf
  • SAP. ERP Migration Checklist: Key Strategies for Success. https://www.sap.com/resources/erp-migration
  • Prosci. Improving ERP User Adoption with Change Management. https://www.prosci.com/blog/improving-erp-user-adoption-with-change-management
  • Panorama Consulting Group. Why ERP Projects Go Over Budget and How to Prevent It. https://www.panorama-consulting.com/why-erp-projects-go-over-budget/

คำถามที่พบบ่อยเกี่ยวกับความล้มเหลวในการวางระบบ ERP

เพราะเหตุใดโครงการ ERP จึงล้มเหลว ทั้งที่เลือกซอฟต์แวร์ที่มีคุณภาพ?

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

ผู้บริหารควรมีบทบาทอย่างไรในโครงการ ERP?

ผู้บริหารควรทำหน้าที่มากกว่าการอนุมัติงบประมาณ โดยต้องกำหนดเป้าหมายและ KPI สนับสนุนการเปลี่ยนแปลง ตัดสินใจเมื่อเกิดความขัดแย้งระหว่างหน่วยงาน และติดตามผลลัพธ์หลังเปิดใช้งาน ควรมี Executive Sponsor, Steering Committee และ Process Owner ที่มีอำนาจรับผิดชอบอย่างชัดเจน

ควรปรับระบบ ERP ให้ทำงานเหมือนระบบเดิมหรือไม่?

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

เหตุใดการเตรียมข้อมูลจึงมีความสำคัญต่อความสำเร็จของERP?

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

องค์กรจะประเมินได้อย่างไรว่าพร้อมเริ่มโครงการ ERP แล้ว?

องค์กรควรทำ ERP Readiness Assessment โดยประเมินความพร้อมอย่างน้อย 4 ด้าน ได้แก่ เป้าหมายและธรรมาภิบาล กระบวนการและระบบ บุคลากรและการเปลี่ยนแปลง รวมถึงข้อมูลและการเตรียม Go-live หากยังไม่มี KPI, Process Owner, Key User, Data Owner, แผนทดสอบ หรือแผนบริหารการเปลี่ยนแปลง ควรปิดช่องว่างเหล่านี้ก่อนเริ่มโครงการเต็มรูปแบบ

สอบถามรายละเอียด SAP Business One ได้ที่

บริษัท ซันเด โซลูชันส์ จำกัด

โทร 026348899 อีเมล sales@sundae.co.th

เว็บไซต์ https://www.sundae.co.th/solution/erp/sap-business-one/

ติดตามเราได้ที่:

Line OA: @sundae.co.th

Facebook: https://www.facebook.com/sundaesolutions

LinkedIn: https://www.linkedin.com/company/sundaeth
IG https://www.instagram.com/sundaesolutions/
X https://www.x.com/@SundaeSolutions