พัฒนาระบบบริหารการผลิตขึ้นใหม่ 2026 จุดตัดสินคือปริมาณงานดัดแปลง

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

เกณฑ์ตัดสินว่าจะพัฒนาระบบบริหารการผลิตขึ้นใหม่ทั้งหมดหรือไม่ ไม่ใช่รายการฟังก์ชัน

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

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

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

ทำไมคำว่าฟังก์ชันครบแล้วจึงพังในปีที่ 3

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

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

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

ผลสรุปเชิงตัวเลขของโครงสร้างแบบนี้ปรากฏอยู่ในบทสรุปของ Godlan ที่อ้างรายงาน ERP ปี 2026 ของ Panorama Consulting Group จากการวิเคราะห์การนำระบบไปใช้จริงกว่า 2,400 กรณีในช่วงเดือนกันยายน 2025 ถึงเดือนมกราคม 2026 พบว่าโครงการ ERP ในอุตสาหกรรมการผลิตแบบดิสครีต 73% ไม่บรรลุเป้าหมาย ซึ่งสูงกว่าค่าเฉลี่ยทุกอุตสาหกรรมที่ 68% ต้นทุนบานปลายเฉลี่ย 215% เทียบกับค่าเฉลี่ยทุกอุตสาหกรรม 189% ระยะเวลายืดออกไป 30% เทียบกับค่าเฉลี่ย 25% และอัตราการบรรลุเป้าหมายอยู่ที่ 27% วิธีอ่านตัวเลขชุดนี้คือ อุตสาหกรรมการผลิตมีโอกาสล้มเหลวมากกว่าอุตสาหกรรมอื่น

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

คำถามที่ต้องตัดสินใจเหลือเพียงข้อเดียว

ดังนั้น คำถามที่ควรถกกันในที่ประชุมคัดเลือกระบบจึงไม่ใช่ว่าผลิตภัณฑ์ไหนมีฟังก์ชันมากกว่ากัน

โรงงานของเราเป็นโรงงานที่กฎการทำงานเปลี่ยนไปปีละกี่คน-เดือน

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

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

ทางเลือกไม่ได้มีสองทางแต่มีสามทาง และทางที่แพงที่สุดคือทางตรงกลาง

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

ในแบบจำลองนี้ ทางตรงกลางคือทางที่แพงที่สุด

นิยามของแนวทาง A B และ C

เพื่อให้เปรียบเทียบกันได้ เรานิยามแนวทางทั้ง 3 ด้วยหน่วยคน-เดือน ทั้งหมดข้างล่างนี้ตั้งอยู่บนขนาดเดียวกันคือ โรงงานญี่ปุ่นในประเทศไทย 1 แห่ง และมีผู้ใช้ระบบบริหารการผลิต 40 คน

แนวทาง A คือสิ่งที่บทสรุปของ Godlan ข้างต้นเรียกว่าการปรับให้เข้ากับงานในระดับปานกลางโดยอยู่ภายในกรอบแนวคิดการออกแบบของผลิตภัณฑ์ แนวทาง B คือสภาพที่ออกไปนอกกรอบนั้นแล้ว ส่วนแนวทาง C คือการถือครองฐานทั้งหมดไว้เอง

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

ทำไมการดัดแปลงแพ็กเกจอย่างหนักจึงกลายเป็นการจ่ายภาษี 2 ต่อ

แนวทาง B แพงกว่าไม่ใช่เพราะค่าพัฒนาระบบสูงอย่างเดียว แต่เพราะหลังจ่ายค่าพัฒนาระบบครบแล้ว โครงสร้างยังบังคับให้จ่ายอีก 2 รายการต่อไปทุกปี

ภาษีต่อที่ 1 คือค่าไลเซนส์ ตราบใดที่ยังใช้แพ็กเกจเป็นฐาน ต่อให้ดัดแปลงมากแค่ไหน ค่าไลเซนส์ก็ไม่ลดลง ในแบบจำลองนี้คือ 40 ผู้ใช้ × 2,500 บาทต่อเดือน = 1,200,000 บาทต่อปี รวม 5 ปีเป็น 6,000,000 บาท แนวทาง A ก็จ่ายเท่ากันนี้ แต่ A ได้ใช้ฟังก์ชันมาตรฐานคุ้มกับเงินที่จ่าย ส่วน B เขียนทับฟังก์ชันมาตรฐานไปแล้วเป็นจำนวนมาก แต่ยังต้องจ่ายค่าฟังก์ชันมาตรฐานส่วนที่ถูกเขียนทับไปนั้นต่อไปด้วย

ภาษีต่อที่ 2 คืองานปรับส่วนที่ดัดแปลงให้เข้ากับเวอร์ชันใหม่ เมื่อแพ็กเกจอัปเดตเวอร์ชัน ส่วนที่ดัดแปลงไว้ต้องถูกตรวจสอบการทำงาน และส่วนใหญ่ต้องสร้างขึ้นใหม่ ยิ่งดัดแปลงไว้มาก งานนี้ก็ยิ่งใหญ่ ในแบบจำลองนี้เราตั้งไว้ว่าตลอด 5 ปีมีการอัปเดตเวอร์ชัน 1 ครั้ง และต้องสร้างขึ้นใหม่คิดเป็น 40% ของปริมาณงานดัดแปลงที่สะสมมาจนถึงเวลานั้น เนื่องจาก B มีงานดัดแปลงเริ่มต้นสูงถึง 14 คน-เดือน เฉพาะงานปรับให้เข้ากับเวอร์ชันใหม่รายการเดียว B จึงต้องแบกภาระประมาณ 2.4 เท่าของแนวทาง A เมื่อ x = 1 คือ 1,368,000 บาท เทียบกับ 576,000 บาท และประมาณ 1.5 เท่าเมื่อ x = 4 คือ 2,448,000 บาท เทียบกับ 1,656,000 บาท

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

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

แบบจำลองต้นทุนรวม 5 ปี จุดพลิกอยู่ที่ 1.4 คน-เดือนต่อปี

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

สมมติฐาน คือราคาต่อคน-เดือน จำนวนผู้ใช้ และระยะเวลา

ราคา 180,000 บาทต่อคน-เดือนเป็นตัวเลขที่มีช่วงกว้าง ราคาจริงกระจายอยู่ในช่วง 150,000 ถึง 250,000 บาทต่อคน-เดือน จากการสำรวจชุดเดียวกันของ ERI SalaryExpert นักพัฒนาซอฟต์แวร์ในกรุงเทพที่มีประสบการณ์ 1 ถึง 3 ปีได้ปีละ 834,099 บาท ส่วนผู้ที่มีประสบการณ์ 8 ปีขึ้นไปได้ปีละ 1,362,287 บาท เมื่อคิดเป็นรายเดือนจะห่างกันประมาณ 44,000 บาท ราคาจึงขยับตามว่าจะจัดใครมากี่คน

อนึ่ง ขอวางราคาตลาดต่างประเทศไว้เป็นค่าอ้างอิงด้วย บทสรุปฉบับปี 2026 ของ LI Solutions ระบุว่าค่าบำรุงรักษาของงานพัฒนาแบบว่าจ้างอยู่ที่ 15 ถึง 25% ของค่าพัฒนาระบบเริ่มต้นต่อปี โดยการสร้างระบบงานขนาดกลางและขนาดเล็กอยู่ที่ 50,000 ถึง 120,000 ดอลลาร์สหรัฐ และการสร้างระบบเต็มรูปแบบที่รวมการเชื่อมต่อ การวิเคราะห์ และงาน QA อยู่ในช่วง 100,000 ถึง 500,000 ดอลลาร์สหรัฐ ส่วนในประเทศญี่ปุ่น บทสรุปฉบับปี 2026 ของ c3index ระบุค่าพัฒนาระบบหลักขององค์กรไว้ที่ 5,000,000 ถึง 300,000,000 เยนตามขนาดงาน ตัวเลขเหล่านี้ทั้งสกุลเงินและขอบเขตงานต่างกัน จึงไม่ได้ถูกแปลงเข้ามาในตัวเลขเงินบาทของแบบจำลองนี้แม้แต่ค่าเดียว ใช้เพื่อดูภาพราคาตลาดเท่านั้น

การตั้งค่าบำรุงรักษาไว้ที่ 12% ต้องอธิบายเพิ่ม ราคาตลาดตามข้อมูลของ LI Solutions อยู่ที่ 15 ถึง 25% แต่ในแบบจำลองนี้เราแยกงานเพิ่มฟังก์ชันออกไปเป็นรายการต่างหากในรูปของ x จึงตั้งค่าบำรุงรักษาไว้ต่ำที่ 12% เมื่อรวมกันในกรณี x = 1 คน-เดือนต่อปี จะได้ 15.8% ต่อปีเมื่อเทียบกับค่าพัฒนาระบบเริ่มต้น ซึ่งอยู่ใกล้ขอบล่างของราคาตลาด ถ้า x = 4 คน-เดือนต่อปี จะได้ 27.4% ซึ่งสูงกว่าราคาตลาดเล็กน้อย ขอให้ตรวจสอบความสอดคล้องข้อนี้ด้วยเมื่อใส่ค่าของบริษัทท่านลงไป

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

สูตรต้นทุนรวม 5 ปี

ต้นทุนรวม 5 ปีของทั้ง 3 แนวทางเขียนเป็นสมการเชิงเส้นของ x ได้ดังนี้

• แนวทาง A(x) = 1,980,000 + 6,000,000 + 900,000x + 0.4 × (3 + 5x) × 180,000 = 8,196,000 + 1,260,000x
• แนวทาง B(x) = 3,960,000 + 6,000,000 + 900,000x + 0.4 × (14 + 5x) × 180,000 = 10,968,000 + 1,260,000x
• แนวทาง C(x) = 4,680,000 + 1,200,000 + 2,808,000 + 900,000x = 8,688,000 + 900,000x

รายละเอียดของแต่ละพจน์มีดังนี้

ทั้ง 3 แนวทางวัดจากเส้นฐานเดียวกัน คือการทำงานด้วย Excel ในปัจจุบัน เพื่อไม่ให้นับมูลค่าผลประโยชน์ซ้ำซ้อน เราจึงเปรียบเทียบด้วยยอดรายจ่ายรวมเท่านั้น ไม่ใช้ยอดที่ลดได้ ส่วน 900,000x ของงานดัดแปลงรายปีนั้นใช้ร่วมกันทั้ง 3 แนวทาง เพราะไม่ว่าจะเลือกแนวทางใด ตัวการเปลี่ยนแปลงของกฎการทำงานเองก็ไม่หายไป

กรณี x เท่ากับ 1 คน-เดือนต่อปี

คือโรงงานที่มีความต้องการงานดัดแปลงปีละ 1 คน-เดือน หรือเท่ากับ 20 วันทำการ

ถูกที่สุดคือแนวทาง A แต่ห่างจาก C เพียง 132,000 บาท คิดเป็นเพียง +1.4% เมื่อเทียบกับ A ในรายจ่ายเกือบ 10,000,000 บาทตลอด 5 ปี เงิน 130,000 บาทจึงถือว่าสูสีกันในทางปฏิบัติ ขยับสมมติฐานเพียงเล็กน้อยลำดับก็สลับกันได้

ในทางกลับกัน แนวทาง B อยู่ที่ 12,228,000 บาท สูงกว่า A อยู่ 2,772,000 บาท คิดเป็น +29.3% เมื่อเทียบกับ A และเมื่อเทียบกับ C ก็ยังสูงกว่า 2,640,000 บาท คิดเป็น +27.5% เมื่อเทียบกับ C ตรงนี้ยืนยันได้ว่า แม้แต่ในโรงงานที่ x น้อย การดัดแปลงอย่างหนักก็ยังแพงโดดออกมา

กรณี x เท่ากับ 4 คน-เดือนต่อปี

คือโรงงานที่มีความต้องการงานดัดแปลงปีละ 4 คน-เดือน หรือเท่ากับ 80 วันทำการ โรงงานที่รับงานสั่งทำเฉพาะรายเป็นหลัก และมีแบบฟอร์มกับหัวข้อการตรวจสอบต่างกันไปตามลูกค้าแต่ละราย จะอยู่ที่ระดับนี้

ลำดับสลับกัน ถูกที่สุดคือแนวทาง C ที่ 12,288,000 บาท แนวทาง A สูงกว่า C อยู่ 948,000 บาท คิดเป็น +7.7% เมื่อเทียบกับ C ส่วนแนวทาง B สูงกว่า C อยู่ 3,720,000 บาท คิดเป็น +30.3% เมื่อเทียบกับ C

ส่วนต่างระหว่างแนวทาง B กับ A คงที่อยู่ที่ 2,772,000 บาททั้งในกรณี x = 1 และ x = 4 เพราะทั้งสองแนวทางมีความชันของงานดัดแปลงรายปีเท่ากันที่ 1,260,000x ต่างกันเพียงปริมาณงานดัดแปลงเริ่มต้นและปริมาณงานปรับเข้ากับเวอร์ชันใหม่เท่านั้น พูดอีกอย่างคือ เงินส่วนที่บวกเพิ่มเข้าไปกับการดัดแปลงอย่างหนัก จะไม่ถูกเรียกคืนไม่ว่า x จะโตขึ้นแค่ไหน เหตุผลที่มักใช้สนับสนุนการดัดแปลงอย่างหนักคือ ถ้าสร้างเผื่อไว้ก่อน การเปลี่ยนแปลงในอนาคตจะง่ายขึ้น แต่เมื่อความชันของทั้งสองเท่ากัน ต่อให้การเปลี่ยนแปลงเพิ่มขึ้น ก็จะไม่มีจังหวะที่ B ไล่ทัน A เงิน 2,772,000 บาทก้อนนี้คือราคาของการเลือกวางระบบไว้บนฐานของแพ็กเกจนั่นเอง

สูตรหาจุดพลิก และวิธีแทนค่าของบริษัทตัวเอง

เราจะหาค่า x ที่ทำให้ต้นทุนรวม 5 ปีของแนวทาง A กับแนวทาง C เท่ากัน จุดนี้ในบทความนี้เรียกว่าจุดพลิก ซึ่งหมายถึงจุดที่ยอดรวม 5 ปีของสองแนวทางเท่ากันพอดี ไม่ได้หมายถึงจุดที่เริ่มมีกำไร

“`

8,196,000 + 1,260,000x = 8,688,000 + 900,000x

360,000x = 492,000

x ≈ 1.37

“`

จุดพลิกอยู่ที่ประมาณ 1.4 คน-เดือนต่อปี ถ้าคิด 1 คน-เดือนเท่ากับ 20 วันทำการ ก็เท่ากับประมาณ 28 คน-วันต่อปี ณ จุดนี้ต้นทุนรวม 5 ปีของทั้งสองแนวทางเท่ากันที่ประมาณ 9,918,000 บาท

ถ้าแปลโครงสร้างของสมการเป็นคำพูดจะได้แบบนี้ ตัวเลข 492,000 บาททางขวาคือความได้เปรียบด้านต้นทุนคงที่ที่แนวทาง A ถืออยู่ ด้านหนึ่ง C จ่ายค่าพัฒนาระบบเริ่มต้นมากกว่า 2,700,000 บาท แต่อีกด้านหนึ่ง ค่าดูแลรักษาตลอด 5 ปีของ C น้อยกว่าอยู่ 2,208,000 บาท เมื่อหักกลบแล้ว A จึงเริ่มต้นจากตำแหน่งที่ได้เปรียบอยู่ 492,000 บาท รายละเอียดของส่วนต่างค่าดูแลรักษาคือ ค่าไลเซนส์ 6,000,000 บาท เทียบกับโครงสร้างพื้นฐานบวกค่าบำรุงรักษาของ C ที่ 4,008,000 บาท ต่างกันปีละ 398,400 บาท และ 5 ปีเป็น 1,992,000 บาท เมื่อบวกงานปรับเข้ากับเวอร์ชันใหม่ของ A อีก 216,000 บาท จะได้ 2,208,000 บาท

ส่วน 360,000x ทางซ้ายคือจำนวนเงินที่ A ต้องจ่ายมากกว่า C ทุกครั้งที่ x เพิ่มขึ้น 1 คน-เดือน ตัวงานดัดแปลงรายปีเองนั้นใช้ร่วมกันทั้ง 3 แนวทาง แต่เฉพาะ A ที่ต้องสร้าง 40% ของงานดัดแปลงนั้นขึ้นใหม่ในอีก 5 ปีข้างหน้า จึงถูกบวกเพิ่ม 0.4 × 5 × 180,000 = 360,000 บาทต่อ 1 คน-เดือน จุดที่ส่วนบวกเพิ่มนี้กินความได้เปรียบ 492,000 บาทจนหมด คือจุดพลิก

ขั้นตอนการแทนค่าของบริษัทตัวเองมี 3 ข้อ

1. เปลี่ยนราคาต่อคน-เดือนเป็นราคาจริงของบริษัทท่าน ถ้าจะเปลี่ยนจาก 180,000 บาทเป็น 150,000 บาท ให้คูณทุกพจน์ที่แปรผันตามคน-เดือนด้วย 0.833 จุดที่มักตกหล่นคือ ค่าบำรุงรักษาของแนวทาง C เพราะเราตั้งค่าบำรุงรักษาไว้ที่ 12% ของค่าพัฒนาระบบเริ่มต้นต่อปี เมื่อราคาต่อคน-เดือนลดลง ค่าพัฒนาระบบเริ่มต้นก็ลดลง และค่าบำรุงรักษาก็ลดลงตามไปด้วย ดังนั้นสิ่งที่ต้องคูณ 0.833 มี 4 รายการ คือค่าพัฒนาระบบเริ่มต้น งานดัดแปลงรายปี งานปรับเข้ากับเวอร์ชันใหม่ และ ค่าบำรุงรักษาของ C ส่วนที่ไม่ขยับมีเพียง 2 รายการคือค่าไลเซนส์กับค่าโครงสร้างพื้นฐาน ถ้าปล่อยค่าบำรุงรักษาของ C ไว้ที่ 561,600 บาทต่อปีเหมือนเดิม ต้นทุนรวม 5 ปีของ C จะถูกประเมินสูงเกินจริงไป 468,000 บาท และทำให้ตำแหน่งของจุดพลิกผิดพลาด
2. เปลี่ยนจำนวนผู้ใช้ ถ้าเปลี่ยนจาก 40 คนเป็น 80 คน ค่าไลเซนส์จะกลายเป็น 2,400,000 บาทต่อปี และความได้เปรียบด้านต้นทุนคงที่ของ A จะหายไป ในแพ็กเกจที่คิดค่าบริการตามจำนวนผู้ใช้ จำนวนคนจะกดจุดพลิกให้ต่ำลงโดยตรง
3. วัดค่า x ของบริษัทท่านแล้วแทนลงไป วิธีวัดอยู่ในหัวข้อถัดไป

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

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

5 ขั้นตอนวัดปริมาณงานดัดแปลง x ของโรงงานตัวเอง ซึ่งคือวิธีเลือกระบบบริหารการผลิตในทางปฏิบัติ

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

ขั้นตอนที่ 1 รวบรวมประวัติการเปลี่ยนแปลงย้อนหลัง 24 เดือน

แหล่งที่ต้องเก็บมี 4 แห่ง

• ใบร้องขอที่ส่งถึงฝ่าย IT หรือฝ่ายวิศวกรรมการผลิต ตั๋วงานภายใน และโฟลเดอร์อีเมลที่ใช้ร้องขอ
• อีเมลถึงผู้พัฒนา ใบเสนอราคา และประวัติการสั่งงานพัฒนาเพิ่มเติม
• ประวัติการแก้ไขไฟล์ Excel ได้แก่วันที่ในชื่อไฟล์ ประวัติการเพิ่มชีต และชีตบันทึกการแก้ไข
• วันเวลาที่อัปเดตมาโครและ Access รวมถึงช่องคอมเมนต์ในโมดูล VBA

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

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

ขั้นตอนที่ 2 แยกการเปลี่ยนกฎการทำงานออกจากการแก้ปัญหาวิธีใช้งาน

นำรายการที่รวบรวมมาแบ่งเป็น 2 กลุ่ม สิ่งที่นับเข้าไปใน x คือกลุ่มแรกเท่านั้น

สิ่งที่กฎการทำงานเปลี่ยน ซึ่งนับเข้า x

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

สิ่งที่เป็นเพียงการแก้ไขวิธีใช้งาน ซึ่งไม่นับเข้า x

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

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

ขั้นตอนที่ 3 ปัดขนาดงานเป็น 3 ระดับแล้วแปลงเป็นค่ารายปี

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

เมื่อรวมยอดได้แล้ว ให้หารด้วย 24 แล้วคูณด้วย 12 ผลลัพธ์คือค่าคน-เดือนต่อปี

ขอยกตัวอย่าง 2 กรณี

โรงงาน ก คือ ผลิตสินค้าจำนวนมากด้วยรายการที่คงที่ และมีลูกค้าน้อยราย ใน 24 เดือนมีรายการที่เข้าข่ายการเปลี่ยนกฎการทำงาน 7 รายการ แบ่งเป็นเล็ก 0.2 คน-เดือน × 5 รายการ = 1.0 และกลาง 0.5 คน-เดือน × 2 รายการ = 1.0 รวม 2.0 คน-เดือน แปลงเป็นค่ารายปีได้ 2.0 ÷ 24 × 12 = 1.0 คน-เดือนต่อปี

โรงงาน ข คือ รับงานสั่งทำเฉพาะราย และมีแบบฟอร์มกับหัวข้อการตรวจสอบต่างกันไปตามลูกค้าแต่ละราย ใน 24 เดือนมีรายการที่เข้าข่าย 19 รายการ แบ่งเป็นเล็ก 0.2 คน-เดือน × 10 รายการ = 2.0 กลาง 0.5 คน-เดือน × 6 รายการ = 3.0 และใหญ่ 1.0 คน-เดือน × 3 รายการ = 3.0 รวม 8.0 คน-เดือน แปลงเป็นค่ารายปีได้ 8.0 ÷ 24 × 12 = 4.0 คน-เดือนต่อปี

สองกรณีนี้ตรงกับ x = 1 และ x = 4 ในแบบจำลองข้างต้นพอดี โรงงาน ก ถูกที่สุดเมื่อใช้แพ็กเกจตามมาตรฐานซึ่งคือแนวทาง A ส่วนโรงงาน ข ถูกที่สุดเมื่อพัฒนาขึ้นใหม่ทั้งหมดซึ่งคือแนวทาง C ทั้งที่เป็นโรงงานญี่ปุ่น 40 ผู้ใช้เหมือนกัน แต่คำตอบกลับกลายเป็นตรงข้ามกัน

ขั้นตอนที่ 4 บวกการเปลี่ยนแปลงที่แน่นอนแล้วในอีก 2 ปีข้างหน้า

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

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

ให้ประเมินสิ่งเหล่านี้ด้วย 3 ระดับเดียวกัน แล้วนำยอดของ 2 ปีมาหารด้วย 24 คูณด้วย 12 และบวกเข้ากับค่าที่ได้จากขั้นตอนที่ 3 ถ้าใช้แต่ผลจริงในอดีต โรงงานที่ธุรกิจกำลังเติบโตอยู่ในขณะนี้จะประเมินค่า x ต่ำเกินไป

ในอุตสาหกรรมการผลิตของไทย ส่วนของอนาคตนี้มีผลมาก จากการเรียบเรียงของ JETRO คำขอส่งเสริมการลงทุนต่อ BOI ของไทยในปี 2025 ทำสถิติสูงสุดเป็นประวัติการณ์ที่ประมาณ 1.8 ล้านล้านบาท และตามที่ Bangkok Shuho รายงาน ในเดือนมิถุนายน 2026 ได้มีการเปิดตัวอย่างเป็นทางการของกลไกลดระยะเวลาการอนุมัติสำหรับภาคการผลิตขั้นสูงที่ชื่อ Thailand Fast Pass โดยโครงการที่เข้าข่ายมีมูลค่ารวมกว่า 700,000 ล้านบาท การที่การลงทุนรอบตัวขยับ ก็หมายความว่าโครงสร้างคำสั่งซื้อและรายการสินค้าที่ผลิตของบริษัทท่านจะขยับไปด้วย

ขั้นตอนที่ 5 นำค่า x ที่ได้ไปแทนในสูตร

แทนค่าลงใน แนวทาง A(x) = 8,196,000 + 1,260,000x และ แนวทาง C(x) = 8,688,000 + 900,000x แล้วเปรียบเทียบกัน ถ้า x ต่ำกว่า 1.4 อย่างชัดเจน ให้ใช้แพ็กเกจตามมาตรฐาน ถ้าสูงกว่าอย่างชัดเจน ให้พัฒนาขึ้นใหม่ทั้งหมด แต่ถ้าตกอยู่ระหว่าง 1.0 ถึง 1.8 แบบจำลองนี้เพียงอย่างเดียวยังตัดสินไม่ได้ เพราะยอดรวมสูสีกัน จึงต้องตัดสินด้วยเงื่อนไขอื่นที่ไม่ใช่จำนวนเงิน

ลักษณะของโรงงานที่ค่า x มักจะสูง

ลองประเมินตัวเองจากจำนวนข้อที่ตรงกัน ถ้าตรงตั้งแต่ 3 ข้อขึ้นไป ค่า x ของท่านอยู่ฝั่งสูงตั้งแต่ก่อนวัดแล้ว

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

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

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

4 เงื่อนไขที่แพ็กเกจยังเป็นคำตอบที่ถูกต้อง และ 4 เงื่อนไขที่การพัฒนาขึ้นใหม่ทั้งหมดคือคำตอบ

มีบางกรณีที่ตัดสินด้วย x เพียงอย่างเดียวไม่ได้ เราจึงขอเรียบเรียงเงื่อนไขที่ไม่ใช่จำนวนเงินไว้ด้วย

4 เงื่อนไขที่แพ็กเกจซึ่งคือแนวทาง A เป็นคำตอบที่ถูกต้อง

1. มีแนวโน้มว่า x จะต่ำกว่า 1 คน-เดือนต่อปี ขอให้ยืนยันว่าต่ำกว่าทั้งในผลจริงย้อนหลัง 24 เดือน และในส่วนที่ยืนยันแล้วของ 2 ปีข้างหน้า อย่างใดอย่างหนึ่งเพียงด้านเดียวยังไม่พอ
2. สำนักงานใหญ่ถือมาตรฐานการทำงานไว้ และพื้นที่ไม่มีอำนาจเปลี่ยนกฎการทำงาน กรณีนี้ ความต้องการที่เกิดในพื้นที่ส่วนใหญ่จะจบลงที่การสอบถามสำนักงานใหญ่แล้วถูกปฏิเสธ จึงไม่สะสมเข้าไปใน x
3. กำหนดเวลาเปิดใช้งานสั้น หากมีกำหนดเวลาเช่นต้องทันการเปิดเดินเครื่องโรงงาน หรือต้องมีกลไกการบันทึกให้ทันก่อนการตรวจประเมิน ส่วนต่างระหว่างงานเริ่มต้น 11 คน-เดือนกับ 26 คน-เดือนจะเป็นข้อจำกัดที่หนักกว่าตัวเงิน
4. ภายในองค์กรไม่มีโครงสร้างที่จะรักษาเอกสารข้อกำหนดและซอร์สโค้ดไว้ได้ต่อเนื่อง การพัฒนาขึ้นใหม่ทั้งหมดคือแนวทางที่บริษัทตัวเองถือต้นฉบับของข้อกำหนดไว้ ถ้าถือไว้ไม่ได้ ก็ต้องไม่เลือกแนวทางนี้

4 เงื่อนไขที่การพัฒนาขึ้นใหม่ทั้งหมดซึ่งคือแนวทาง C เป็นคำตอบที่ถูกต้อง

1. x สูงเกิน 1.8 คน-เดือนต่อปี เป็นระดับที่เผื่อระยะห่างจากจุดพลิกที่ 1.4 ไว้แล้ว เมื่อคำนึงถึงความคลาดเคลื่อนของการวัด การสูงกว่า 1.4 เพียงเล็กน้อยยังใช้เป็นข้อมูลตัดสินใจไม่ได้
2. ตัวกฎการทำงานเองคือความสามารถในการแข่งขัน หากวิธีบริหารกระบวนการพิเศษ วิธีคำนวณต้นทุนเฉพาะตัว หรือข้อตกลงกับลูกค้าเป็นปัจจัยสร้างความแตกต่าง การทิ้งสิ่งเหล่านั้นไปเพื่อให้เข้ากับมาตรฐานของแพ็กเกจย่อมเป็นความสูญเสียทางธุรกิจ
3. ตั้งใจใช้งานเกิน 5 ปี และมีแผนขยายสาขาหรือเพิ่มรายการสินค้าอยู่ในแผนแล้ว ยิ่งระยะเวลาเปรียบเทียบยืดออกเป็น 7 ปีหรือ 10 ปี การสะสมของค่าไลเซนส์ก็ยิ่งเป็นผลดีต่อ C
4. มีเจตจำนงและโครงสร้างที่จะถือต้นฉบับของข้อกำหนดไว้เองอย่างต่อเนื่อง เงื่อนไขคือต้องบริหารเอกสารข้อกำหนด นิยามตาราง และประวัติการเปลี่ยนแปลง ในฐานะสินทรัพย์ของบริษัท และรักษาสภาพที่ส่งต่อกันได้แม้ผู้รับผิดชอบจะเปลี่ยนคน

เงื่อนไขข้อที่ 4 เป็นข้อที่มีราคาต้องจ่ายสูงที่สุดหากทำไม่ได้ กระทรวงเศรษฐกิจ การค้าและอุตสาหกรรมของญี่ปุ่นได้เผยแพร่รายงานสรุปของคณะกรรมการปรับปรุงระบบเลกาซีให้ทันสมัยเมื่อวันที่ 28 พฤษภาคม 2025 ซึ่งสรุปสถานะการรับมือต่อข้อชี้ของรายงาน DX ปี 2018 ที่เรียกว่าหน้าผาปี 2025 นั่นคือหากปล่อยทิ้งไว้ จะเกิดความสูญเสียทางเศรษฐกิจสูงสุดถึงปีละ 12 ล้านล้านเยนตลอด 5 ปีนับจากปี 2025 คำว่าเลกาซีในที่นี้ไม่ได้หมายถึงการที่ระบบถูกเขียนด้วยเทคโนโลยีเก่าในตัวมันเอง แต่หมายถึง สภาพที่คนซึ่งอธิบายเนื้อในได้และเอกสารประกอบได้สูญหายไปแล้ว ในความหมายนี้ ทั้งระบบที่พัฒนาขึ้นใหม่ทั้งหมดแต่ไม่มีเอกสารข้อกำหนด และระบบที่ดัดแปลงอย่างหนักแต่ไม่ได้บันทึกร่องรอยการดัดแปลง ก็ลงเอยที่จุดเดียวกัน การเลือกแนวทาง C จึงเท่ากับการสัญญาว่าจะรักษาโครงสร้างที่ทำให้มีคนในบริษัทอธิบายเนื้อในนั้นได้ในอีก 5 ปีข้างหน้า

แล้วแนวทาง B ซึ่งคือการดัดแปลงแพ็กเกจอย่างหนักล่ะ ภายในแบบจำลองนี้ B ไม่ได้เป็นตัวเลือกที่ถูกที่สุดที่ค่า x ใดเลย แพงกว่า A อยู่ 2,772,000 บาทเสมอ และส่วนต่างกับ C อยู่ที่ 2,640,000 บาทเมื่อ x = 1 และ 3,720,000 บาทเมื่อ x = 4 คือยิ่ง x เพิ่มก็ยิ่งถ่างออก ถ้าจะยังมีเหตุผลให้เลือก B เหตุผลนั้นก็เป็นเงื่อนไขที่อยู่นอกแบบจำลอง เช่นกรณีที่สำนักงานใหญ่กำหนดให้ต้องเป็นผลิตภัณฑ์แพ็กเกจตามข้อกำหนดด้านบัญชีของกลุ่มบริษัท หรือกรณีที่จำเป็นต้องมีการรับประกันผลิตภัณฑ์จากผู้จำหน่ายเพื่อรองรับการตรวจสอบ ในกรณีเช่นนั้น ขอให้ระบุไว้ในเอกสารขออนุมัติอย่างชัดเจนว่าเลือกทั้งที่รู้แล้วว่าเสียเปรียบด้านจำนวนเงิน เพื่อให้อธิบายได้เมื่อภายหลังมีคนถามว่าทำไมถึงแพงขนาดนี้

ข้อความที่ว่าใช้ AI สร้างแล้วถูกลง จริงหรือไม่

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

จากการสำรวจของ DX ที่ getdx.com ซึ่งวิเคราะห์บริษัทกว่า 400 แห่งตลอด 14 เดือน ค่ามัธยฐานของการปรับปรุงปริมาณงาน PR ที่ไหลผ่านจากการนำผู้ช่วยเขียนโค้ด AI มาใช้ อยู่ที่ 7.76% บริษัทส่วนใหญ่อยู่ในช่วง 5 ถึง 15% และที่เปอร์เซ็นไทล์ที่ 90 อยู่ที่ 43.9% อีกทั้งการเขียนโค้ดกินเวลาเพียง ประมาณ 14% ของวันทำงานของนักพัฒนาเท่านั้น ส่วนค่าเครื่องมือระบุไว้ที่ 200 ถึง 600 ดอลลาร์สหรัฐต่อ 1 คน-เดือน ซึ่งรวมค่าที่นั่งและค่าโทเคน

ค่ามัธยฐานคือ 7.76% ไม่ใช่หลายเท่าตัว ส่วนต่างนี้ชี้ขาด ถ้าผลิตภาพเพิ่มขึ้นหลายเท่าจริง 26 คน-เดือนของแนวทาง C จะเหลือราว 8 คน-เดือน และโครงสร้างของการเปรียบเทียบทั้งหมดจะเปลี่ยนไป แต่ถ้าเป็น 7.76% 26 คน-เดือนก็เพียงลดลงเหลือประมาณ 24 คน-เดือนเท่านั้น คำนวณได้จาก 26 × 7.76% = ประมาณ 2.0 คน-เดือน ยิ่งกว่านั้น การคำนวณนี้ยังเป็นการประเมินที่ผ่อนปรนพอสมควร เพราะสมมติว่าอัตราเดียวกันนี้มีผลกับงานวิเคราะห์ความต้องการ งานทดสอบ งานย้ายข้อมูล และงานขึ้นใช้งาน ซึ่งไม่ใช่งานเขียนโค้ดด้วย ถ้าการเขียนโค้ดกินเวลาเพียง 14% ของวันทำงาน ผลที่กระเพื่อมไปถึงจริงก็จะเล็กกว่านี้

เหตุผลที่แบบจำลองนี้ไม่ได้รวมผลของ AI

แบบจำลองในบทความนี้ตั้งผลของ AI ไว้ที่ศูนย์ เหตุผลมี 2 ข้อ

ข้อแรกคือ ถ้าลดให้เพียงฝั่งเดียว ข้อสรุปจะพัง ลองดูความอ่อนไหวกัน สมมติว่างานเริ่มต้น 26 คน-เดือนของแนวทาง C ลดลง 2 คน-เดือน ค่าพัฒนาระบบเริ่มต้นจะลดลง 360,000 บาท และค่าบำรุงรักษาซึ่งคิดเป็น 12% ของค่านั้นตลอด 5 ปีก็จะลดลงอีก 216,000 บาท รวมลดลง 576,000 บาท ในเมื่อความได้เปรียบด้านต้นทุนคงที่ของแนวทาง A มีอยู่เพียง 492,000 บาท เพียงเท่านี้จุดพลิกก็หายไปในทางทฤษฎีแล้ว แต่ผลของ AI ชุดเดียวกันนี้ก็มีต่อ 11 คน-เดือนของแนวทาง A และ 22 คน-เดือนของแนวทาง B ด้วยเช่นกัน แบบจำลองที่ใส่ส่วนลดให้เฉพาะ C จึงเป็นการคำนวณที่ตั้งข้อสรุปไว้ก่อนแล้ว

ข้อที่สองคือ แม้พอบอกทิศทางได้ แต่ยังกำหนดช่วงตัวเลขไม่ได้ สิ่งที่พูดได้ในเชิงทิศทางคือ AI มีผลต่อคน-เดือน แต่ไม่มีผลต่อค่าไลเซนส์ แนวทาง A และ B แบกค่าไลเซนส์ 6,000,000 บาทตลอด 5 ปี และยอดนี้ไม่ลดลงแม้แต่บาทเดียวไม่ว่าประสิทธิภาพการพัฒนาจะสูงขึ้นเพียงใด แนวทาง C ซึ่งยอดรวมส่วนใหญ่เป็นคน-เดือน โดยในกรณี x = 0 ที่ยอดรวม 8,688,000 บาทนั้น ส่วนที่ไม่ผูกกับคน-เดือนคือค่าโครงสร้างพื้นฐาน 1,200,000 บาท หรือ 13.8% เท่านั้น จึงเป็นฝ่ายที่ได้รับประโยชน์จากการเพิ่มประสิทธิภาพมากกว่า ดังนั้นถ้ารวมผลของ AI เข้าไป จุดพลิกจะขยับไปในทิศทางที่ต่ำลง นั่นคือขยับไปในทิศทางที่การพัฒนาขึ้นใหม่ทั้งหมดได้เปรียบ พูดกลับกันคือ จุดพลิกที่ 1.4 คน-เดือนต่อปีที่บทความนี้แสดงไว้ เป็น ตัวเลขที่ออกมาในทางเข้มงวดต่อฝั่งการพัฒนาขึ้นใหม่ทั้งหมด

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

เส้นแบ่งที่เป็นจริงของการทำระบบบริหารการผลิตใช้เองภายในองค์กร

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

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

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

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

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

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

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

สมมติฐาน คือ ฝั่งผู้พัฒนามีคนทำงานพร้อมกันเฉลี่ย 2.5 คน และอัตราการทำงานจริงอยู่ที่ 80% โดยรวมช่วงรอการยืนยันจากฝั่งผู้ใช้และช่วงชะงักจากเหตุผลของหน้างานไว้แล้ว คำนวณด้วยสูตร จำนวนเดือนตามปฏิทิน = คน-เดือน ÷ 2.5 ÷ 0.8

จุดที่ควรอ่านคือ ส่วนต่างระหว่าง B กับ C มีเพียง 2.0 เดือน แนวทาง B ย่นระยะเวลาได้แค่ถึงจุดที่ห่างจากการพัฒนาขึ้นใหม่ทั้งหมด 2 เดือนเท่านั้น ทั้งที่เมื่อ x = 4 ต้นทุนรวม 5 ปีสูงกว่า C ถึง 3,720,000 บาท เท่ากับ จ่ายเดือนละ 1,860,000 บาทเพื่อให้ขึ้นใช้งานเร็วขึ้น 2 เดือน และแม้ในกรณี x = 1 เมื่อเอาส่วนต่าง 2,640,000 บาทหารด้วย 2 เดือน ก็ได้เดือนละ 1,320,000 บาท เหตุผลที่ว่าดัดแปลงอย่างหนักเพราะอยากขึ้นใช้งานเร็ว ขอให้ตรวจสอบว่าคุ้มกับจำนวนเงินนี้หรือไม่

เหตุผลที่แท้จริงที่ทำให้ระยะเวลายืดออกไป

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

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

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

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

ในรายงาน ERP ปี 2026 ของ Panorama Consulting Group ที่ Godlan อ้างถึง ระบุว่าโครงการ ERP ในอุตสาหกรรมการผลิตมีระยะเวลายืดออกไปเฉลี่ย 30% เทียบกับค่าเฉลี่ยทุกอุตสาหกรรมที่ 25% การแจ้งภายในองค์กรด้วยตัวเลขที่บวกเพิ่มจากจำนวนเดือนในตารางข้างบนอีก 30% จึงสมจริงกว่า

ประเด็นเพิ่มเติมเมื่อว่าจ้างพัฒนาในประเทศไทย

มีบางส่วนที่เกณฑ์การตัดสินใจของประเทศญี่ปุ่นนำมาใช้ตรง ๆ ไม่ได้ หากจะว่าจ้างงานพัฒนาระบบกับบริษัทพัฒนาซอฟต์แวร์ในประเทศไทย จะมีประเด็นเพิ่มขึ้นอีก 5 ข้อ

ภาษาและเอกสารข้อกำหนด

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

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

โครงสร้างทีมพัฒนาและการเปลี่ยนงานของบุคลากร

ตามข้อมูลของ ERI SalaryExpert รายได้ต่อปีของนักพัฒนาซอฟต์แวร์ในกรุงเทพเฉลี่ยอยู่ที่ 1,185,019 บาท ผู้มีประสบการณ์ 1 ถึง 3 ปีอยู่ที่ 834,099 บาท และผู้มีประสบการณ์ 8 ปีขึ้นไปอยู่ที่ 1,362,287 บาท แม้จะเป็นระดับที่ต่ำกว่าเมื่อเทียบกับญี่ปุ่น แต่ในแง่ของการรักษาคนที่มีประสบการณ์ไว้ ยังมีอีกปัญหาหนึ่ง คือความถี่ในการเปลี่ยนงานสูงกว่าญี่ปุ่น ทำให้เกิดการเปลี่ยนตัวผู้รับผิดชอบระหว่างช่วงโครงการได้ง่าย

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

BOI และสภาพแวดล้อมการลงทุน

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

สภาพแวดล้อมการลงทุนเองก็กำลังเคลื่อนไหว ตามที่ JETRO รายงาน คำขอส่งเสริมการลงทุนต่อ BOI ในปี 2025 ทำสถิติสูงสุดเป็นประวัติการณ์ที่ประมาณ 1.8 ล้านล้านบาท และตามข้อมูลของ Bangkok Shuho ในเดือนมิถุนายน 2026 ได้มีการเปิดตัวกลไกลดระยะเวลาการอนุมัติสำหรับภาคการผลิตขั้นสูงที่ชื่อ Thailand Fast Pass โดยโครงการที่เข้าข่ายมีมูลค่ารวมกว่า 700,000 ล้านบาท การที่การลงทุนรอบตัวเร่งตัวขึ้น หมายความว่ารายการสินค้าที่ผลิตและโครงสร้างสาขาของบริษัทท่านเองก็มีโอกาสสูงที่จะเคลื่อนไหวภายใน 5 ปีนี้ ซึ่งเป็นแรงที่ผลักค่า x ให้สูงขึ้น

การส่งมอบเมื่อยุติสัญญาหรือเปลี่ยนผู้พัฒนา

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

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

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

หลุมพรางของการเปรียบเทียบกับราคาตลาดในญี่ปุ่น

เวลาขออนุมัติจากสำนักงานใหญ่ บางครั้งจะถูกนำไปเทียบกับราคาตลาดของญี่ปุ่น ในบทสรุปฉบับปี 2026 ของ c3index ค่าพัฒนาระบบหลักขององค์กรในประเทศญี่ปุ่นมีช่วงกว้างตั้งแต่ 5,000,000 ถึง 300,000,000 เยนตามขนาดงาน การจะเทียบกับจุดใดในช่วงนี้ ทำให้เรื่องเปลี่ยนไปได้ไม่รู้จบ

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

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

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

ตัดสินด้วยความต้องการงานดัดแปลงต่อปีหลังระบบขึ้นใช้งาน ซึ่งก็คือค่า x ในแบบจำลองของบทความนี้ คือโรงงานญี่ปุ่นในไทย 40 ผู้ใช้ ระยะเวลา 5 ปี และราคา 180,000 บาทต่อคน-เดือน หาก x = 1 คน-เดือนต่อปี การใช้แพ็กเกจตามมาตรฐานถูกที่สุดที่ 9,456,000 บาท ส่วนการพัฒนาขึ้นใหม่ทั้งหมดอยู่ที่ 9,588,000 บาท สูงกว่า 132,000 บาท ต่างกันเพียง 1.4% หาก x = 4 คน-เดือนต่อปี การพัฒนาขึ้นใหม่ทั้งหมดจะถูกที่สุดที่ 12,288,000 บาท และการใช้แพ็กเกจตามมาตรฐานจะสูงกว่า 948,000 บาท คิดเป็น +7.7% เมื่อเทียบกับการพัฒนาขึ้นใหม่ทั้งหมด จุดพลิกอยู่ที่ประมาณ 1.4 คน-เดือนต่อปี หรือประมาณ 28 คน-วันต่อปี เนื่องจากจุดพลิกนี้ขึ้นกับราคาต่อคน-เดือนและจำนวนผู้ใช้ ขอให้คำนวณใหม่ด้วยค่าของบริษัทท่านเอง

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

ภายใต้สมมติฐานของแบบจำลองเดียวกัน คือทำงานพร้อมกัน 2.5 คนและอัตราการทำงานจริง 80% การใช้แพ็กเกจตามมาตรฐานใช้เวลาประมาณ 5.5 เดือน การดัดแปลงแพ็กเกจอย่างหนักประมาณ 11.0 เดือน และการพัฒนาขึ้นใหม่ทั้งหมดประมาณ 13.0 เดือน อย่างไรก็ตาม ในรายงาน ERP ปี 2026 ของ Panorama Consulting Group ที่ Godlan อ้างถึง ระบุว่าโครงการ ERP ในอุตสาหกรรมการผลิตมีระยะเวลายืดออกไปเฉลี่ย 30% เทียบกับค่าเฉลี่ยทุกอุตสาหกรรมที่ 25% ระยะเวลาที่แจ้งภายในองค์กรจึงควรเผื่อไว้อีก 30% สาเหตุหลักที่ทำให้ระยะเวลายืดออกไปไม่ใช่ความเร็วในการทำงานของผู้พัฒนา แต่คือ 3 ข้อ ได้แก่เรื่องค้างคาของฝั่งธุรกิจ การที่กระบวนการทำงานปัจจุบันไม่ได้ถูกจัดทำเป็นเอกสาร และการย้ายข้อมูล

การปรับแต่งแพ็กเกจ ทำได้มากแค่ไหนจึงจะยังอยู่ในเกณฑ์ที่ยอมรับได้

ในด้านจำนวนเงิน คือขอบเขตที่งานดัดแปลงเริ่มต้นยังอยู่ภายใน 3 คน-เดือน ซึ่งก็คือแนวทาง A ของบทความนี้ ถ้าเกินเลยไปจนถึง 14 คน-เดือนซึ่งคือแนวทาง B ต้นทุนรวม 5 ปีจะสูงกว่าการใช้แพ็กเกจตามมาตรฐาน 2,772,000 บาท และสูงกว่าการพัฒนาขึ้นใหม่ทั้งหมด 2,640,000 บาทเมื่อ x = 1 และ 3,720,000 บาทเมื่อ x = 4 ในด้านแนวคิด บทสรุปของ Panorama Consulting Group ที่ Godlan อ้างถึงใช้อ้างอิงได้ คือการปรับให้เข้ากับงานในระดับปานกลางโดยอยู่ภายในกรอบแนวคิดการออกแบบของผลิตภัณฑ์ ให้ผลลัพธ์ดีกว่าการดัดแปลงอย่างหนัก โดยมีบริษัท 45% ที่ได้ผลลัพธ์ดีที่สุดจากวิธีนี้ เมื่อใดที่จำเป็นต้องดัดแปลงจนออกไปนอกกรอบแนวคิดการออกแบบของผลิตภัณฑ์ เมื่อนั้นคือสัญญาณให้กลับมาพิจารณาใหม่ว่าจะเลือกแพ็กเกจตัวอื่น หรือจะถือครองฐานทั้งหมดไว้เอง

ทำระบบบริหารการผลิตใช้เองภายในองค์กรได้หรือไม่

ทำได้ถ้าจำกัดขอบเขต การบันทึกรายงานประจำวัน การแสดงความคืบหน้าแบบง่าย การดึงข้อมูลจากระบบเดิมมาทำรายงาน และแดชบอร์ดสำหรับติดแสดงที่หน้างาน เหมาะกับการทำเอง ในทางกลับกัน ต้นฉบับของข้อมูลสินค้าคงคลัง การคำนวณต้นทุน บันทึกการสอบกลับสำหรับลูกค้า และการเชื่อมต่อกับระบบหลัก ไม่เหมาะ เกณฑ์การตัดสินคือเมื่อโปรแกรมนั้นหยุดทำงาน การจัดส่งของวันรุ่งขึ้นจะหยุดหรือไม่ ถ้าหยุด ก็อยู่นอกขอบเขตของการทำเอง สำหรับการทำเองโดยตั้งอยู่บนผู้ช่วยเขียนโค้ด AI ก็เช่นกัน ในการสำรวจของ DX ที่ครอบคลุมบริษัทกว่า 400 แห่งตลอด 14 เดือน ค่ามัธยฐานของการปรับปรุงปริมาณงาน PR ที่ไหลผ่านอยู่ที่ 7.76% และบริษัทส่วนใหญ่อยู่ในช่วง 5 ถึง 15% ความเร็วในการสร้างเพิ่มขึ้นบ้าง แต่ปัญหาที่ว่าใครจะแก้ไขหลังจากคนสร้างลาออกไปนั้นไม่ได้เปลี่ยนไป

หากว่าจ้างบริษัทพัฒนาซอฟต์แวร์ในประเทศไทย ควรเขียนอะไรไว้ในสัญญา

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

ตอนนี้ยังหมุนงานด้วย Excel อยู่ ควรเริ่มทำอะไรก่อน

ไม่ใช่การขอเอกสารแนะนำผลิตภัณฑ์ แต่คือการนับประวัติการเปลี่ยนแปลงย้อนหลัง 24 เดือน ให้รวบรวมใบร้องขอ อีเมลถึงผู้พัฒนา ประวัติการแก้ไขไฟล์ Excel และวันที่อัปเดตมาโคร แล้วแยกออกเป็นสิ่งที่กฎการทำงานเปลี่ยนกับสิ่งที่เป็นเพียงการแก้ไขวิธีใช้งาน จากนั้นนำกลุ่มแรกมาปัดเป็น 3 ระดับคือ 0.2 หรือ 0.5 หรือ 1.0 คน-เดือน รวมยอด หารด้วย 24 แล้วคูณด้วย 12 ผลลัพธ์คือค่า x ของบริษัทท่าน เมื่อบวกการเปลี่ยนแปลงที่แน่นอนแล้วในอีก 2 ปีข้างหน้า และแทนลงในสูตรของบทความนี้ ก็จะได้คำตอบเป็นตัวเงินว่าแพ็กเกจหรือการพัฒนาขึ้นใหม่ทั้งหมดถูกกว่าสำหรับบริษัทท่าน งานนี้ใช้เวลาประมาณ 2 คน 3 วัน หรือถ้าเอกสารกระจัดกระจายก็จบภายใน 1 สัปดาห์ เป็นงานที่คุ้มค่าที่จะทำก่อนการเปรียบเทียบผลิตภัณฑ์

สรุป

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

ทางเลือกไม่ได้มีสองทางแต่มีสามทาง และทางที่แพงที่สุดคือทางตรงกลาง แนวทาง B ซึ่งดัดแปลงแพ็กเกจอย่างหนัก จะกลายเป็นการจ่ายภาษี 2 ต่อทุกปี คือค่าไลเซนส์กับงานปรับส่วนที่ดัดแปลงให้เข้ากับเวอร์ชันใหม่ ต้นทุนรวม 5 ปีจึงสูงกว่าการใช้แพ็กเกจตามมาตรฐาน 2,772,000 บาทเสมอ และสูงกว่าการพัฒนาขึ้นใหม่ทั้งหมด 2,640,000 บาทเมื่อ x = 1 และ 3,720,000 บาทเมื่อ x = 4 เนื่องจากทั้งสองแนวทางมีความชันเท่ากัน ส่วนที่บวกเพิ่มนี้จะไม่ถูกเรียกคืนไม่ว่า x จะโตขึ้นแค่ไหน

ข้อสรุปด้านจำนวนเงินตกลงมาเป็นสมการเดียว คือ แนวทาง A(x) = 8,196,000 + 1,260,000x และ แนวทาง C(x) = 8,688,000 + 900,000x ทั้งสองเท่ากันที่ x ≈ 1.37 หรือ ประมาณ 1.4 คน-เดือนต่อปี ซึ่งเท่ากับประมาณ 28 คน-วันต่อปี และ ณ จุดนั้นต้นทุนรวม 5 ปีของทั้งสองอยู่ที่ประมาณ 9,918,000 บาท ถ้า x = 1 แพ็กเกจถูกกว่า 132,000 บาท ซึ่งเป็นส่วนต่าง +1.4% เมื่อเทียบกับ A จึงถือว่าสูสีกันในทางปฏิบัติ ถ้า x = 4 การพัฒนาขึ้นใหม่ทั้งหมดถูกกว่า 948,000 บาท คิดเป็น +7.7% เมื่อเทียบกับ C ขอให้เปลี่ยนราคาต่อคน-เดือนและจำนวนผู้ใช้เป็นค่าของบริษัทท่าน ถ้าราคาต่อหน่วยลดลง การพัฒนาขึ้นใหม่ทั้งหมดจะได้เปรียบ และถ้าจำนวนผู้ใช้เพิ่มขึ้น การสะสมของค่าไลเซนส์แพ็กเกจจะมีผลและกดจุดพลิกให้ต่ำลง

ข้อความที่ว่าใช้ AI สร้างแล้วถูกลงนั้นถูกในเชิงทิศทาง แต่ขนาดต่างกัน ในการสำรวจของ DX ค่ามัธยฐานของการปรับปรุงปริมาณงาน PR ที่ไหลผ่านอยู่ที่ 7.76% ไม่ใช่หลายเท่าตัว เนื่องจากแบบจำลองของบทความนี้ตั้งผลของ AI ไว้ที่ศูนย์ ตัวเลข 1.4 คน-เดือนต่อปีที่แสดงไว้จึงเป็นตัวเลขที่ออกมาในทางเข้มงวดต่อฝั่งการพัฒนาขึ้นใหม่ทั้งหมด แต่ถึงอย่างนั้น สิ่งที่ขยับการตัดสินใจก็ยังไม่ใช่ AI แต่คือ x

และสิ่งแรกที่ควรลงมือทำ ไม่ใช่การขอเอกสารแนะนำผลิตภัณฑ์ แต่คือการนับประวัติการเปลี่ยนแปลงย้อนหลัง 24 เดือน งานนี้จบได้ในไม่กี่วัน และผลของมันคือฐานรองรับการตัดสินใจระดับ 10,000,000 บาทตลอด 5 ปี

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

เอกสารอ้างอิง

• ERP Implementation Failure Statistics โดย Godlan ซึ่งอ้างรายงาน 2026 ERP Report ของ Panorama Consulting Group
• AI Coding Assistant Pricing and Impact โดย DX ที่ getdx.com
• Custom Software Development Cost 2026 โดย LI Solutions
• รายงานสรุปของคณะกรรมการปรับปรุงระบบเลกาซีให้ทันสมัย ลงวันที่ 28 พฤษภาคม 2025 โดย METI และ IPA
• รายงานเชิงพื้นที่และเชิงวิเคราะห์ว่าด้วยการเปลี่ยนแปลงเชิงโครงสร้างของอุตสาหกรรมการผลิตไทย โดย JETRO
• บทความเกี่ยวกับ Thailand Fast Pass โดย Bangkok Shuho
• Software Developer Salary in Bangkok, Thailand โดย ERI SalaryExpert
• ราคาตลาดของค่าพัฒนาระบบหลักขององค์กร โดย c3index

จำนวนเงินทั้งหมดในบทความนี้เป็นแบบจำลองที่ตั้งอยู่บนสมมติฐานซึ่งบริษัทเรากำหนดขึ้นเอง ไม่ใช่ใบเสนอราคาของโครงการใดโครงการหนึ่ง หากเปลี่ยนสมมติฐาน ได้แก่ ราคา 180,000 บาทต่อคน-เดือน ผู้ใช้ 40 คน ระยะเวลา 5 ปี ค่าไลเซนส์ 2,500 บาทต่อผู้ใช้ต่อเดือน โครงสร้างพื้นฐาน 240,000 บาทต่อปี ค่าบำรุงรักษา 12% ต่อปี และงานปรับเข้ากับเวอร์ชันใหม่ 40% ข้อสรุปก็จะเปลี่ยนไป หมวดหมู่ผลิตภัณฑ์และงานสำรวจที่กล่าวถึงในเนื้อหา ล้วนเป็นของแต่ละบริษัทและแต่ละหน่วยงานนั้น ไม่ใช่ผลิตภัณฑ์ของบริษัทเรา ตัวเลขอ้างอิงจากเนื้อหาที่เผยแพร่ต่อสาธารณะ ณ เดือนสิงหาคม 2026