การเริ่มระบบแบบสมอลสตาร์ท วิธีซอยงานที่ตัดสินจากความสัมพันธ์ระหว่างขนาดโครงการกับ QCD

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

การเริ่มแบบเล็กไม่ใช่การประนีประนอม ขอสรุปก่อน

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

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

สัดส่วนที่ผลลัพธ์ไม่ดีนั้น ในโครงการขนาดน้อยกว่า 10 คน-เดือน อยู่ต่ำกว่า 10.0% ทั้ง 3 ด้านของ QCD แต่ในโครงการขนาด 500 คน-เดือนขึ้นไป กลับสูงถึง 29.6% ในด้านคุณภาพ 42.2% ในด้านงบประมาณ และ 47.8% ในด้านระยะเวลา

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

การอ่านตารางนี้ต้องระวังอยู่จุดหนึ่ง ตัวเลขด้านคุณภาพและงบประมาณมาจากแผนภาพที่แบ่งขนาดออกเป็น 5 ช่วงชั้น ส่วน 47.8% ของด้านระยะเวลามาจากอีกแผนภาพหนึ่งที่แบ่งขนาดออกเป็น 3 ช่วงชั้น ในตารางแบบ 3 ช่วงชั้นนั้นไม่มีช่วงที่เรียกว่าน้อยกว่า 10 คน-เดือน อยู่เลย จึงอ่านได้จากข้อความสรุปรวมในเนื้อรายงานเท่านั้น ด้วยเหตุนี้ ช่องล่างซ้ายของตารางข้างบนจึงใส่ไว้เป็นข้อความ ไม่ใช่ตัวเลข

ถึงอย่างนั้น สิ่งที่ตารางสื่อออกมาก็ชัดเจน หากพยายามสร้างงานระดับ 500 คน-เดือน ให้จบในครั้งเดียว สัดส่วนโครงการที่งบบานปลายจะอยู่ที่ 42.2% และสัดส่วนที่ล่าช้ากว่ากำหนดจะอยู่ที่ 47.8% นี่ไม่ใช่กรณียกเว้นที่หลบได้ถ้าทำดีพอ แต่เป็นภาพเฉลี่ยที่ได้จากการรวบรวมโครงการจำนวนมาก ในทางกลับกัน ถ้าซอยให้เล็กกว่า 10 คน-เดือน สัดส่วนที่ผลออกมาไม่ดีจะต่ำกว่า 10% ทั้ง 3 ด้าน การซอยงานจึงไม่ใช่การยอมรับว่าความสามารถไม่ถึง แต่คือการเลือกวางตัวเองไว้ในฝั่งที่สถิติเป็นใจมากกว่า

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

ข้อมูลบอกอะไรเรื่องขนาดโครงการกับ QCD

ก่อนอื่นขอวางตัวเลขที่เป็นฐานของข้อสรุปไว้ให้ครบโดยไม่ตัดทอน แหล่งอ้างอิงคือแผนภาพ 7-1-4 สถานะการรักษา QCD ของการพัฒนาระบบแยกตามขนาดโครงการ จากรายงาน Corporate IT Trend Survey 2026 (สำรวจปีงบประมาณ 2025) ของ JUAS หน่วยทั้งหมดเป็นเปอร์เซ็นต์ และ n คือจำนวนโครงการ

สถานะการรักษาคุณภาพ

สัดส่วนที่ตอบว่าไม่พอใจในด้านคุณภาพ ไต่จาก 5.4% ขึ้นไปถึง 29.6% แบบเพิ่มขึ้นทางเดียวตามขนาดที่ใหญ่ขึ้น เมื่อหารค่าปลายบนด้วยค่าปลายล่างออกมาจริง จะได้ 29.6 ÷ 5.4 = 5.48 เท่า ถ้าไม่ปัดค่าจะได้ 5.481 กว่า ๆ ดังนั้นการเขียนเป็น 5.48 เท่าที่ทศนิยม 2 ตำแหน่งจึงเหมาะสมที่สุด หลายคนอยากเรียกว่าราว 6 เท่า แต่ผลของการหารคือ 5.48 ไม่ใช่ 6 บทความนี้จึงใช้ค่า 5.48 เท่าโดยไม่ปัด

ถัดมาคือด้านงบประมาณ ซึ่งมาจากแผนภาพเดียวกันแต่คนละฝั่ง

สถานะการรักษางบประมาณ

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

ขอย้ำอีกอย่างว่า อย่าสร้างอัตราส่วนระหว่างช่วงชั้นตรงกลางขึ้นมาเอง ตัวอย่างเช่นการคำนวณว่างบบานปลาย 19.6% ของช่วง 50 ถึงต่ำกว่า 100 คน-เดือน เป็นกี่เท่าของ 6.0% ในช่วงน้อยกว่า 10 คน-เดือน นั้นทำได้ในเชิงเลขคณิต แต่สิ่งที่รายงานให้ความหมายไว้คือแนวโน้มที่ไปในทิศทางเดียวว่ายิ่งใหญ่ยิ่งแย่ ไม่ใช่ตัวคูณรายคู่ บทความนี้จึงใช้อัตราส่วนเพียง 2 ค่าข้างต้นเท่านั้น

สำหรับด้านระยะเวลา เส้นแบ่งของขนาดจะเปลี่ยนไป แผนภาพ 7-1-3 สถานะการรักษาระยะเวลาของการพัฒนาระบบแยกตามขนาดโครงการและตามปี (ปีงบประมาณ 2025) ในรายงานฉบับเดียวกัน แบ่งไว้เป็น 3 ช่วงชั้น

สถานะการรักษาระยะเวลา (แบบ 3 ช่วงชั้น)

ตรงนี้ขอเทียบจำนวนช่วงชั้นให้ชัด ตารางด้านคุณภาพและงบประมาณแบ่งเป็น 5 ช่วงชั้น ส่วนตารางด้านระยะเวลาแบ่งเป็น 3 ช่วงชั้น เมื่อจำนวนไม่เท่ากัน จึงห้ามเอาแถวของตาราง 5 ช่วงชั้นไปวางเรียงข้างแถวของตาราง 3 ช่วงชั้น ยืนยันได้จากจำนวนโครงการด้วย ผลรวมต่อไปนี้เป็นการบวกค่า n ในตารางของรายงานโดยบทความนี้เอง เมื่อบวก n ในตารางด้านคุณภาพจะได้ 688 + 562 + 405 + 319 + 223 = 2,197 โครงการ ส่วนผลรวม n ในตารางด้านระยะเวลาคือ 1,647 + 317 + 226 = 2,190 โครงการ ต่างกันอยู่ 7 โครงการ ยิ่งไปกว่านั้น ผลรวมของ 3 ช่วงชั้นฝั่งเล็กในตารางคุณภาพ (688 + 562 + 405 = 1,655 โครงการ) กับช่วงน้อยกว่า 100 คน-เดือน ในตารางระยะเวลา (1,647 โครงการ) ก็ยังต่างกันอยู่ 8 โครงการ แปลว่ากลุ่มประชากรที่นำมารวบรวมไม่ได้ตรงกันทั้งหมด จึงไม่สามารถต่อ 2 ตารางเข้าด้วยกันเพื่อหาอัตราความล่าช้าของช่วงน้อยกว่า 10 คน-เดือน ได้

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

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

ทำไมโครงการใหญ่ถึงพัง เพราะความต้องการไปไม่ถึงสเปก

เราทราบแล้วว่าขนาดกับอัตราผลลัพธ์ที่ไม่ดีของ QCD สัมพันธ์กัน แล้วทำไมของใหญ่ถึงพัง แผนภาพอีกชิ้นในรายงานฉบับเดียวกันให้เบาะแสถึงต้นเหตุที่อยู่ก่อนหน้านั้น นั่นคือแผนภาพ 7-2-7 อุปสรรคในการผลักดันการพัฒนาระบบด้วยทีมภายใน (ตอบได้หลายข้อ ปีงบประมาณ 2025 n = 953)

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

3 อันดับแรกเป็นเรื่องจำนวนคนและความชำนาญของบุคลากร ทั้งเชิงปริมาณ เชิงคุณภาพ และคนที่บริหารโครงการเป็น แต่ในบริบทของบทความนี้ อันดับที่ 4 และ 5 คือของหนัก ความเข้าใจงานปัจจุบันไม่เพียงพออยู่ที่ 38.2% และการขาดความสามารถในการแปลงความต้องการทางธุรกิจให้เป็นสเปกของระบบอยู่ที่ 34.5% ในฐานะอุปสรรคของการพัฒนาด้วยทีมภายใน มากกว่า 1 ใน 3 ของบริษัทชี้ไปที่การสะดุดในงานแปลงงานของตัวเองให้กลายเป็นสเปก

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

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

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

อีกประเด็นหนึ่ง ปัญหาเชิงปริมาณของบุคลากรไม่ใช่เรื่องที่พบเฉพาะในผลสำรวจของญี่ปุ่น การสำรวจแนวโน้ม DX ปีงบประมาณ 2025 ของ Information-technology Promotion Agency, Japan หรือ IPA (จำนวนแบบตอบกลับ 1,799 บริษัท ช่วงสำรวจ 17 เมษายน ถึง 12 มิถุนายน 2026) พบว่า เมื่อถามถึงปริมาณของบุคลากรที่ผลักดัน DX ผลรวมของคำตอบว่าขาดแคลนเล็กน้อยกับขาดแคลนอย่างมากอยู่ที่ 85.5% อย่างไรก็ตาม นี่เป็นคนละการสำรวจกับของ JUAS ทั้งผู้จัดทำ ช่วงเวลา และกลุ่มบริษัทเป้าหมาย จึงนำไปวางเรียงกับตัวเลขของ JUAS เพื่อคำนวณสัดส่วนหรือถกเถียงว่าอันไหนสูงกว่าด้วยไม้บรรทัดเดียวกันไม่ได้ ตรงนี้ขออ้างอิงเพียงในฐานะฉากหลังว่าการรับรู้เรื่องคนไม่พอนั้นเป็นความเห็นที่แพร่หลาย

จะซอยตรงไหน วิธีกำหนดหน่วยของการซอย

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

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

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

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

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

จุดที่ห้ามซอย มาสเตอร์ข้อมูล การรันเลขที่ และสิทธิ์การใช้งาน

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

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

ห้ามแยกมาสเตอร์ข้อมูล

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

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

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

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

ห้ามแยกการรันเลขที่

เลขที่งานผลิต เลขที่ล็อต เลขที่เอกสาร เลขที่ใบสั่งงาน เลขที่การตรวจสอบ ถ้าแยกกฎการรันเลขที่และผู้ที่ทำหน้าที่รันเลขที่ออกจากกัน จะเกิดเลขซ้ำหรือเลขขาดหาย

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

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

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

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

ห้ามแยกสิทธิ์การใช้งาน

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

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

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

สิ่งที่แยกได้กับสิ่งที่แยกไม่ได้

สรุปออกมาได้ดังนี้

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

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

ทำไมการซอยงานถึงได้ผลเป็นพิเศษที่ฐานในประเทศไทย

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

ประการแรกคือ โครงการที่ยาวจะพาดผ่านการเปลี่ยนตัวคน ตามรายงาน Thailand Job Market 2026 Outlook ของ RECRUITdee งบขึ้นเงินเดือนเฉลี่ยของปี 2026 อยู่ที่ราว 4.7% ขณะที่ในสายงานทักษะสูง การเปลี่ยนงานทำให้ผลตอบแทนขยับขึ้น 15 ถึง 30% ตัวเลข 2 ชุดนี้อยู่คนละมิติกัน 4.7% คืออัตราต่อปีที่ขึ้นให้ระหว่างยังอยู่กับที่เดิม ส่วน 15 ถึง 30% คือการกระโดดขึ้นครั้งเดียวตอนย้ายงาน ทั้ง 2 ค่านี้ไม่อยู่ในความสัมพันธ์ที่หารหรือบวกกันได้ แต่เมื่อวางเรียงกันแล้วมอง ก็พอเห็นว่าแรงจูงใจให้คนที่มีทักษะขยับตัวนั้นอยู่ตรงไหน รายงานฉบับเดียวกันระบุอัตราการลาออกในภูมิภาคไว้ที่ราว 17.5% ตัวเลขนี้เขียนกำกับว่าเป็นค่าของภูมิภาค ไม่ได้ระบุว่าเป็นตัวเลขของประเทศไทยโดยลำพัง จึงฟันธงว่าเป็นอัตราการลาออกของไทยไม่ได้ ถึงกระนั้นก็ยังใช้เป็นภาพระดับอ้างอิงได้ อนึ่ง รายงานฉบับนี้ไม่ได้ระบุตัวเลขเงินเดือนเป็นจำนวนเงินไว้ บทความนี้จึงไม่ก้าวล่วงไปพูดถึงจำนวนเงิน

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

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

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

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

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

รูปแบบความล้มเหลวที่พบบ่อยของสมอลสตาร์ท

ไม่ใช่ว่าซอยแล้วจะสำเร็จเสมอไป สมอลสตาร์ทมีวิธีล้มเหลวที่เป็นเอกลักษณ์ของตัวเอง ที่พบบ่อยมี 4 แบบต่อไปนี้

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

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

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

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

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

จะเลือกอะไรเป็นเฟสที่ 1 ให้เริ่มจากอาการ

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

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

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

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

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

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

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

เส้นแบ่งระหว่างทีมภายในกับการจ้างภายนอกกับสมอลสตาร์ท

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

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

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

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

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

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

แนวทางเดินเฟสที่ 1 ให้จบใน 13 สัปดาห์ หรือราว 90 วัน

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

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

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

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

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

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

ควรเริ่ม DX ของโรงงานจากอะไร

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

ขีดจำกัดของการจัดการด้วย Excel มาถึงตอนไหน

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

จะกำจัดการคีย์ข้อมูลซ้ำซ้อน ควรเริ่มจากอะไร

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

ในอุตสาหกรรมการผลิต จะแก้การพึ่งพาตัวบุคคลควรเริ่มจากอะไร

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

การเลิกใช้กระดาษควรทำรวดเดียวจบหรือไม่

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

สมอลสตาร์ทสุดท้ายแล้วรวมทั้งหมดจะแพงกว่าหรือไม่

ภาระงานส่วนที่ของเก่ากับของใหม่อยู่ร่วมกันตลอดช่วงเปลี่ยนผ่านนั้นเพิ่มขึ้นจริง แต่สิ่งที่ควรนำมาเทียบไม่ใช่กรณีทำทีเดียวจบแล้วสำเร็จสวยงาม หากแต่เป็นค่าคาดหมายของสิ่งที่จะเกิดขึ้นจริง ในผลสำรวจของ JUAS สัดส่วนของโครงการขนาด 500 คน-เดือนขึ้นไปที่งบเกินกว่าที่วางไว้อยู่ที่ 42.2% ส่วนโครงการที่น้อยกว่า 10 คน-เดือน อยู่ที่ 6.0% อัตราส่วนระหว่างค่าปลายบนกับค่าปลายล่างคือ 42.2 ÷ 6.0 = 7.03 เท่า ส่วนความล่าช้าด้านระยะเวลาของโครงการ 500 คน-เดือนขึ้นไปอยู่ที่ 47.8% จำเป็นต้องนำการบานปลายและความล่าช้าในกรณีเดินทีเดียวจบมาคิดรวมก่อนแล้วจึงเปรียบเทียบ อนึ่ง การสำรวจนี้เก็บจากบริษัทผู้ใช้ระบบในประเทศญี่ปุ่น ไม่ใช่ผลงานจริงของนิติบุคคลในไทย โปรดใช้เป็นการอ้างอิงแนวโน้ม

การปรับปรุงกระบวนการทำงานของการบริหารการผลิต ควรทำก่อนหรือหลังการนำระบบเข้ามา

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

เฟสที่ 1 ควรมีขนาดเท่าไรจึงเหมาะสม

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

จะหางบสำหรับเฟสที่ 2 เป็นต้นไปได้อย่างไร

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

สรุป

การเริ่มระบบแบบสมอลสตาร์ทไม่ใช่ทางเลือกของคนที่เสียดายเงินลงทุน อย่างที่รายงาน Corporate IT Trend Survey 2026 ของ JUAS แสดงให้เห็น ระหว่างขนาดของโครงการกับอัตราผลลัพธ์ที่ไม่ดีของ QCD มีความสัมพันธ์ที่ชัดเจน ความไม่พอใจด้านคุณภาพอยู่ที่ 5.4% ในกลุ่มน้อยกว่า 10 คน-เดือน และ 29.6% ในกลุ่ม 500 คน-เดือนขึ้นไป คิดเป็นอัตราส่วน 5.48 เท่า งบที่บานปลายอยู่ที่ 6.0% ในกลุ่มน้อยกว่า 10 คน-เดือน และ 42.2% ในกลุ่ม 500 คน-เดือนขึ้นไป คิดเป็นอัตราส่วน 7.03 เท่า ส่วนความล่าช้าด้านระยะเวลา จากการรวบรวมแบบ 3 ช่วงชั้นซึ่งใช้เส้นแบ่งคนละชุด กลุ่ม 500 คน-เดือนขึ้นไปอยู่ที่ 47.8% การซอยงานคือการตัดสินใจวางตัวเองไว้ในฝั่งที่ได้เปรียบของความสัมพันธ์นี้ และตัวมันเองก็คือการบริหารความเสี่ยงที่สำคัญที่สุด

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

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

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

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

ข้อมูลอ้างอิง

• JUAS Corporate IT Trend Survey Report 2026 (Chapter 7 System Development) — Japan Users Association of Information Systems อ้างอิงแผนภาพ 7-1-3, 7-1-4 และ 7-2-7
• JUAS Corporate IT Trend Survey 2026 Press Release ฉบับที่ 2 — ภาพรวมการสำรวจ คำตอบที่ใช้ได้ 957 บริษัท ช่วงสำรวจ 5 กันยายน ถึง 24 ตุลาคม 2025
• JUAS Corporate IT Trend Survey หน้าแนะนำการสำรวจ — ที่มาที่ไปของการสำรวจและรายการของปีก่อนหน้า
• IPA DX Trend Survey ปีงบประมาณ 2025 Press Release — Information-technology Promotion Agency, Japan จำนวนแบบตอบกลับ 1,799 บริษัท ความขาดแคลนเชิงปริมาณของบุคลากรผลักดัน DX 85.5%
• Thailand Job Market 2026 Outlook — RECRUITdee งบขึ้นเงินเดือนเฉลี่ยราว 4.7% อัตราการลาออกในภูมิภาคราว 17.5% ประมาณการการเติบโตทางเศรษฐกิจราว 1.6% โดยที่มาคือ IMF
• JUAS Corporate IT Trend Survey 2026 Press Release ฉบับที่ 1 — รายงานฉบับแรกเกี่ยวกับการเผยแพร่ผลสำรวจ