ระบบบริหารการผลิตล้าสมัย ประเมินการเปลี่ยนระบบด้วย 6 ตัวแปร

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

ทำไม “ยังใช้งานได้” กับ “ยังปลอดภัย” จึงเป็นคนละเรื่องกัน

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

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

วันสิ้นสุดการสนับสนุนถูกกำหนดไว้แล้วโดยไม่เกี่ยวกับความพร้อมของเรา

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

ตัวแรกคือ IBM i ซึ่งสืบสายมาจาก AS/400 รุ่นเก่า การสนับสนุนแบบขยายเวลาของ IBM i 7.3 จะสิ้นสุดในวันที่ 30 กันยายน 2026 และวันเดียวกันนี้ยังเป็นวันสิ้นสุดการสนับสนุนมาตรฐานของ IBM i 7.4 ด้วย กำหนดเส้นตายสองแบบที่มีลักษณะต่างกันจึงมาซ้อนกันในวันเดียว ทั้งโรงงานที่ยังใช้ 7.3 อยู่ และโรงงานที่คิดว่าอัปเกรดเป็น 7.4 แล้วจึงสบายใจได้ ต่างก็ถูกบีบให้ตัดสินใจในวันเดียวกัน

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

กรณีที่รันบนเซิร์ฟเวอร์ Windows ก็เช่นเดียวกัน Windows Server 2016 สิ้นสุดการสนับสนุนหลักไปตั้งแต่เดือนมกราคมปี 2022 และการสนับสนุนแบบขยายเวลาก็จะสิ้นสุดในวันที่ 12 มกราคม 2027 หลังจากนั้นยังเหลือกลไกแบบมีค่าใช้จ่ายที่เรียกว่าการอัปเดตความปลอดภัยแบบขยายเวลา หรือ Extended Security Updates (ESU) แต่กลไกนี้ถูกออกแบบให้ราคาสูงขึ้นเป็นขั้นบันไดในแต่ละปี พูดอีกอย่างคือ ESU ไม่ใช่ “วิธีใช้ระบบเดิมต่อไป” แต่เป็น “กลไกซื้อเวลาด้วยเงินจนกว่าจะย้ายระบบเสร็จ”

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

“เลิกผลิต” กับ “หมดระยะบำรุงรักษา” เจ็บคนละจุดกัน

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

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

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

“หน้าผาปี 2025” ยังไม่จบลง

“หน้าผาปี 2025” ที่กระทรวงเศรษฐกิจ การค้า และอุตสาหกรรมของญี่ปุ่นเป็นผู้จุดประเด็น ยังไม่คลี่คลายแม้จะเข้าปี 2026 แล้ว สวนทางกับความรู้สึกที่ชื่อนี้ให้ไว้ จากการวิเคราะห์ ณ เดือนมกราคมปี 2026 ระบุว่าบริษัทขนาดใหญ่ของญี่ปุ่น 74% ยังคงถือครองระบบไอทีที่ล้าสมัย หรือที่เรียกกันว่าระบบเลกาซี

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

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

สัญญาณความล้าสมัยไม่ได้โผล่ที่ตัวชี้วัดทางเทคนิค แต่โผล่ที่การสึกหรอของการปฏิบัติงาน

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

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

สัญญาณที่ 1 หน้างานใช้ Excel มาเสริมจนกลายเป็นเรื่องปกติ

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

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

สัญญาณที่ 2 ใบเสนอราคาสำหรับฟังก์ชันใหม่แพงขึ้นทุกครั้ง จนต้องล้มเลิกความต้องการบ่อยขึ้น

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

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

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

สัญญาณที่ 3 ผู้รับผิดชอบงานบำรุงรักษาฝั่งผู้ให้บริการลดลง และตอบสนองช้าลง

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

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

สัญญาณที่ 4 เริ่มติดข้อทักท้วงจากการตรวจสอบด้านความปลอดภัยภายใน

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

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

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

โมเดลให้คะแนนแบบ 6 ตัวแปรสำหรับตัดสินใจเปลี่ยนระบบ

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

เราจึงแปลงเป็นรูปแบบที่ให้คะแนน 6 ตัวแปร ตัวละ 0 ถึง 3 คะแนน แล้วตัดสินจากคะแนนรวม 0 ถึง 18 คะแนน เริ่มจากรายการตัวแปรก่อน

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

ตัวแปรที่ 1 จำนวนปีที่เหลือจนถึงวันสิ้นสุดการสนับสนุน

ให้ยึดตัวที่หมดอายุเร็วที่สุดในบรรดาระบบปฏิบัติการ ฐานข้อมูล มิดเดิลแวร์ และการบำรุงรักษาฮาร์ดแวร์ นี่เป็นตัวแปรที่มีโรงงานจำนวนมากตอบว่า “ยังไหวอยู่” ทั้งที่ยังไม่ได้ตรวจสอบครบทุกตัว

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

ตัวแปรที่ 2 ระดับการแย่ลงของเวลากู้คืนจากเหตุขัดข้อง

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

กรณีที่เข้าข่าย 3 คะแนน ส่วนใหญ่ไม่ใช่ปัญหาของระบบ แต่เป็นปัญหาที่ไม่เหลือคนที่เข้าใจโครงสร้างแล้ว ในกรณีนี้การแก้ไขเพียงบางส่วนจะไม่ช่วยให้จบ

ตัวแปรที่ 3 ขอบเขตที่ Excel เข้ามาเสริม

ให้วัดจาก “Excel รับผิดชอบงานส่วนไหน” ไม่ใช่ “ใช้ Excel หรือไม่”

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

ตัวแปรที่ 4 ระดับการหดตัวของทีมบำรุงรักษาฝั่งผู้ให้บริการ

เป็นเรื่องที่ถามยากอยู่ แต่คุ้มค่าที่จะถามตรง ๆ ถ้าถามว่า “บริษัทของท่านมีวิศวกรที่ดูแลระบบนี้ได้กี่ท่าน” แล้วไม่ได้คำตอบทันที ควรคิดไว้ก่อนว่าโดยเนื้อแท้แล้วกำลังพึ่งพาคนจำนวนน้อย เพราะถ้ารู้จำนวนอยู่แล้ว นี่เป็นคำถามที่ตอบได้ทันที

ตัวแปรที่ 5 ข้อทักท้วงจากการตรวจสอบด้านความปลอดภัย

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

ตัวแปรที่ 6 ความต้องการเชื่อมต่อกับระบบรอบข้าง

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

เมื่อให้คะแนนครบทั้ง 6 ตัวแปรแล้ว ให้นำคะแนนรวมมาเทียบกับช่วงต่อไปนี้

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

ในทางกลับกันไม่มีข้อยกเว้น แม้ตัวแปรที่ 1 จะได้ 0 คะแนน แต่ถ้าตัวแปรที่ 3 และตัวแปรที่ 4 ได้ 3 คะแนนพร้อมกัน นั่นคือสภาวะที่การปฏิบัติงานพังก่อนกำหนดเส้นตายทางเทคนิคเสียอีก การที่เส้นตายยังเหลือเวลาไม่ได้หักล้างปัญหาอื่น

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

ลองให้คะแนนโรงงานตัวอย่าง

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

ผู้ผลิตชิ้นส่วนอิเล็กทรอนิกส์สัญชาติญี่ปุ่นในจังหวัดชลบุรี พนักงาน 240 คน สร้างระบบบริหารการผลิตเมื่อ 15 ปีก่อนโดยยกกลไกของบริษัทแม่ในญี่ปุ่นมาปรับใช้ และหลังจากนั้นก็แก้ไขเพิ่มเติมเป็นส่วน ๆ เรื่อยมา แพลตฟอร์มคือ Windows Server 2016

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

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

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

ต่อให้ได้คะแนนสูง ก็ไม่ได้แปลว่าข้อสรุปคือต้องรื้อระบบใหม่ทั้งหมดทันที กลยุทธ์การปรับปรุงระบบให้ทันสมัยที่กลายเป็นกระแสหลักในปี 2026 กลับเป็นไปในทิศทางตรงกันข้าม

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

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

ในทางปฏิบัติ ทางเลือกในการรับมือจัดได้เป็น 4 แบบดังนี้

แต่ละทางเลือกมีหลุมพรางเฉพาะตัว การเลือกโดยดูเพียงว่าราคาถูกที่สุดแล้วต้องมาจ่ายแพงในภายหลัง ก็เป็นเรื่องเดียวกับการเปลี่ยนเครื่องจักร

การต่อสัญญาบำรุงรักษาไม่ใช่ทางเลือกที่ใช้เดี่ยว ๆ ได้ เพราะเป็นเพียงการซื้อเวลา ถ้ายังไม่ได้ตัดสินใจว่าจะใช้เวลาที่ซื้อมาทำอะไร ปีหน้าก็จะกลับมาตัดสินใจเรื่องเดิมซ้ำอีก

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

ระยะเวลาและค่าใช้จ่ายของการเปลี่ยนระบบตามความเป็นจริง

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

ตัวเลข 12-18 เดือนนี้ตั้งอยู่บนสมมติฐานว่าการอนุมัติเดินหน้าราบรื่น และข้อกำหนดค่อนข้างนิ่งแล้ว ถ้าเรื่องเสนออนุมัติถูกตีกลับสักครั้ง เวลาก็หายไปหลายเดือนตรงนั้น

ลองคิดจากตัวอย่าง IBM i 7.3 ที่กล่าวไปข้างต้น กำหนดคือ 30 กันยายน 2026 เมื่อแทนค่าระยะเวลาที่ต้องใช้ 12-18 เดือนลงไป จะคำนวณได้ว่า หากจะให้ทันกำหนดนี้ ต้องลงมือไปแล้ว กรณีที่เพิ่งเริ่มพิจารณาตอนนี้ เรื่องที่ต้องคุยจึงไม่ใช่ว่าทันหรือไม่ทัน แต่เป็นว่าจะประคองอย่างไรบนสมมติฐานว่าจะเลยกำหนดแน่นอน

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

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

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

ประเด็นเฉพาะของโรงงานญี่ปุ่นในประเทศไทย

ที่ผ่านมาเป็นเรื่องที่ใช้ร่วมกันได้กับโรงงานในญี่ปุ่นด้วย แต่ถ้ามีฐานอยู่ในประเทศไทย จะมีวัตถุดิบเฉพาะเพิ่มเข้ามา

ถึงกำหนดแล้วก็หาซื้อเพิ่มในประเทศไม่ได้

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

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

ข้อจำกัดเรื่องการหาวิศวกรในประเทศ

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

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

การประคองทั้งมาตรฐานสำนักงานใหญ่และความเหมาะสมกับหน้างานในไทย

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

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

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

ภาษาและการส่งต่องาน

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

อย่างน้อยที่สุด เราแนะนำให้เก็บขั้นตอนการปฏิบัติงานและขั้นตอนรับมือเหตุขัดข้องไว้เป็นภาษาไทยหรือภาษาอังกฤษด้วย นี่คือการประกันที่ราคาไม่แพงนัก เพื่อป้องกันไม่ให้แพลตฟอร์มที่อุตส่าห์ทำใหม่ กลายเป็น “ระบบที่ไม่มีใครรู้ข้างในอีกแล้ว” ในอีก 5 ปีข้างหน้า

จะเลือกผู้รับงานย้ายระบบอย่างไร

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

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

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

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

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

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

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

ควรพิจารณาเปลี่ยนระบบบริหารการผลิตเมื่อใด

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

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

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

ไม่ได้แปลว่าระบบจะหยุดทำงานทันที ในกรณีส่วนใหญ่ ระบบจะยังเดินต่อไปราวกับไม่มีอะไรเกิดขึ้น นี่เองที่ทำให้การตัดสินใจยาก

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

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

ค่าใช้จ่ายในการเปลี่ยนระบบประมาณเท่าไร

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

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

มีวิธียืดอายุระบบนอกเหนือจากการรื้อใหม่ทั้งหมดหรือไม่

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

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

สรุป

ความล้าสมัยของระบบบริหารการผลิตวัดด้วยอัตราการทำงานไม่ได้ หากสรุปประเด็นสำคัญของการตัดสินใจ จะได้ดังนี้

การที่ระบบยังทำงานอยู่กับการที่ระบบยังปลอดภัย เป็นคนละเรื่องกัน การสนับสนุนแบบขยายเวลาของ IBM i 7.3 สิ้นสุดวันที่ 30 กันยายน 2026 และวันเดียวกันนั้นก็เป็นวันสิ้นสุดการสนับสนุนมาตรฐานของ IBM i 7.4 ด้วย รุ่น IBM Power9 บางรุ่นสิ้นสุดการบำรุงรักษาฮาร์ดแวร์มาตรฐานวันที่ 31 มกราคม 2026 และการสนับสนุนแบบขยายเวลาของ Windows Server 2016 สิ้นสุดวันที่ 12 มกราคม 2027 สถานการณ์ที่บริษัทขนาดใหญ่ของญี่ปุ่น 74% ยังถือครองระบบเลกาซีอยู่นั้น แม้จะเป็นเรื่องปกติแต่ก็ไม่ปลอดภัย

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

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

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

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

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

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

• การสิ้นสุดการสนับสนุนแบบขยายเวลาของ IBM i 7.3 และการสิ้นสุดการสนับสนุนมาตรฐานของ IBM i 7.4

https://www.c3index.co.jp/blog/blog_3456/

• การสิ้นสุดการบำรุงรักษาฮาร์ดแวร์มาตรฐานของรุ่น IBM Power9

https://www.c3index.co.jp/blog/blog_3082/

• คู่มือการปรับปรุง AS/400 และ IBM i ให้ทันสมัย ปี 2026 – Aurant Technologies

https://aurant-technologies.com/blog/as400-ibm-i-modernization-guide-2026/

• การวางแผนล่วงหน้าสำหรับการสิ้นสุดการสนับสนุน Windows Server 2016 – Microsoft

https://www.microsoft.com/en-us/windows-server/blog/2026/02/25/planning-ahead-for-windows-server-2016-end-of-support/

• ความเสี่ยงเมื่อหมดระยะบำรุงรักษา ระยะเวลาที่ต้องใช้ในการเปลี่ยนระบบ และสัญญาณเชิงปฏิบัติที่บอกว่าควรเริ่มพิจารณา – Venture Net

https://www.venture-net.co.jp/netsuite/risk-of-expiry-of-maintenance/

• “หน้าผาปี 2025” ยังไม่จบลงแม้เข้าปี 2026 – ITmedia Enterprise

https://www.itmedia.co.jp/enterprise/articles/2603/30/news017.html

• การย้ายระบบหลักของโรงงานเหล็กและโรงงานผลิตทุกแห่งไปยังสภาพแวดล้อมแบบเปิดโดยสมบูรณ์ – JFE Steel

https://www.jfe-steel.co.jp/release/2026/02/260226.html