ลองค้นหาคำว่า "อัตราความล้มเหลวของ ERP" ก่อนตัดสินใจเรื่องซอฟต์แวร์สักครั้ง แล้วจะเจอตัวเลขเดิมๆ ซ้ำแล้วซ้ำเล่า โครงการ ERP ล้มเหลว 73% งบประมาณบานปลายสูงถึง 215% และแหล่งที่มาที่ถูกอ้างอิงในบล็อกและเว็บเปรียบเทียบซอฟต์แวร์นับสิบแห่งมักเป็นชื่อเดียวกันเสมอ คือ Panorama Consulting Group บริษัทวิจัยด้านการติดตั้ง ERP ที่มีชื่อเสียง ตัวเลขนี้เจาะจงพอจะฟังดูน่าเชื่อถือ ถูกพูดซ้ำบ่อยพอจะรู้สึกเหมือนได้รับการยืนยันแล้ว และน่ากลัวพอจะทำให้เจ้าของ SME ที่ระมัดระวังเก็บไอเดียทั้งหมดขึ้นหิ้งไปเงียบๆ
เราไปที่เว็บไซต์ของ Panorama โดยตรงเพื่ออ่านแหล่งข้อมูลต้นทางที่ตัวเลขเหล่านี้ถูกอ้างถึง รายงานล่าสุดที่ Panorama เผยแพร่จริงไม่มีตัวเลขทั้งสองตัวนี้เลย ไม่มี "ล้มเหลว 73%" ไม่มี "งบบาน 215%" สิ่งที่รายงานบอกไว้จริงๆ แคบกว่า เจาะจงกว่า และมีประโยชน์กว่ามากสำหรับธุรกิจที่กำลังจะตัดสินใจจริง
ฟังดูเหมือนคำเตือนที่มาจากงานวิจัยที่แน่นหนา แต่จริงๆ แล้วมันคือสถิติที่ถูกก็อปวางซ้ำไปมาในเนื้อหาซอฟต์แวร์สำหรับ SME จนแทบไม่มีใครตรวจสอบแล้วว่ามันยังผูกอยู่กับรายงานที่มันอ้างว่ามาจากหรือเปล่า บทความนี้จะพาไปตามรอยข้อมูลจริงของ Panorama ว่าบอกอะไรไว้จริงๆ เกี่ยวกับความเสี่ยงด้านงบประมาณของ ERP และวิธีวางแผนรับความเสี่ยงที่มีอยู่จริง แทนที่จะเป็นความเสี่ยงที่ไม่มีอยู่จริง
สถิติความล้มเหลวของ ERP ที่น่ากลัวซึ่งแชร์กันทั่วอินเทอร์เน็ตไม่ได้มาจาก Panorama จริง ความเสี่ยงที่ตรวจสอบได้จริงแคบกว่าและจัดการได้ง่ายกว่ามาก งบประมาณบานปลายเกิดจากความต้องการเทคโนโลยีเพิ่มเติมที่ไม่ได้ถูกกำหนดขอบเขตไว้ตั้งแต่แรก ไม่ใช่เพราะโครงการ ERP ถูกลิขิตให้ล้มเหลวตั้งแต่ต้น
The Phantom Statistic ตัวเลข 73% ล้มเหลว และ 215% งบบาน ที่ไม่มีอยู่จริงบนแหล่งข้อมูลต้นทาง
เรียกมันว่า Phantom Statistic ตัวเลขที่เจาะจงพอจะฟังดูเหมือนมาจากงานวิจัยจริง ถูกพูดซ้ำในเนื้อหาผู้ขายซอฟต์แวร์มากพอจนเริ่มรู้สึกเหมือนเป็นความจริงในตัวเอง แต่ไม่เคยตามรอยกลับไปหาแหล่งข้อมูลต้นทางที่มันถูกอ้างถึงได้จริง "ล้มเหลว 73% งบบาน 215% อ้างว่ามาจาก Panorama Consulting" คือรูปแบบหนึ่งที่พบบ่อยที่สุดของแพทเทิร์นนี้ในเนื้อหาขาย ERP เมื่อไปดึงรายงานล่าสุดที่ Panorama เผยแพร่จริงโดยตรง ไม่พบตัวเลขทั้งสองตัวนี้ที่ไหนบนหน้าเว็บเลย
นั่นไม่ได้แปลว่าโครงการ ERP ไม่มีความเสี่ยงเลย ความเสี่ยงมีอยู่จริงชัดเจน แต่มันแปลว่าตัวเลขที่เจาะจงและน่ากลัวตัวหนึ่งหลุดออกจากแหล่งที่มาที่มันอ้างไว้ ณ จุดใดจุดหนึ่ง และมีเว็บเนื้อหาจำนวนมากพอที่พูดซ้ำจนตอนนี้มันทำหน้าที่เหมือนภูมิปัญญาที่ยอมรับกันแล้ว มากกว่าจะเป็นข้อเท็จจริงที่ตรวจสอบได้ วิธีแก้ที่ตรงไปตรงมาไม่ใช่การสมมติว่า ERP ไม่มีความเสี่ยงเลย แต่คือการแทนที่ตัวเลขที่ตรวจสอบไม่ได้ด้วยตัวเลขจริง
ข้อมูลจริงปี 2569 ของ Panorama บอกอะไรไว้จริงๆ
รายงานล่าสุดที่ Panorama เผยแพร่จริงระบุว่า มากกว่าหนึ่งในสี่ขององค์กรที่สำรวจใช้งบประมาณเกินกว่าที่วางแผนไว้ นี่คือความเสี่ยงจริงที่มีความหมาย แต่ต่างจาก "ล้มเหลว 73%" อย่างสิ้นเชิงในเชิงหมวดหมู่ สาเหตุหลักไม่ใช่การวางแผนที่แย่แบบลอยๆ หรือการเลือกเทคโนโลยีที่ถูกลิขิตให้ล้มเหลว แต่เป็นการที่องค์กรพบระหว่างโครงการว่าต้องการเทคโนโลยีเพิ่มเติมที่ไม่มีใครกำหนดขอบเขตไว้ตั้งแต่แรก ผลักดันให้ต้องขยายขอบเขตงานและสร้างส่วนที่กำหนดเองเพิ่มเติมที่ไม่ได้ตั้งราคาไว้ตั้งแต่ต้น
รายงานเดียวกันยังพบว่า Business Intelligence คือโครงการดิจิทัลที่ถูกนำไปใช้อย่างมีนัยสำคัญมากที่สุด โดย 55.3% ขององค์กรรายงานว่ามีการใช้งานอย่างมีนัยสำคัญ ซึ่งแปลว่าธุรกิจในงานวิจัยนี้โดยรวมกำลังลงทุนในชั้นการรายงานและการมองเห็นข้อมูลของการดำเนินงานอย่างจริงจัง ไม่ใช่ล้มเลิกโครงการกันเป็นกลุ่มใหญ่ การใช้งบเกินและการล้มเหลวโดยสิ้นเชิงคือผลลัพธ์ที่ต่างกัน และการเอามาปนกันคือวิธีที่ทำให้ความเสี่ยงจริงที่แคบ (งบบานเพราะเทคโนโลยีที่ไม่ได้กำหนดขอบเขต) กลายเป็นตำนานเมืองที่บวมขึ้น (สามในสี่ของโครงการล่มสลาย)
ลองนึกภาพ สิ่งที่ Phantom Statistic ทำให้ต้องเสียไปจริงๆ
ลองนึกภาพบริษัทสมมติชื่อ "บ้านสวน เฟอร์นิเจอร์" ผู้ผลิตเฟอร์นิเจอร์ไทยสมมติ เจ้าของอ่านเจอ "73% ของโครงการ ERP ล้มเหลว" บนบล็อกเปรียบเทียบซอฟต์แวร์ แล้วเก็บโครงการระบบสต็อกและการผลิตที่วางแผนไว้ขึ้นหิ้งไปหนึ่งปีเต็ม เพราะกังวลว่าโอกาสมันเสียเปรียบตั้งแต่วันแรก ความกลัวนั้นไม่ได้ไร้เหตุผลในตัวมันเอง มันแค่สร้างขึ้นจากตัวเลขที่ไม่มีมูลจริง ระหว่างนั้นบ้านสวนก็ยังคงแบกรับต้นทุนที่ ERP ตัวนี้ควรจะแก้ไปเรื่อยๆ สินค้าหมดสต็อกที่ป้องกันได้ แผนการผลิตที่วางแผนตามจำนวนวัตถุดิบผิด ทีมจัดซื้อสั่งของแบบมองไม่เห็นภาพ ต้นทุนนั้นเป็นของจริง และมันพอกพูนไปตลอดทั้งปี ส่วนสถิติที่ทำให้การแก้ไขต้องล่าช้าไปนั้นไม่ใช่ของจริงเลย
พอเจ้าของได้อ่านข้อมูลจริงของ Panorama ในที่สุด ความเสี่ยงจริงกลับเจาะจงและจัดการได้ คือเฝ้าระวังจุดที่โครงการต้องการเทคโนโลยีมากกว่าที่ใครกำหนดขอบเขตไว้ตั้งแต่แรก แล้วตามให้ทันช่องว่างนั้นด้วยขั้นตอนสำรวจความต้องการที่รัดกุมขึ้น ไม่ใช่ยกเลิกไอเดียทั้งหมดเพราะบล็อกโพสต์ที่ตรวจสอบไม่ได้
ความเสี่ยงที่ควรวางแผนรับจริงๆ
ถ้าความต้องการเทคโนโลยีที่ไม่ได้กำหนดขอบเขตคือสาเหตุจริงที่ตรวจสอบได้ของงบ ERP บานปลาย วิธีแก้ก็เจาะจงพอกัน คือระบุการเชื่อมต่อระบบ งานย้ายข้อมูล และความต้องการด้านรายงานทั้งหมดในขั้นตอนสำรวจความต้องการ ก่อนที่ผู้ขายรายใดจะตั้งราคาว่า "สุดท้ายแล้ว" และตั้งงบสำรองไว้สำหรับเทคโนโลยีที่ยังมองไม่เห็นตอนนี้ ไม่ใช่เทคโนโลยีที่เห็นอยู่แล้ว สำหรับภาพที่ลึกกว่านี้ว่าความเสี่ยงงบบานปลายแบบเดียวกันนี้แสดงออกต่างกันอย่างไรระหว่างเส้นทาง ERP แบบกำหนดเองกับแบบสำเร็จรูป การเปรียบเทียบสิ่งที่งานวิจัยการติดตั้งระดับโลกที่ใหญ่กว่าบอกไว้เกี่ยวกับความเสี่ยงแบบสร้างเองกับซื้อสำเร็จรูป คุ้มค่าที่จะอ่านก่อนตัดสินใจเลือกทางใดทางหนึ่ง และเนื่องจากข้อมูล Business Intelligence บอกว่าองค์กรที่มีวินัยมากกว่ากำลังลงทุนในการมองเห็นข้อมูลจริงๆ ก็ควรตรวจสอบด้วยว่าสต็อก การจัดซื้อ การขาย และบัญชีควรเชื่อมกันอย่างไร ก่อนจะสรุปว่าช่องว่างการรายงานของคุณตอนนี้เป็นปัญหาซอฟต์แวร์ ไม่ใช่ปัญหาความเป็นเจ้าของข้อมูล
The Real-Risk Playbook
- Verify Before You Fear ตรวจสอบก่อนจะกลัว — ก่อนสถิติใดจะเปลี่ยนการตัดสินใจด้านงบประมาณจริง ให้ตรวจสอบว่ามันปรากฏบนหน้าเว็บของแหล่งข้อมูลที่ถูกอ้างถึงจริงหรือเปล่า ถ้าไม่มีภายในสองนาที ให้ถือว่าเป็นเสียงรบกวน ไม่ใช่หลักฐาน
- Scope the Unscoped กำหนดขอบเขตสิ่งที่ยังไม่ถูกกำหนด — ระบุการเชื่อมต่อระบบ งานทำความสะอาดข้อมูล และความต้องการด้านรายงานที่โครงการน่าจะต้องใช้เพิ่มเติมนอกเหนือไลเซนส์หลัก ก่อนจะถือว่าใบเสนอราคาใดเป็นราคาสุดท้าย
- Budget the Real Overrun, Not the Fake One ตั้งงบสำรองรับความเสี่ยงจริง ไม่ใช่ความเสี่ยงปลอม — งบสำรองที่ตั้งไว้สำหรับ "อาจต้องการเทคโนโลยีเพิ่มระหว่างโครงการ" คือการวางแผนที่สมจริง ส่วนงบสำรองที่ตั้งไว้สำหรับ "ล้มเหลว 73%" คือการเดาที่แต่งตัวเป็นความระมัดระวัง
- Cross-Industry Check ตรวจสอบข้ามอุตสาหกรรม — กลุ่มคลินิกเอกชนที่กำลังพิจารณาระบบเวชระเบียนใหม่ก็เจอแพทเทิร์น Phantom Statistic แบบเดียวกัน อัตราความล้มเหลวที่น่ากลัวแพร่กระจายในเนื้อหาขาย IT สำหรับสุขภาพเช่นกัน และสาเหตุความเสี่ยงจริงมักเป็นตัวเดียวกันเสมอ คือเทคโนโลยีที่ไม่ได้กำหนดขอบเขตที่ถูกพบระหว่างโครงการ ไม่ใช่โอกาสล้มเหลวแบบเหรียญหัวก้อย
Traceable สรุปสิ่งที่ทุกอย่างโยงมาที่จุดเดียว
ถ้าต้องเหลือคำเดียวที่อธิบายวิธีรับมือกับสถิติ ERP ใดๆ ก่อนที่มันจะเปลี่ยนการตัดสินใจจริง คำนั้นคือ Traceable หรือ ตามรอยได้ ไม่ใช่ว่าคุณเห็นมันถูกพูดซ้ำกี่ครั้ง แต่คือคุณตามรอยมันกลับไปเจอบนหน้าเว็บขององค์กรที่มันถูกอ้างถึงได้จริงหรือเปล่า
คำถามที่ควรลองถามตัวเองคือ ตัวเลขตัวถัดไปที่ทำให้คุณกังวลเรื่องการตัดสินใจซอฟต์แวร์ คุณตามรอยมันกลับไปหาที่มาได้ภายในสองนาทีไหม ถ้าตามไม่ได้ ตัวเลขนั้นน่าจะทำให้คุณเสียเวลาจากความล่าช้าไปมากกว่าความเสี่ยงจริงที่มันอ้างว่ากำลังเตือนคุณอยู่แล้ว
คำถามที่พบบ่อย
จริงไหมที่โครงการ ERP ส่วนใหญ่ล้มเหลว
ไม่มีข้อมูลที่น่าเชื่อถือและตรวจสอบได้รองรับตัวเลขที่ใกล้เคียงกับคำว่า "ส่วนใหญ่" เลย รายงานล่าสุดที่ Panorama เผยแพร่จริง ซึ่งเป็นแหล่งที่ถูกอ้างถึงบ่อยที่สุดสำหรับข้อกล่าวอ้างเรื่องความล้มเหลวสูง รายงานว่างบประมาณบานปลายเกิดขึ้นกับมากกว่าหนึ่งในสี่ของโครงการ ไม่ใช่อัตราล้มเหลวส่วนใหญ่
"ล้มเหลว 73%" และ "งบบาน 215%" มาจากไหนจริงๆ
ไม่ปรากฏบนเว็บไซต์ของ Panorama Consulting เอง มันแพร่กระจายอยู่ในเนื้อหาซอฟต์แวร์สำหรับ SME รอง ถูกอ้างว่ามาจาก Panorama ซ้ำแล้วซ้ำเล่าโดยไม่มีลิงก์ที่ตามรอยกลับไปหารายงานเฉพาะเจาะจงของ Panorama ที่มีตัวเลขเหล่านี้อยู่จริง
ข้อมูลจริงและตรวจสอบได้ปี 2569 ของ Panorama บอกอะไรไว้จริงๆ
บอกว่ามากกว่าหนึ่งในสี่ขององค์กรใช้งบประมาณเกินที่วางแผนไว้ ส่วนใหญ่เพราะพบระหว่างโครงการว่าต้องการเทคโนโลยีเพิ่มเติมที่ไม่มีใครกำหนดขอบเขตไว้ตั้งแต่ต้น และ Business Intelligence คือโครงการดิจิทัลที่ถูกนำไปใช้อย่างมีนัยสำคัญมากที่สุดในกลุ่มองค์กรที่ศึกษา
การใช้งบเกินแปลว่าโครงการ ERP ล้มเหลวหรือเปล่า
ไม่ใช่ การใช้งบเกินคือความเสี่ยงจริงที่ควรจัดการ แต่เป็นผลลัพธ์ที่ต่างจากโครงการที่ถูกล้มเลิกหรือส่งมอบไม่ได้ การถือว่าทั้งสองอย่างเหมือนกันคือวิธีที่ทำให้สถิติจริงที่แคบกลายเป็นความเชื่อผิดๆ ที่บวมเกินจริง
สาเหตุที่ตรวจสอบได้จริงที่สำคัญที่สุดของงบ ERP บานปลายคืออะไร
การพบระหว่างโครงการว่าต้องการเทคโนโลยีเพิ่มเติมนอกเหนือจากที่กำหนดขอบเขตไว้ตั้งแต่แรก ซึ่งผลักดันให้โครงการต้องขยายขอบเขตงานและสร้างส่วนที่กำหนดเองที่ไม่มีใครตั้งราคาไว้ตั้งแต่ต้น
ข้อมูลของ Panorama ใช้ได้ตรงกับความเสี่ยงของ SME ไทยขนาดเล็กหรือเปล่า
ควรมองเป็นสัญญาณเชิงทิศทางว่างบบานปลายมักมาจากไหน ไม่ใช่การพยากรณ์ตัวเลขตรงตัวสำหรับโครงการระดับ SME องค์กรที่ Panorama ศึกษามักมีขนาดใหญ่กว่าและหลายแห่งเป็นบริษัทข้ามชาติ ดังนั้นแพทเทิร์นที่อยู่เบื้องหลังจึงนำไปใช้ได้มากกว่าตัวเปอร์เซ็นต์ที่แน่นอน
หน้าตาแบบนี้เมื่อใช้ NAWA ERP
NAWA ERP เปิดใช้งานเป็นขั้นตอน เริ่มจากกระบวนการที่มีปัญหาด้านต้นทุน ความเสี่ยง หรือรายงานชัดเจนที่สุดก่อน เพื่อให้ความต้องการเทคโนโลยีที่ไม่ได้กำหนดขอบเขตปรากฏขึ้นตั้งแต่เนิ่นๆ ทีละโมดูล แทนที่จะโผล่มาพร้อมกันหลังงบถูกล็อกไปแล้ว ความเป็นเจ้าของ ข้อมูล การควบคุม ข้อยกเว้น และขอบเขตการเชื่อมต่อถูกกำหนดไว้ก่อนแต่ละโมดูลจะเปิดใช้งานจริง ไม่ใช่ถูกค้นพบกลางทาง
ถ้าสถิติที่น่ากลัวตัวหนึ่งกำลังขวางกั้นธุรกิจของคุณจากการตัดสินใจที่จำเป็นต้องทำจริงๆ คุยกับเราเรื่องการกำหนดขอบเขตความเสี่ยงจริงก่อนจะตัดสินใจอะไรทั้งนั้น