ระบบบริหารการผลิตล้มเหลว | 5 รอยแยกที่ตัดสินผลก่อนวันขึ้นระบบ

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

ความล้มเหลวของระบบบริหารการผลิตถูกกำหนดตั้งแต่ขั้นวางแผน ไม่ใช่วันขึ้นระบบ

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

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

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

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

ต่อไปนี้คือสรุปรอยแยกทั้ง 5 จุดที่บทความนี้จะกล่าวถึง แต่ละหัวข้อถัดจากนี้จะเจาะลึกทีละบรรทัดของตาราง

ทั้งห้าข้อนี้ไม่ได้เป็นอิสระต่อกัน ถ้าแบ่งซอยผิดที่รอยแยกที่ 2 เวลาสำหรับเขียนข้อกำหนดในรอยแยกที่ 3 จะหายไป การจัดระเบียบข้อมูลหลักในรอยแยกที่ 4 จะถูกผลักไปงานปลายน้ำ และช่วงเวลาอบรมในรอยแยกที่ 5 จะถูกตัดเป็นอย่างสุดท้าย ความล้มเหลวไม่ได้เกิดขึ้นที่จุดเดียว แต่ดำเนินไปในรูปที่การตัดสินใจต้นน้ำค่อย ๆ ทำลายทางเลือกของปลายน้ำ

ดูความล้มเหลวจากข้อมูลจริง | คุณภาพ งบประมาณ และระยะเวลาถูกกำหนดด้วยขนาดโครงการ

เพื่อไม่ให้เริ่มจากความรู้สึก เราขอวางข้อมูลสำรวจที่เผยแพร่สาธารณะไว้ก่อน แหล่งอ้างอิงคือรายงานสำรวจแนวโน้ม IT ขององค์กร ปี 2026 ที่สมาคมผู้ใช้ระบบสารสนเทศแห่งประเทศญี่ปุ่น (JUAS) เผยแพร่เมื่อเดือนเมษายน 2026 เป็นการสำรวจปีงบประมาณ 2025 จากบริษัทผู้ตอบราว 950 ถึง 1,000 แห่ง เป็นการสำรวจที่ติดตามองค์กรผู้ใช้ในญี่ปุ่นแบบอนุกรมเวลาต่อเนื่องยาวนาน และรวบรวมสถานะการรักษาคุณภาพ งบประมาณ และระยะเวลา (QCD) ของการพัฒนาระบบไว้อย่างต่อเนื่อง

ผลสำรวจระบุว่า ระดับการรักษา QCD ของการพัฒนาระบบมีแนวโน้มลดลงโดยรวมตลอด 10 ปีที่ผ่านมา และสิ่งที่ควรจับตาคือรายละเอียดภายในที่แยกกันชัดเจนตามขนาดโครงการ โครงการขนาดเล็กอยู่ในเกณฑ์ค่อนข้างดี ขณะที่โครงการขนาด 500 คน-เดือนขึ้นไป มีสัดส่วนการประเมินเชิงลบ 30 ถึง 50 เปอร์เซ็นต์ในทุกด้าน ทั้งคุณภาพ งบประมาณ และระยะเวลา

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

ผลสำรวจจากต่างประเทศก็ชี้ไปทางเดียวกัน ผลสำรวจของ Gartner ปี 2024 ที่ Nomura Research Institute นำมาอ้าง ระบุว่ากว่า 70 เปอร์เซ็นต์ของโครงการนำแพ็กเกจ ERP มาใช้และปรับปรุงใหม่ จบลงโดยไม่บรรลุเป้าหมายทางธุรกิจที่ตั้งไว้ตอนต้น สิ่งที่ต้องระวังคือ คำว่า “ล้มเหลว” ในที่นี้ไม่ได้แปลว่าระบบเดินไม่ได้ ระบบเดินได้ แต่เมื่อเดินได้แล้วกลับไปไม่ถึงเป้าหมายทางการบริหารที่ประกาศไว้ตอนแรก รอยแยกที่ 1 ซึ่งว่าด้วยวัตถุประสงค์ คือปัญหาที่ตัวเลขนี้กำลังบอกโดยตรง

นอกจากนี้ ผลสำรวจชุดเดียวกันของ JUAS ระบุว่า ในปีงบประมาณ 2025 บริษัทที่งบ IT เพิ่มขึ้นมีสัดส่วน 52.6 เปอร์เซ็นต์ ค่า DI อยู่ที่ 43.3 จุด เพิ่มขึ้นต่อเนื่องเป็นปีที่ 5 และค่า DI คาดการณ์ของปีงบประมาณ 2026 อยู่ที่ 39.9 จุด เหตุผลของการเพิ่มงบที่ถูกยกมาเป็นอันดับต้น ได้แก่ การอัปเดต เปลี่ยนใหม่ และเสริมฟังก์ชันของระบบเดิม 66.3 เปอร์เซ็นต์ ค่าเงินเยนอ่อนกับค่าแรงและค่าใช้จ่ายผู้ขายที่สูงขึ้น 46.6 เปอร์เซ็นต์ และการใช้บริการคลาวด์ที่เพิ่มขึ้น 45.0 เปอร์เซ็นต์ (ทั้งหมดเป็นคำถามตอบได้หลายข้อ ตัวเลขจึงเป็นสัดส่วนของบริษัทที่ยกเหตุผลนั้น) อ่านได้ว่าแม้งบจะเพิ่มขึ้น แต่แรงจูงใจหลักของการเพิ่มอยู่ฝั่งการบำรุงรักษาระบบเดิมและราคาต่อหน่วยที่สูงขึ้น ไม่ได้แปลว่าวงเงินสำหรับความริเริ่มใหม่จะขยายตามไปโดยอัตโนมัติ และเมื่อล้มเหลวหนึ่งครั้ง โอกาสลองใหม่จะถูกยกยอดไปรอบงบประมาณถัดไป

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

ผลสำรวจปีงบประมาณ 2025 ของ JUAS ชุดเดียวกัน สรุปปัจจัยอันดับหนึ่งที่ทำให้ QCD แย่ลงไว้ดังนี้

สามข้อนี้เรียงกันแล้วแทบจะลบล้างข้อถกเถียงแบบสองขั้วที่มักถูกยกมาพูด

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

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

ข้อสาม คำกล่าวที่ว่า “เริ่มเล็กแล้วสุดท้ายก็ต้องรื้อทำใหม่” ในเมื่อสถานะการรักษา QCD ของ JUAS ดีขึ้นเมื่อโครงการเล็กลง ข้อสรุปที่ว่าการแบ่งซอยคือมาตรการหลักในการลดความเสี่ยงจึงสอดคล้องกับข้อมูลมากกว่า การเลือกสร้างทุกอย่างในครั้งเดียวเพราะกลัวต้องรื้อทำใหม่ คือการเดินเข้าไปอยู่ในแถบ 500 คน-เดือนขึ้นไปด้วยตัวเอง

รอยแยกที่ 1 | รอยแยกของวัตถุประสงค์ — เมื่อการขึ้นระบบกลายเป็นเป้าหมายเสียเอง

Nomura Research Institute สรุปปัจจัยความล้มเหลวของโครงการนำ ERP มาใช้และปรับปรุงใหม่ไว้ 3 ข้อ ได้แก่ การขาดวิสัยทัศน์ที่เปรียบเสมือนดาวเหนือ ช่องว่างทางความคิดระหว่างหน้างานกับฝ่ายบริหาร และความยากของการบริหารเชิงบูรณาการระหว่างหลายโครงการ

ข้อแรกคือการขาดดาวเหนือ ซึ่งตรงกับรอยแยกที่ 1 เป็นปรากฏการณ์ที่เมื่อโครงการเดินหน้าไป วัตถุประสงค์ค่อย ๆ ถูกแทนที่อย่างเงียบ ๆ จาก “การแก้ปัญหาเชิงบริหาร” ไปเป็น “การขึ้นระบบให้ทันวันที่กำหนด”

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

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

เปลี่ยนเกณฑ์ตัดสินการขึ้นระบบจาก “เดินได้หรือไม่” เป็น “อะไรที่ลดลง”

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

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

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

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

รอยแยกที่ 2 | รอยแยกของขนาด — จะแบ่งระยะเวลาและคน-เดือนของการนำระบบบริหารการผลิตมาใช้อย่างไร

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

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

เกิน 50 คน-เดือนหรือ 6 เดือนต่อหนึ่งเฟส ให้ตั้งข้อสงสัยว่าควรแบ่ง

ในทางปฏิบัติ ที่บริษัทของเราใช้เป็นเกณฑ์คร่าว ๆ คือ เมื่อใดที่มีแผนซึ่งหนึ่งเฟสเกิน 50 คน-เดือนหรือ 6 เดือน เราจะพิจารณาก่อนว่าแบ่งได้หรือไม่ ตัวเลขนี้ไม่ใช่ตัวเลขที่ JUAS ระบุ แต่เป็นเกณฑ์เชิงปฏิบัติจากหน้างาน มีเหตุผลรองรับ 3 ข้อ

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

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

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

แนวการแบ่งนั้น การตัดตามความสมบูรณ์ของงานได้ผลดีกว่าการตัดตามฟังก์ชัน

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

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

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

รอยแยกที่ 3 | รอยแยกของข้อกำหนด — ไม่มีใครอธิบายงานปัจจุบันได้

ในผลสำรวจของ JUAS มีข้อคำถามเกี่ยวกับอุปสรรคของการเดินหน้าพัฒนาระบบด้วยทีมภายใน (ตอบได้หลายข้อ n=953) อันดับต้นคือ ขาดแคลนบุคลากรพัฒนาเชิงปริมาณ 52.7 เปอร์เซ็นต์ ขาดแคลนเชิงคุณภาพ 49.6 เปอร์เซ็นต์ และขาดบุคลากรบริหารโครงการ 44.4 เปอร์เซ็นต์ แต่ที่หนักกว่าในทางปฏิบัติคือรายการที่เรียงถัดจากนั้น

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

และผลสำรวจของ JUAS ยังระบุว่า ราว 6 ใน 10 ของบริษัทกำลังนำการพัฒนาระบบบางส่วนหรือทั้งหมดกลับมาทำเอง โดยพยายามใช้ทีมภายในควบคู่กับการจ้างภายนอกตามความเหมาะสม และเป้าหมายของการทำเองนั้นเน้นไปที่งานต้นน้ำ เช่น การวางแผนระบบและการกำหนดความต้องการ กล่าวคือ องค์กรพยายามดึงงานต้นน้ำกลับมาไว้กับตัว แต่กลับขาดความเข้าใจงานปัจจุบันซึ่งจำเป็นต่องานต้นน้ำ นี่คือโครงสร้างขององค์กรผู้ใช้ในปัจจุบัน ผลสำรวจเดียวกันยังชี้ไปทางเดียวกัน เมื่อพบว่าความสามารถที่ขาดแคลนในองค์กร IT อันดับต้น ได้แก่ การสรรหาและพัฒนาบุคลากร IT 73.9 เปอร์เซ็นต์ การใช้ประโยชน์และบริหารข้อมูล 71.9 เปอร์เซ็นต์ และการค้นหาและประเมินเทคโนโลยีใหม่ 69.5 เปอร์เซ็นต์ (n ประมาณ 946)

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

วิธีรับมือนั้นเรียบง่ายจนน่าเบื่อ ก่อนสั่งจ้าง ให้ฝ่ายผู้ว่าจ้างเขียนงานปัจจุบันออกมาด้วยมือของตัวเอง ไม่จำเป็นต้องวาดผังกระบวนการทำงานให้ครบถ้วนทุกซอกมุม เพียงเขียน 4 ข้อต่อไปนี้ให้ได้หนึ่งหน้าต่อหนึ่งงานเป้าหมายก็เพียงพอ

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

จุดแยกระหว่างการปรับแต่งระบบบริหารการผลิตกับการพัฒนาขึ้นใหม่ทั้งหมด

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

การตัดสินใจต้องทำเป็นรายพื้นที่ฟังก์ชัน ไม่ใช่เหมารวมทั้งงาน แม้อยู่ในระบบเดียวกัน พื้นที่ที่ใช้ฟังก์ชันมาตรฐานได้ กับพื้นที่ที่ต้องสร้างขึ้นเฉพาะองค์กร ย่อมแยกจากกันเสมอ

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

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

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

รอยแยกที่ 4 | รอยแยกของข้อมูล — ระบบที่ข้อมูลผลผลิตจริงไม่ไหลเข้า จะตายในเดือนถัดไป

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

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

รอยแยกของข้อมูลแยกเป็นสองฝั่ง คือฝั่งข้อมูลหลักและฝั่งข้อมูลผลผลิตจริง

วัดความแม่นยำของข้อมูลหลักก่อนย้ายข้อมูล

การย้ายข้อมูลหลักถูกปฏิบัติในหลายโครงการเสมือนเป็น “งานขนข้อมูล” และถูกวางไว้ในงานปลายน้ำ แต่ในความเป็นจริง ความแม่นยำของข้อมูลหลักคือคุณภาพการดำเนินงานปัจจุบันโดยตรง และการขนย้ายเฉย ๆ ไม่ได้ทำให้ปัญหาหายไป

สิ่งที่ต้องวัดก่อนย้ายข้อมูลเสมอมี 4 อย่างต่อไปนี้ คำว่าวัดในที่นี้หมายถึงการสุ่มตัวอย่างออกมาเทียบกับของจริง

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

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

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

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

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

รอยแยกที่ 5 | รอยแยกของการใช้งานจริง — ที่โรงงานในไทย การทำให้ติดเป็นนิสัยคือด่านสุดท้าย

สี่ข้อที่ผ่านมาใช้ร่วมกันได้ทั้งในญี่ปุ่นและที่โรงงานต่างประเทศ มีเพียงรอยแยกที่ 5 เท่านั้นที่น้ำหนักเปลี่ยนไปเมื่ออยู่ที่โรงงานต่างประเทศ โดยเฉพาะโรงงานของบริษัทญี่ปุ่นในประเทศไทย

เมื่อขยายระบบที่ออกแบบจากสำนักงานใหญ่ในญี่ปุ่นมายังโรงงานในไทย มักมีสมมติฐานที่ถูกวางไว้อย่างไม่รู้ตัว นั่นคือสมมติฐานที่ว่า “คนที่ใช้งานจะอ่านคู่มือภาษาญี่ปุ่นหรือภาษาอังกฤษ และเข้าใจเบื้องหลังของกฎการทำงาน” โรงงานที่สมมติฐานนี้เป็นจริงมีไม่มากนัก ต่อไปนี้ไม่ใช่สถิติ แต่เป็นโครงสร้างที่พบซ้ำ ๆ จากการทำงานจริง (สำหรับสภาพแวดล้อมทางธุรกิจของบริษัทญี่ปุ่นในไทยโดยรวม โปรดดูผลสำรวจแนวโน้มการลงทุนของ JETRO ที่ยกไว้ในแหล่งอ้างอิงท้ายบทความ)

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

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

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

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

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

วิธีสอดแทรกประเด็นเหล่านี้เข้าไปในแผน เราได้เรียบเรียงไว้ในการนำระบบไปใช้ที่โรงงานต่างประเทศ พร้อมกับการแบ่งบทบาทระหว่างสำนักงานใหญ่กับท้องถิ่น และวิธีกำหนดลำดับการขยายผล

ลำดับการนำระบบมาใช้ที่เลี่ยงความล้มเหลว | 6 สิ่งที่ต้องตัดสินก่อนสั่งจ้าง

เมื่อแปลงรอยแยกทั้ง 5 ข้างต้นให้เป็นการลงมือก่อนสั่งจ้าง จะได้ออกมา 6 รายการ ลำดับมีความหมาย หากไม่ตัดสินจากบนลงล่าง รายการที่อยู่ล่างจะตัดสินไม่ได้

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

พูดกลับกัน ถ้าขอใบเสนอราคาในสภาพที่ 6 รายการนี้ถูกกรอกครบแล้ว ความต่างของราคาจากแต่ละบริษัทจะอ่านออก ความต่างจะมาจากขอบเขตงานที่แต่ละรายคาดไว้ ประสบการณ์ของคนที่จะถูกมอบหมาย หรือวิธีประเมินความเสี่ยง อย่างใดอย่างหนึ่ง แต่ถ้าขอใบเสนอราคาทั้งที่ 6 รายการยังไม่นิ่ง แต่ละบริษัทจะบวกราคาโดยตั้งสมมติฐานว่าตนต้องแบกเรื่องที่ยังไม่ตัดสินไว้เอง ราคาจึงกระจาย และการเปรียบเทียบเองก็เกิดขึ้นไม่ได้

ในแง่ของลำดับการนำระบบมาใช้ ให้กันช่วงเวลาสำหรับตรึง 6 รายการนี้ไว้อย่างชัดเจนในฐานะงานก่อนหน้าการกำหนดความต้องการ หากวางจุดนี้ไว้นอกแผนในฐานะ “การเตรียมตัว” ในความเป็นจริงมันจะถูกทำคู่ขนานไปหลังคิกออฟ และหนี้ที่ค้างชำระตามที่กล่าวไว้ในรอยแยกที่ 3 ก็จะเกิดขึ้น

คำถามที่พบบ่อย (FAQ)

อัตราความล้มเหลวของการนำระบบบริหารการผลิตมาใช้อยู่ที่เท่าใด

สถิติอัตราความล้มเหลวอย่างเป็นทางการที่จำกัดเฉพาะระบบบริหารการผลิตนั้นยังไม่มีที่เป็นหลักเป็นฐาน ตัวชี้วัดที่ใกล้เคียงและอ้างอิงได้มี 2 แหล่ง แหล่งแรกคือรายงานสำรวจแนวโน้ม IT ขององค์กร 2026 ของ JUAS ซึ่งระบุว่าระดับการรักษา QCD ของการพัฒนาระบบมีแนวโน้มลดลงโดยรวมตลอด 10 ปีที่ผ่านมา และในโครงการขนาด 500 คน-เดือนขึ้นไป ทั้งคุณภาพ งบประมาณ และระยะเวลา มีการประเมินเชิงลบ 30 ถึง 50 เปอร์เซ็นต์ อีกแหล่งคือผลสำรวจของ Gartner ปี 2024 ที่ Nomura Research Institute นำมาอ้าง ซึ่งระบุว่ากว่า 70 เปอร์เซ็นต์ของโครงการนำแพ็กเกจ ERP มาใช้และปรับปรุงใหม่ จบลงโดยไม่บรรลุเป้าหมายทางธุรกิจที่ตั้งไว้ตอนต้น สิ่งที่ควรอ่านจากสองแหล่งนี้ไม่ใช่ตัวเลขอัตราความล้มเหลว แต่คือโครงสร้างที่ว่าการกระจายตัวของความล้มเหลวขึ้นอยู่กับขนาด โครงการเล็กอยู่ในเกณฑ์ค่อนข้างดี ยิ่งใหญ่ยิ่งมีการประเมินเชิงลบมากขึ้น กล่าวคือ ความน่าจะเป็นของความล้มเหลวไม่ใช่เงื่อนไขที่ถูกกำหนดมาให้ แต่เป็นตัวแปรที่ฝ่ายผู้ว่าจ้างขยับได้ด้วยวิธีแบ่งซอยโครงการ อนึ่ง สถิติเฉพาะภูมิภาคอย่าง “ในไทยล้มเหลวกี่เปอร์เซ็นต์” นั้นไม่มีอยู่จริง หากพบตัวเลขลักษณะนั้น โปรดตรวจสอบแหล่งที่มา

การนำระบบบริหารการผลิตมาใช้ใช้เวลานานเท่าใด

เนื่องจากขอบเขตงาน จำนวนโรงงาน รูปแบบการผลิต และสภาพของระบบเดิม ทำให้ตัวเลขต่างกันหลายเท่าตัว การระบุระยะเวลาทั่วไปจึงแทบไม่มีความหมาย คำถามที่ใช้งานได้จริงกว่าคือ “จะตัดหนึ่งเฟสไว้ตรงไหน” ที่บริษัทของเรา เมื่อมีแผนซึ่งหนึ่งเฟสเกิน 50 คน-เดือนหรือ 6 เดือน เราจะพิจารณาทันทีว่าแบ่งได้หรือไม่ ตัวเลขนี้ไม่ใช่ตัวเลขที่ JUAS ระบุ แต่เป็นเกณฑ์เชิงปฏิบัติ โดยมีเหตุผลรองรับ 3 ข้อ ข้อแรก เมื่อเกิน 6 เดือน ผู้เกี่ยวข้องจะนึกไม่ออกว่าเบื้องหลังของข้อกำหนดที่ตัดสินไว้ตอนต้นคืออะไร ความรู้สึกขัดใจในขั้นทดสอบจึงถูกจัดการในฐานะการเปลี่ยนข้อกำหนด ข้อสอง ภายในครึ่งปีถึงหนึ่งปีจะเกิดการโยกย้ายผู้รับผิดชอบและการเปลี่ยนสินค้าที่ผลิต ทำให้ต้องเล็งเป้าที่เคลื่อนที่อยู่ตลอด ข้อสาม ยิ่งเฟสใหญ่ ยิ่งตัดสินใจหยุดกลางทางไม่ได้ คุณค่าที่แท้จริงของการแบ่งซอยไม่ใช่การลดต้นทุน แต่คือการมีโอกาสตัดสินใจได้หลายครั้ง การย่นรอบการตัดสินใจหนึ่งรอบให้สั้นลง ให้ผลลัพธ์ออกมาเร็วกว่าการพยายามย่นระยะเวลารวมทั้งโครงการ

ระหว่างแพ็กเกจกับการพัฒนาขึ้นใหม่ทั้งหมด แบบไหนล้มเหลวยากกว่ากัน

คำถามนี้เองที่หลุดออกจากปัจจัยหลักของความล้มเหลว ในผลสำรวจปีงบประมาณ 2025 ของ JUAS ปัจจัยอันดับหนึ่งที่ทำให้ QCD แย่ลงคือ ระยะเวลาได้แก่การพิจารณาไม่รอบด้านตอนวางแผน งบประมาณได้แก่การเปลี่ยนข้อกำหนดบ่อย และคุณภาพได้แก่ทักษะของผู้ขายไม่เพียงพอ (คิดเป็น 6 ใน 10 ของบริษัทที่ตอบว่าไม่พอใจคุณภาพ) ทั้งสามข้อนี้เป็นอิสระจากการเลือกวิธีสร้าง ต่อให้เลือกแพ็กเกจ ถ้าตอนวางแผนไม่ได้เผื่อแรงงานสำหรับกลืนส่วนต่างของงาน ระยะเวลาก็ยังบานปลาย และถ้าเข้าสู่การพัฒนาก่อนที่ความต้องการจะนิ่ง การเปลี่ยนข้อกำหนดก็ยังถล่มลงมา สิ่งที่ควรตัดสินจึงไม่ใช่ประเภทของผลิตภัณฑ์ แต่คือเส้นแบ่งว่าจะโน้มไปหาฟังก์ชันมาตรฐานหรือสร้างขึ้นเฉพาะ เป็นรายพื้นที่ฟังก์ชัน พื้นที่ที่ไม่เชื่อมโยงกับความสามารถในการแข่งขันโดยตรงและทำแบบเดียวกับบริษัทอื่นได้ ให้โน้มไปหามาตรฐาน ส่วนพื้นที่ที่จุดแข็งขององค์กรฝังตัวอยู่ และพื้นที่ที่ลูกค้าหรือหน่วยงานกำกับกำหนดรูปแบบมา ให้สร้างขึ้นเฉพาะ โดยขีดเส้นแบ่งนี้เป็นรายพื้นที่ฟังก์ชันหลังจากจัดทำเอกสารงานปัจจุบันแล้ว อนึ่ง หากเลือกทำเอง (พัฒนาขึ้นใหม่ภายในองค์กร) โปรดตรวจสอบก่อนว่าอุปสรรคของการพัฒนาด้วยทีมภายในที่ JUAS ระบุไว้ ได้แก่ ขาดแคลนบุคลากรพัฒนาเชิงปริมาณ 52.7 เปอร์เซ็นต์ เชิงคุณภาพ 49.6 เปอร์เซ็นต์ และขาดบุคลากรบริหารโครงการ 44.4 เปอร์เซ็นต์ นั้นตรงกับองค์กรของท่านหรือไม่

ควรปรับแต่งระบบบริหารการผลิตได้มากแค่ไหน

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

ระบบที่เคยล้มเหลวมาแล้ว ต้องรื้อทำใหม่อย่างเดียวหรือไม่

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

เมื่อจะนำระบบบริหารการผลิตมาใช้ที่โรงงานในไทย ควรระวังอะไรเป็นพิเศษ

มี 5 ข้อ ข้อแรกคือภาษาของหน้าจอและข้อความแจ้งข้อผิดพลาด พฤติกรรมของคนต่อหน้าจอที่ผู้ปฏิบัติงานท้องถิ่นอ่านไม่ออกคือการจำตำแหน่ง ซึ่งทำให้ต้องอบรมใหม่ทุกครั้งที่เปลี่ยนเลย์เอาต์ และไม่มีใครตัดสินใจได้เมื่อเกิดกรณีพิเศษ ข้อสองคือขอบเขตของการอบรม ที่ญี่ปุ่นสอนเพียงวิธีใช้งานก็มักเพียงพอ เพราะเบื้องหลังของกฎการทำงานถูกแบ่งปันกันอยู่แล้ว แต่ที่โรงงานต่างประเทศต้องอธิบายตั้งแต่ “ทำไมจึงต้องกรอกข้อมูลนี้” และ “ตัวเลขนี้ถูกใช้ทำอะไรในขั้นตอนถัดไป” ข้อสามคือคู่มือขั้นตอน ให้ตั้งอยู่บนสมมติฐานว่าคนจะหมุนเวียน แล้วตัดสินคู่มือภาษาท้องถิ่นและผู้รับผิดชอบการปรับปรุงคู่มือไว้ก่อนขึ้นระบบ ข้อสี่คือเส้นแบ่งระหว่างมาตรฐานของสำนักงานใหญ่กับความเหมาะสมของท้องถิ่น ในทางปฏิบัติ การแบ่งที่พังยากคือ ระบบรหัส โครงสร้างข้อมูลหลัก และรายการที่เชื่อมกับบัญชี เป็นมาตรฐานของสำนักงานใหญ่ ส่วนวิธีป้อนข้อมูลผลผลิตจริง เลย์เอาต์ของเอกสารหน้างาน และภาษา ให้ท้องถิ่นตัดสิน ข้อห้าคือระบบสนับสนุนในหนึ่งเดือนแรกหลังขึ้นระบบ หากช่วงนี้ไม่มีคนที่ตอบคำถามได้อยู่ในพื้นที่ วิธีใช้งานที่หน้างานสร้างขึ้นเองจะฝังตัวไปเลย อนึ่ง ทั้งหมดนี้เป็นโครงสร้างเชิงปฏิบัติที่พบซ้ำ ๆ ที่โรงงานในไทย ไม่ได้กล่าวในฐานะสถิติอย่างอัตราความล้มเหลวรายภูมิภาค

สรุป

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

สิ่งที่รายงานสำรวจแนวโน้ม IT ขององค์กร 2026 ของ JUAS แสดงคือ ระดับการรักษา QCD มีแนวโน้มลดลงโดยรวมตลอด 10 ปีที่ผ่านมา และในโครงการขนาด 500 คน-เดือนขึ้นไป ทั้งคุณภาพ งบประมาณ และระยะเวลา มีการประเมินเชิงลบ 30 ถึง 50 เปอร์เซ็นต์ ขณะที่โครงการขนาดเล็กอยู่ในเกณฑ์ค่อนข้างดี ปัจจัยอันดับหนึ่งที่ทำให้ QCD แย่ลงคือ ระยะเวลาได้แก่การพิจารณาไม่รอบด้านตอนวางแผน งบประมาณได้แก่การเปลี่ยนข้อกำหนดบ่อย และคุณภาพได้แก่ทักษะของผู้ขายไม่เพียงพอ (คิดเป็น 6 ใน 10 ของบริษัทที่ไม่พอใจคุณภาพ) ทั้งหมดนี้เป็นอิสระจากการเลือกวิธีสร้างว่าจะเป็นแพ็กเกจหรือพัฒนาใหม่ทั้งหมด และย้อนกลับไปที่วิธีแบ่งซอยขนาดกับวิธีกำหนดความต้องการ ตัวเลขจากผลสำรวจ Gartner ปี 2024 ที่ Nomura Research Institute นำมาอ้าง ซึ่งระบุว่ากว่า 70 เปอร์เซ็นต์ของโครงการ ERP จบลงโดยไม่บรรลุเป้าหมายทางธุรกิจที่ตั้งไว้ตอนต้น ก็แสดงเช่นกันว่าการขึ้นระบบกับความสำเร็จเป็นคนละเรื่อง

รอยแยกทั้ง 5 ที่บทความนี้วางไว้คือ วัตถุประสงค์ ขนาด ข้อกำหนด ข้อมูล และการใช้งานจริง ที่รอยแยกของวัตถุประสงค์ ให้เปลี่ยนเกณฑ์ตัดสินการขึ้นระบบจาก “เดินได้หรือไม่” เป็น “อะไรที่ลดลง” และเขียนค่าปัจจุบัน ค่าเป้าหมาย วิธีวัด และผู้รับผิดชอบการวัด ไว้เป็นชุดเดียวกัน ที่รอยแยกของขนาด เมื่อมีแผนซึ่งหนึ่งเฟสเกิน 50 คน-เดือนหรือ 6 เดือน ให้ตั้งข้อสงสัยว่าควรแบ่ง แล้วตัดด้วยกระบวนการทำงาน โรงงาน สินค้า หรือข้อมูล อย่างใดอย่างหนึ่ง ที่รอยแยกของข้อกำหนด ให้ฝ่ายผู้ว่าจ้างเขียนงานปัจจุบันออกมาด้วยมือของตัวเอง การที่อุปสรรคของการพัฒนาด้วยทีมภายในของ JUAS เรียงกันอยู่ว่า เข้าใจงานปัจจุบันไม่เพียงพอ 38.2 เปอร์เซ็นต์ ขาดความสามารถวางแผนระบบ 34.5 เปอร์เซ็นต์ และไม่ทราบข้อกำหนดของระบบปัจจุบัน 25.9 เปอร์เซ็นต์ แสดงว่างานนี้จ้างภายนอกไม่ได้ ที่รอยแยกของข้อมูล ให้วัดความแม่นยำของสินค้า BOM ขั้นตอนการผลิต และสต๊อกจริงก่อนย้ายข้อมูล และออกแบบการป้อนผลผลิตจริงให้เป็นส่วนหนึ่งของงานในกระบวนการ ที่รอยแยกของการใช้งานจริง ให้เตรียมคนฝั่งโรงงานที่รับช่วงการใช้งาน คู่มือขั้นตอนภาษาท้องถิ่น และระบบสนับสนุนหนึ่งเดือนแรกหลังขึ้นระบบ

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

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

แหล่งอ้างอิง

• รายงานผลสำรวจแนวโน้ม IT ขององค์กร ปี 2026 (สมาคมผู้ใช้ระบบสารสนเทศแห่งประเทศญี่ปุ่น JUAS, เมษายน 2026)
• ข่าวประชาสัมพันธ์ชุดที่ 1 ของผลสำรวจแนวโน้ม IT ขององค์กร ปี 2026 (JUAS, 2026)
• การสร้างการเปลี่ยนแปลงเชิงบริหารด้วยการนำ ERP มาใช้และปรับปรุงใหม่ — ถอดหลักความสำเร็จจากปัจจัยความล้มเหลว 3 ประการ (Nomura Research Institute, สิงหาคม 2025)
• ความยากและแนวทางรับมือของโครงการนำแพ็กเกจ ERP มาใช้และปรับปรุงใหม่ (Nomura Research Institute, NRI Management Review No.24, มกราคม 2026)
• JUAS เผยตัวเลขเบื้องต้นของผลสำรวจแนวโน้ม IT ขององค์กร ปี 2026 (i Magazine, กุมภาพันธ์ 2026)
• ผลสำรวจแนวโน้มการลงทุนของบริษัทญี่ปุ่นในประเทศไทย ปีงบประมาณ 2024 (JETRO, กุมภาพันธ์ 2025)