เมื่อโรงงานในประเทศไทยหรือเวียดนามเริ่มพิจารณาการนำระบบบริหารการผลิตมาใช้อย่างจริงจัง สิ่งแรกที่มักติดขัดคือคำถามว่าจะเริ่มต้นจากตรงไหน หลายบริษัทศึกษาการเปรียบเทียบตัวผลิตภัณฑ์และช่วงราคามาแล้วอย่างครบถ้วน แต่ก็ยังมองไม่ออกว่าตั้งแต่การกำหนดความต้องการ การคัดเลือกผู้ขาย การวิเคราะห์ Fit&Gap การทดสอบ การย้ายข้อมูล ไปจนถึงการขึ้นระบบจริงนั้นดำเนินไปอย่างไร และใครในองค์กรต้องทำอะไรในช่วงเวลาใด บทความนี้แบ่งกระบวนการทั้งหมดออกเป็น 9 เฟส และอธิบายเนื้องาน ผู้เกี่ยวข้อง รวมถึงจุดที่มักสะดุด จากมุมมองของคนที่ทำงานจริง พร้อมกันนั้นยังครอบคลุมประเด็นเฉพาะของฐานการผลิตในอาเซียน เช่น วีซ่าสำหรับวิศวกรระบบชาวญี่ปุ่นที่เดินทางมาระยะสั้น ช่วงปิดบัญชีที่งานล้นมือในเดือนธันวาคม และโครงสร้างทีมที่รองรับภาษาญี่ปุ่นของผู้ให้บริการในประเทศไทย
ระบบบริหารการผลิตคืออะไร และทำไมจึงถูกพิจารณากันมากในตอนนี้
หน้างานจำนวนมากเข้าใจว่าการนำระบบบริหารการผลิตมาใช้คือการซื้อซอฟต์แวร์มาติดตั้ง แต่ในทางปฏิบัติแล้วมันคือการกลับมาอธิบายกระบวนการทำงานออกมาเป็นภาษาอีกครั้ง ทำสิ่งที่ทำให้เป็นมาตรฐานได้ให้เป็นมาตรฐาน แล้วออกแบบวิธีทำงานใหม่ให้สอดคล้องกับระบบ สิ่งที่ซื้อคือซอฟต์แวร์ แต่สิ่งที่เปลี่ยนคือการเคลื่อนที่ของคนและข้อมูล ความเข้าใจที่คลาดเคลื่อนตรงนี้เองคือจุดตั้งต้นของความล้มเหลวส่วนใหญ่ที่จะกล่าวถึงในช่วงท้าย
เบื้องหลังที่ทำให้มีการพิจารณามากขึ้น
ผลสำรวจที่ทำกับวิสาหกิจขนาดกลางและขนาดย่อมในประเทศญี่ปุ่นพบว่า บริษัทที่ตอบว่าดำเนินการ DX อยู่แล้วหรือกำลังพิจารณาที่จะดำเนินการมีอยู่ 39.1% การสำรวจนี้ทำกับบริษัทขนาดกลางและขนาดย่อมทั่วประเทศจำนวน 1,000 บริษัท ระหว่างวันที่ 5 ถึง 18 ธันวาคม 2025 และเผยแพร่ในเดือนกุมภาพันธ์ 2026 ซึ่งเป็นระดับที่แทบไม่ต่างจากการสำรวจครั้งก่อนในเดือนธันวาคม 2024 ในทางกลับกัน การใช้งาน AI อยู่ที่ 28.4% เพิ่มขึ้น 14.1 จุดจากครั้งก่อน จึงอ่านได้ว่าอัตราการเริ่มลงมือทำ DX โดยรวมยังย่ำอยู่กับที่ ขณะที่การใช้เทคโนโลยีเฉพาะด้านกำลังเร่งตัวขึ้นอย่างรวดเร็ว
หากจำกัดเฉพาะภาคการผลิต ตัวเลขจะเข้มงวดขึ้นอีก ในสมุดปกขาวอุตสาหกรรมการผลิต หรือ Monodzukuri White Paper ประจำปี 2026 ที่เสนอต่อการประชุมสภาแห่งชาติของญี่ปุ่นครั้งที่ 221 ในเดือนพฤษภาคม 2026 พบว่าวิสาหกิจขนาดกลางและขนาดย่อมที่ตอบว่ายังไม่ได้จัดทำกลยุทธ์การใช้เทคโนโลยีดิจิทัลและไม่มีแผนจะจัดทำ มีสูงถึง 55% ปัญหาร่วมที่ถูกยกขึ้นมาคือการขาดความรู้และองค์ความรู้ด้านเทคโนโลยีดิจิทัล ซึ่งอยู่ที่ประมาณ 46% ถึง 58% และการขาดแคลนบุคลากร ซึ่งอยู่ที่ประมาณ 47% ถึง 58% นั่นหมายความว่าก่อนจะไปถึงคำถามว่าควรลงทุนหรือไม่ สภาพที่ว่าไม่มีคนในองค์กรที่ออกแบบได้นั้นเป็นสิ่งที่หลายบริษัทเผชิญร่วมกัน
ที่ฐานการผลิตในต่างประเทศ ข้อจำกัดนี้ยิ่งส่งผลรุนแรงกว่าเดิม ฝ่ายสารสนเทศของสำนักงานใหญ่ในญี่ปุ่นไม่ได้รู้รายละเอียดงานของโรงงานในพื้นที่ ส่วนที่โรงงานเองก็ไม่มีผู้ดูแลด้าน IT เต็มเวลาแม้แต่คนเดียว หรือมีเพียงคนเดียวที่ควบตำแหน่งอื่นอยู่ ซึ่งเป็นโครงสร้างที่พบได้ทั่วไป ด้วยเหตุนี้ การมีแบบแผนของการเดินโครงการติดตัวไว้ล่วงหน้าจึงมีคุณค่ามากเป็นพิเศษ
ข้อตั้งต้นที่ทำให้เรื่องนี้ไม่จบแค่การเลือกระบบ
การนำระบบบริหารการผลิตมาใช้แบ่งออกได้เป็น 2 ช่วงใหญ่ ช่วงแรกคือช่วงก่อนนำมาใช้ ซึ่งครอบคลุมจนถึงการตัดสินใจเรื่องวิธีการว่าจะใช้แพ็กเกจสำเร็จรูปตามที่เป็น จะเพิ่มการปรับแต่ง หรือจะพัฒนาขึ้นใหม่ทั้งหมด อีกช่วงหนึ่งคือช่วงลงมือนำมาใช้จริง ซึ่งเริ่มจากการวิเคราะห์ Fit&Gap ไปสู่การจัดระเบียบข้อมูลหลัก การตั้งค่า การปรับแต่ง การทดสอบ จนถึงการใช้งานจริงและการย้ายข้อมูล
ในสองช่วงนี้ ความสนใจภายในองค์กรเกือบทั้งหมดกระจุกอยู่ที่ครึ่งแรกคือคำถามว่าจะเลือกอะไร แต่ปริมาณงานและความเสี่ยงที่จะล้มเหลวส่วนใหญ่อยู่ที่ครึ่งหลัง เหตุที่บทความนี้แยกอธิบายละเอียดถึง 9 เฟส ก็เพราะเมื่อรู้ล่วงหน้าว่าครึ่งหลังจะเกิดอะไรขึ้น เกณฑ์การเลือกในครึ่งแรกจะเปลี่ยนไปเอง การลองจินตนาการว่าการวิเคราะห์ Fit&Gap จะทำให้เกิดช่องว่างกี่รายการกับบริษัทของเรา ให้ความแม่นยำในการคัดเลือกมากกว่าการนั่งไล่ดูรายการฟังก์ชันของผลิตภัณฑ์
สำหรับมุมมองการเปรียบเทียบว่าควรเลือกผลิตภัณฑ์หมวดใด เราแยกอธิบายไว้ต่างหากใน การเปรียบเทียบและวิธีเลือกระบบบริหารการผลิตที่ใช้ได้ในประเทศไทย บทความนี้จะโฟกัสไปที่ขั้นถัดไป คือจะขับเคลื่อนกระบวนการนำมาใช้ทั้งหมดซึ่งรวมการคัดเลือกไว้ด้วยอย่างไร
ขั้นตอนการนำระบบบริหารการผลิตมาใช้ ภาพรวม 9 เฟส
เริ่มจากภาพรวมก่อน ชื่อเรียกอาจต่างกันไปบ้างตามแต่ละผู้ขาย แต่ในทางปฏิบัติ หากจัดเป็น 9 เฟสตามนี้ จะช่วยลดความเข้าใจไม่ตรงกันทั้งในการอธิบายภายในองค์กรและในการคุยกับผู้ขาย
| เฟส | งานหลัก | ผู้รับผิดชอบหลัก | ผลงานส่งมอบหลัก |
|---|---|---|---|
| 1 การกำหนดความต้องการ | ทำให้งานปัจจุบันมองเห็นได้ อธิบายปัญหาออกมาเป็นภาษา นิยามภาพที่อยากไปให้ถึง | ฝ่ายงานเป็นแกนหลัก ฝ่ายสารสนเทศสนับสนุน | เอกสารกำหนดความต้องการ ผังกระบวนการทำงาน |
| 2 การคัดเลือกผู้ขาย | จัดทำ RFP ขอข้อเสนอ ดูการสาธิต ตรวจสอบทีมงานและผลงาน | ฝ่ายงาน ฝ่ายสารสนเทศ และฝ่ายจัดซื้อ | RFP ตารางเปรียบเทียบข้อเสนอ เอกสารเหตุผลการคัดเลือก |
| 3 การทำสัญญา | ตกลงขอบเขตและเส้นแบ่งความรับผิดชอบ กำหนดเงื่อนไขการตรวจรับและการบำรุงรักษา | ผู้บริหาร ฝ่ายกฎหมาย ฝ่ายจัดซื้อ | สัญญา SOW รายละเอียดใบเสนอราคา |
| 4 การออกแบบและวิเคราะห์ Fit&Gap | ตรวจความสอดคล้องกับฟังก์ชันมาตรฐาน จำแนกช่องว่างและกำหนดแนวทางรับมือ | ฝ่ายงานและวิศวกรระบบของผู้ขาย | รายการ Fit&Gap เอกสารออกแบบพื้นฐาน |
| 5 การพัฒนาและปรับแต่ง | งานตั้งค่า พัฒนาส่วนเสริม จัดทำแบบฟอร์ม เชื่อมต่อกับระบบอื่น | ผู้ขายเป็นแกนหลัก ฝ่ายสารสนเทศเป็นผู้ประสานงาน | สภาพแวดล้อมที่ตั้งค่าแล้ว ส่วนเสริม อินเทอร์เฟซเชื่อมต่อ |
| 6 การทดสอบและ UAT | หลังทดสอบระดับหน่วยและระดับเชื่อมต่อแล้ว ฝ่ายงานทำการทดสอบเพื่อยอมรับระบบ | ผู้ขายและฝ่ายงาน | เอกสารข้อกำหนดการทดสอบ ผล UAT รายการปัญหา |
| 7 การย้ายข้อมูล | จัดระเบียบข้อมูลหลัก ดึงและแปลงข้อมูลที่จะย้าย ซ้อมย้ายข้อมูล | ฝ่ายงานเป็นแกนหลัก ผู้ขายสนับสนุน | แผนการย้ายข้อมูล ผลการตรวจสอบหลังย้าย |
| 8 การขึ้นระบบจริง | ตัดสินความพร้อมขึ้นระบบ สลับระบบ สนับสนุนอย่างเข้มข้นในช่วงแรก | ทั้งบริษัท โดยผู้บริหารเป็นผู้ตัดสินใจขั้นสุดท้าย | บันทึกการตัดสินความพร้อม บันทึกการใช้งานช่วงแรก |
| 9 การทำให้ยั่งยืน | ทำให้กฎการใช้งานติดเป็นนิสัย อบรม วัดผล และหมุนวงจรปรับปรุง | ฝ่ายงานเป็นแกนหลัก | คู่มือขั้นตอนการใช้งาน ผลการวัด KPI |
9 เฟสนี้ดูเหมือนจะเดินไปข้างหน้าเป็นเส้นตรง แต่ในความเป็นจริงจะเกิดขึ้นเสมอว่าการวิเคราะห์ Fit&Gap ในเฟส 4 ทำให้พบสิ่งที่ตกหล่นไปจากการกำหนดความต้องการ แล้วต้องย้อนกลับไปเฟส 1 บางส่วน การย้อนกลับไม่ใช่ความล้มเหลวในตัวมันเอง ปัญหาอยู่ที่การไม่ยอมย้อนกลับทั้งที่ควรย้อน แล้วดันเดินหน้าต่อไปทั้งที่ยังคลุมเครือ

ขอเสริมเรื่องระยะเวลา สถิติที่น่าเชื่อถือซึ่งระบุระยะเวลามาตรฐานของทุกเฟสนั้น อย่างน้อยในข้อมูลที่เปิดเผยต่อสาธารณะก็ยังไม่พบ ตัวเลขคร่าวที่ผู้ขายเสนอมาก็เปลี่ยนแปลงได้มากตามขอบเขตงานและความซับซ้อนของกระบวนการ ดังนั้นบทความนี้จึงไม่ระบุจำนวนเดือนแบบฟันธง แต่ควรเข้าใจอย่างมีช่วงเผื่อไว้ว่า มีหลายกรณีที่ว่ากันว่าลำพังการกำหนดความต้องการก็ต้องใช้เวลาประมาณ 3 เดือน สำหรับวิธีวางตารางงาน เราจัดระเบียบไว้ต่างหากใน ระยะเวลาการนำระบบบริหารการผลิตมาใช้และวิธีวางแผนตารางงาน
คำอธิบายเชิงปฏิบัติของแต่ละเฟส
จากนี้จะไล่ดูทั้ง 9 เฟสตามลำดับ โดยเฉพาะการวิเคราะห์ Fit&Gap ในเฟส 4 ซึ่งเป็นจุดพีคที่เชื่อมโยงโดยตรงกับสถิติสาเหตุความล้มเหลวที่จะกล่าวถึงภายหลัง จึงจะอธิบายให้หนากว่าเฟสอื่น
เฟส 1 การกำหนดความต้องการ ตัดสินอะไรบ้าง
การกำหนดความต้องการมักถูกเข้าใจว่าเป็นขั้นตอนตัดสินว่าอยากให้ระบบทำอะไร แต่เวลาส่วนใหญ่จริง ๆ ถูกใช้ไปกับการทำให้สภาพปัจจุบันมองเห็นได้ ข้อมูลคำสั่งซื้อถูกส่งต่อไปที่ใดด้วยแบบฟอร์มอะไร ใครเป็นคนตัดสินอะไร และตรงไหนที่กลายเป็นบันทึกเขียนมือ เมื่อไล่เส้นทางนี้ไปทีละจุด ก็จะพบข้อเท็จจริงว่าไม่มีใครในบริษัทที่เห็นภาพรวมทั้งหมด
เอกสารกำหนดความต้องการถูกวางบทบาทให้เป็นผลงานส่งมอบที่ป้องกันความเข้าใจไม่ตรงกันระหว่างลูกค้ากับผู้พัฒนา นั่นแปลว่าเป้าหมายของการเขียนคือการมีข้อตกลงร่วม ไม่ใช่ความครบถ้วน ต่อให้ทำเอกสารหนาเพียงใด หากฝ่ายงานไม่ได้อ่าน เอกสารนั้นก็ไม่ได้ทำหน้าที่ของมัน
ในทางปฏิบัติ การดำเนินตามลำดับนี้จะช่วยให้ไม่ติดขัด
- ขีดเส้นขอบเขตงานที่จะครอบคลุมเป็นอย่างแรก จะเอาแค่ตั้งแต่รับคำสั่งซื้อจนถึงจัดส่ง หรือจะรวมการคำนวณต้นทุนด้วย และจะรวมงานจัดซื้อกับสต๊อกไปถึงระดับใด
- สัมภาษณ์กระบวนการปัจจุบันของแต่ละแผนก แล้ววาดออกมาเป็นผังตามที่เป็นจริง ไม่ใช่วาดภาพในอุดมคติ แต่เขียนสิ่งที่ทำกันอยู่จริงในตอนนี้
- ไล่รายการปัญหาในระดับความละเอียดของสิ่งที่กำลังลำบากอยู่ แล้วแยกออกเป็นสิ่งที่จะแก้ด้วยระบบ สิ่งที่จะแก้ด้วยกฎการปฏิบัติงาน และสิ่งที่จะยังไม่จัดการในรอบนี้
- สะสางความต้องการด้านการเชื่อมต่อกับระบบอื่น แบบฟอร์มที่จำเป็น และช่องว่างสำหรับการขยายในอนาคต หากผัดวันตรงนี้ จะกลายเป็นการย้อนงานครั้งใหญ่ในเฟส 4
สิ่งที่ต้องระวังเป็นพิเศษสำหรับฐานการผลิตในต่างประเทศคือรูปแบบการรายงานไปยังสำนักงานใหญ่ที่ญี่ปุ่น แม้ในแง่งานของโรงงานจะไม่จำเป็น แต่หากสำนักงานใหญ่กำหนดวิธีตัดต้นทุนหรือระดับความละเอียดของการรายงานความคืบหน้าไว้แล้ว สิ่งนั้นก็คือความต้องการ การเพิ่มข้อเรียกร้องของสำนักงานใหญ่เข้ามาตอนท้ายของการกำหนดความต้องการ จะทำให้ต้องรื้อการออกแบบใหม่
เฟส 2 การคัดเลือกผู้ขายและวิธีใช้ RFP
เมื่อความต้องการรวบรวมได้ระดับหนึ่งแล้ว ก็ถึงเวลาขอข้อเสนอจากผู้ขาย หากเดินหน้าด้วยการพูดปากเปล่าและอีเมลโดยไม่ทำ RFP ระดับความละเอียดของข้อเสนอจะกระจัดกระจายไปตามแต่ละผู้ขาย จนเปรียบเทียบกันไม่ได้เลย วิธีเขียน RFP อย่างเป็นรูปธรรม เราสรุปไว้ใน วิธีเขียน RFP สำหรับระบบบริหารการผลิตและหัวข้อที่ต้องระบุ
สำหรับการคัดเลือกที่ฐานการผลิตในอาเซียน การตรวจสอบโครงสร้างทีมและภาษาที่รองรับได้ผลดีกว่าการเทียบรายการฟังก์ชัน หากจัดระเบียบหัวข้อที่ควรตรวจสอบจะได้ดังนี้
| หัวข้อที่ต้องตรวจสอบ | สิ่งที่ควรถามให้ชัด | จุดชี้ขาด |
|---|---|---|
| ผู้รับผิดชอบการกำหนดความต้องการ | วิศวกรระบบชาวญี่ปุ่นเข้ามาร่วมกี่คน และด้วยสัดส่วนเวลาเท่าไร | ตรวจสอบได้ถึงระดับชื่อและอัตราการทำงานจริงหรือไม่ |
| การใช้ล่ามคั่นกลาง | สัมภาษณ์หน้างานเป็นภาษาญี่ปุ่นได้โดยตรง หรือต้องผ่านล่าม | เมื่อผ่านล่าม รายละเอียดเชิงนัยของงานมักตกหล่น |
| ภาษาที่รองรับในงานบำรุงรักษา | ช่วงเวลาที่รับคำถามหลังขึ้นระบบเป็นภาษาญี่ปุ่นได้ | เป็นเวลาญี่ปุ่นหรือเวลาไทย และมีผู้รับผิดชอบกี่คน |
| การรองรับกฎหมายท้องถิ่น | ผลงานการรองรับข้อกำหนดด้านภาษีและบัญชี รวมถึงรูปแบบเอกสารของไทย | ตรวจสอบจากกรณีศึกษาการนำไปใช้จริง |
| ความต่อเนื่องของบุคลากร | ทีมที่มาเสนองานจะรับผิดชอบเฟสลงมือทำจริงด้วยหรือไม่ | หากทีมเสนองานกับทีมลงมือทำเป็นคนละชุด ต้องระวัง |
ในบรรดาหัวข้อเหล่านี้ แถวแรกจะส่งผลมากที่สุดในภายหลัง เหตุผลจะอธิบายละเอียดในหัวข้อข้อควรระวังเฉพาะของประเทศไทย แต่โดยสรุปคือบุคลากรที่ดึงความต้องการออกมาเป็นภาษาญี่ปุ่นได้นั้นเป็นทรัพยากรที่จำกัดแม้ในผู้ให้บริการในประเทศไทยเอง การจัดสรรทรัพยากรนี้จึงต้องตกลงกันให้แน่นอนก่อนเซ็นสัญญา
เฟส 3 จุดที่ห้ามปล่อยให้คลุมเครือในสัญญา
สิ่งที่ต้องตกลงในขั้นสัญญาไม่ใช่ตัวเงินเสียทีเดียว แต่คือขอบเขตและเส้นแบ่งความรับผิดชอบ โดยเฉพาะ 3 ประเด็นต่อไปนี้ที่มักกลายเป็นชนวนข้อพิพาทในภายหลัง
ประเด็นแรกคือการจัดการเรื่องการปรับแต่ง งานพัฒนาส่วนเสริมที่เกิดขึ้นจากผลการวิเคราะห์ Fit&Gap นั้นรวมอยู่ในวงเงินตามสัญญาหรือต้องเสนอราคาแยก ถ้ารวมอยู่แล้ว รวมได้ถึงกี่คนวัน หากไม่มีเส้นแบ่งตรงนี้ การถกเรื่องค่าใช้จ่ายจะยืดเยื้อไปเรื่อยตั้งแต่เฟส 4 เป็นต้นไป
ประเด็นที่สองคือขอบเขตความรับผิดชอบของการย้ายข้อมูล งานจัดระเบียบข้อมูลต้นทาง เช่น การแก้รหัสสินค้าซ้ำซ้อนหรือการเขียนชื่อคู่ค้าไม่เป็นมาตรฐานเดียวกัน โดยทั่วไปเป็นความรับผิดชอบของฝ่ายผู้ว่าจ้าง หากเข้าใจผิดว่าโยนให้ผู้ขายทำได้ งานจะไปหยุดอยู่ที่เฟส 7
ประเด็นที่สามคือเงื่อนไขการตรวจรับ อะไรคือเกณฑ์ที่ถือว่าเสร็จสมบูรณ์ การเขียนเกณฑ์ผ่านของ UAT ออกมาเป็นลายลักษณ์อักษรตั้งแต่ตอนทำสัญญา จะช่วยลดการถกเถียงที่ไม่เกิดผลในเฟส 6 ว่าสิ่งนี้เป็นสเปกหรือเป็นข้อบกพร่องกันแน่
ภาพรวมค่าใช้จ่ายและแนวคิดเรื่อง TCO เราแยกอธิบายไว้ใน ค่าใช้จ่ายการนำระบบบริหารการผลิตมาใช้และรายละเอียดของ TCO
เฟส 4 วิธีดำเนินการวิเคราะห์ Fit&Gap อย่างเป็นรูปธรรม
แกนกลางของเฟสลงมือทำจริงคือการวิเคราะห์ Fit&Gap ซึ่งหมายถึงขั้นตอนการสะสางว่างานใดรองรับได้ด้วยฟังก์ชันมาตรฐานของแพ็กเกจ ซึ่งเรียกว่า Fit และงานใดรองรับไม่ได้ ซึ่งเรียกว่า Gap แล้วกำหนดแนวทางรับมือเป็นรายช่องว่าง
วิธีดำเนินการโดยรวมแบ่งได้เป็น 4 ขั้น
ขั้นที่ 1 คือทำให้ขอบเขตและลำดับความสำคัญของงานที่จะวิเคราะห์ชัดเจน หากพยายามวิเคราะห์ทุกงานด้วยแรงเท่ากันหมด จะทำไม่เสร็จภายในกำหนด ควรเริ่มจากกระแสงานหลักที่เชื่อมโยงตรงกับยอดขายหรือคุณภาพ ส่วนการจัดการกรณียกเว้นที่เกิดเพียงไม่กี่ครั้งต่อเดือนให้เลื่อนไปทีหลัง หรือระบุให้ชัดว่าอยู่นอกขอบเขตของรอบนี้
ขั้นที่ 2 คือการสัมภาษณ์แต่ละแผนก จัดระเบียบกระบวนการทำงานปัจจุบันและปัญหา แล้วนำไปทาบกับหน้าจอของฟังก์ชันมาตรฐานเพื่อยืนยันว่าการทำงานด้วยขั้นตอนนี้เดินได้จริงหรือไม่ สิ่งสำคัญตรงนี้คือต้องให้ผู้รับผิดชอบของฝ่ายงานได้ลองสัมผัสหน้าจอจริง ลำพังการเปิดเอกสารให้ดูแล้วอธิบาย จะไม่ทำให้พบช่องว่าง
ขั้นที่ 3 คือการตัดสินสเปก โดยพิจารณาการเชื่อมต่อกับระบบอื่น แบบฟอร์มที่จำเป็น และความสามารถในการขยายในอนาคต แล้วสรุปให้ได้ว่าจะใช้การตั้งค่าใดของฟังก์ชันมาตรฐาน แบบฟอร์มเป็นสิ่งที่ถูกมองข้ามเป็นพิเศษ และช่องว่างมักปรากฏออกมาในรูปที่ว่ารายการกระดาษที่หน้างานพิมพ์ใช้ทุกวันนั้นไม่มีอยู่ในฟังก์ชันมาตรฐาน
ขั้นที่ 4 คือการตัดสินแนวทางรับมือต่อช่องว่าง ซึ่งมีทางเลือกอยู่ 3 ทาง
| แนวทางรับมือ | เนื้อหา | กรณีที่เหมาะสม | ความเสี่ยงหลัก |
|---|---|---|---|
| รับมือด้วยการปฏิบัติงาน | ไม่แก้ระบบ แต่ดูดซับด้วยขั้นตอนปฏิบัติงานหรือเอกสารเสริม | ความถี่ในการเกิดต่ำ ขอบเขตผลกระทบแคบ | งานมือยังเหลืออยู่ และมักผูกกับตัวบุคคล |
| BPR หรือการเปลี่ยนฝั่งกระบวนการทำงาน | เปลี่ยนวิธีทำงานให้เข้ากับฟังก์ชันมาตรฐาน | วิธีที่ทำอยู่ปัจจุบันไม่มีเหตุผลรองรับที่หนักแน่น | หน้างานต่อต้าน และเกิดต้นทุนการอบรม |
| พัฒนาส่วนเสริม | สร้างฟังก์ชันขึ้นมาด้วยการพัฒนาเพิ่มเติม | เป็นงานที่เป็นแหล่งความสามารถในการแข่งขันและทดแทนไม่ได้ | ค่าใช้จ่ายเพิ่ม กำหนดส่งยืดออก และเป็นภาระตอนอัปเดตในอนาคต |
ในทางปฏิบัติ ไม่ควรเลือก 3 ทางนี้แบบกลไก แต่ควรเขียนกำกับลงในรายการช่องว่างว่ามีความจำเป็นเชิงกระบวนการทำงานแค่ไหน และมีวิธีทดแทนหรือไม่ แล้วตัดสินทีละรายการ การแบ่งบทบาทให้ฝ่ายงานเป็นผู้ตัดสิน ส่วนผู้ขายทำหน้าที่เสนอทางเลือกและประมาณการปริมาณงานเท่านั้น จะทำให้การถกเถียงเดินหน้าได้
จุดที่มักพลาดตรงนี้คือการเอนเอียงไปทางพัฒนาส่วนเสริมอย่างง่ายดายเกินไป หากเก็บทุกความต้องการของหน้างานมาหมด รายการช่องว่างส่วนใหญ่จะกลายเป็นส่วนเสริม ผลคือทั้งค่าใช้จ่ายและระยะเวลาบานปลาย และยังต้องแบกสินทรัพย์ที่ต้องแก้ไขทุกครั้งที่แพ็กเกจอัปเกรดเวอร์ชัน ในทางกลับกัน หากพยายามดันทุกอย่างด้วย BPR หน้างานจะไม่ขยับ และจะเหลือระบบที่ไม่มีใครใช้หลังขึ้นระบบจริง
เกณฑ์ที่ใช้ตัดสินได้ผลดีคือการตั้งคำถามต่อไปนี้ทีละรายการ วิธีทำงานแบบนี้เกี่ยวข้องกับเหตุผลที่ลูกค้าเลือกบริษัทเราหรือไม่ ถ้าไม่เกี่ยว ก็ยังมีช่องให้ปรับเข้าหาฟังก์ชันมาตรฐาน ถ้าเกี่ยว นั่นคือช่องว่างที่ควรลงทุน
ที่ฐานการผลิตในประเทศไทย จะมีมุมมองเฉพาะพื้นที่เพิ่มเข้ามาอีก ข้อกำหนดด้านภาษีของไทยและรูปแบบเอกสารที่คู่ค้าเรียกร้อง เป็นช่องว่างชนิดที่หลบเลี่ยงด้วยการปฏิบัติงานหรือ BPR ไม่ได้ หากแยกสิ่งเหล่านี้ออกมาตั้งแต่ต้นในฐานะส่วนเสริมที่จำเป็นต้องมี แล้วแยกออกจากการพิจารณาส่วนที่เหลือ การถกเถียงจะเป็นระเบียบขึ้น
เฟส 5 สิ่งที่ฝ่ายผู้ว่าจ้างต้องทำระหว่างช่วงพัฒนาและปรับแต่ง
เฟสนี้เป็นช่วงที่ผู้ขายลงมือทำงาน ฝ่ายผู้ว่าจ้างมักกลายเป็นฝ่ายที่แค่รอ แต่จริง ๆ แล้วมีสิ่งที่ต้องทำ
อย่างแรกคือเริ่มลงมือจัดระเบียบข้อมูลหลักเพื่อเตรียมการย้ายข้อมูลในเฟส 7 งานกำจัดความซ้ำซ้อนและการเขียนที่ไม่เป็นมาตรฐานเดียวกันในข้อมูลหลักของรายการสินค้า คู่ค้า และกระบวนการผลิต ใช้เวลามากและต้องอาศัยการตัดสินใจของหน้างาน จึงจ้างข้างนอกทำแทนไม่ได้ หากไม่ทำคู่ขนานไปในช่วงพัฒนา จะจนตรอกก่อนถึงวันย้ายข้อมูล
อย่างที่สองคือการเตรียมแผนการทดสอบ ในเฟสถัดไปฝ่ายงานจะต้องทำ UAT แต่ถ้าเพิ่งเริ่มสร้างเคสทดสอบตอนนั้นก็จะไม่ทัน ระหว่างช่วงพัฒนาควรให้ฝ่ายงานเขียนสถานการณ์ด้วยภาษาของตัวเองเอาไว้ก่อน ในทำนองว่าถ้ามีคำสั่งซื้อแบบนี้เข้ามา ระบบควรประมวลผลออกมาแบบนี้
อย่างที่สามคือการยับยั้งการเปลี่ยนสเปก การเปลี่ยนสเปกหลังเริ่มพัฒนาแล้วถูกยกให้เป็นสาเหตุอันดับหนึ่งของการใช้เวลาเกินกำหนดในสถิติที่จะกล่าวถึงภายหลังด้วย การจัดให้มีเวทีตัดสินความจำเป็นของการเปลี่ยนแปลงเป็นรายสัปดาห์ และกำหนดว่าการเปลี่ยนแปลงที่ไม่ผ่านเวทีนั้นจะไม่รับ จะทำให้การเดินงานมีเสถียรภาพ
เฟส 6 จะออกแบบการทดสอบและ UAT อย่างไร
การทดสอบแบ่งเป็นการทดสอบระดับหน่วยและระดับเชื่อมต่อที่ผู้ขายเป็นผู้ทำ และการทดสอบเพื่อยอมรับระบบหรือ UAT ที่ฝ่ายผู้ว่าจ้างเป็นผู้ทำ สิ่งที่ชี้ขาดความสำเร็จหรือล้มเหลวของโครงการคือ UAT
สิ่งที่ต้องหลีกเลี่ยงใน UAT คือการตรวจสอบด้วยข้อมูลตัวอย่างที่สะอาดเรียบร้อยเท่านั้น ในงานจริงจะเกิดกรณียกเว้นขึ้นเป็นประจำ เช่น คำสั่งซื้อที่จำนวนเปลี่ยนกลางทาง การคืนสินค้าที่คร่อมวันตัดรอบ และสต๊อกที่มีหน่วยนับต่างกัน หากไม่ใส่สิ่งเหล่านี้ไว้ในเคสทดสอบ ภายใน 1 สัปดาห์หลังขึ้นระบบจะมีรายงานเข้ามาว่ารูปแบบนี้ประมวลผลไม่ได้
เมื่อสร้างเคสทดสอบ การเรียงตามมุมมองต่อไปนี้จะช่วยลดการตกหล่น
- สถานการณ์พื้นฐานที่เดินกระแสงานปกติตั้งแต่ต้นจนจบ
- สถานการณ์ที่มีการแก้ไขหรือยกเลิกแทรกเข้ามากลางทาง
- ค่าขอบเขต เช่น จำนวนเป็นศูนย์ วันตัดรอบพอดี และจำนวนหลักสูงสุด
- การตรวจสอบว่าเนื้อข้อมูลที่ส่งไปเชื่อมต่อกับระบบอื่นถูกต้องหรือไม่
- ภาพที่ผู้ใช้เห็นเมื่อเข้าสู่ระบบด้วยสิทธิ์ที่ต่างกัน
การตัดสินผ่าน UAT ไม่ควรใช้จำนวนข้อบกพร่องที่ตรวจพบ แต่ควรใช้ว่ากระบวนการทำงานไหลตั้งแต่ต้นจนจบโดยไม่สะดุดหรือไม่ ถึงจะยังมีข้อบกพร่องหลงเหลือ แต่หากมีวิธีเลี่ยงและงานยังเดินได้ ก็ขึ้นระบบได้ ในทางกลับกัน ต่อให้ข้อบกพร่องเป็นศูนย์ แต่ถ้ากระบวนการทำงานไม่ไหล ก็ไม่ควรขึ้นระบบ

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

การเดินทางระยะสั้นของวิศวกรระบบชาวญี่ปุ่นกับข้อจำกัดด้านวีซ่าและใบอนุญาตทำงาน
การจัดการที่ส่งวิศวกรระบบชาวญี่ปุ่นจากสำนักงานใหญ่หรือจากผู้ขายในญี่ปุ่นมาทำงานกำหนดความต้องการและติดตั้งระบบ ดูเป็นเรื่องธรรมชาติ แต่ในระบบตรวจคนเข้าเมืองและใบอนุญาตทำงานของประเทศไทย อาจทำแบบนั้นตรง ๆ ไม่ได้
หากสรุปภาพรวมของกฎเกณฑ์จะได้ดังนี้ ผู้ถือหนังสือเดินทางธรรมดาของประเทศที่ได้รับการยกเว้นวีซ่าซึ่งรวมถึงญี่ปุ่น สามารถเดินทางเข้าประเทศได้โดยไม่ต้องมีวีซ่าสำหรับการพำนักในระยะเวลาที่กำหนด หากมีวัตถุประสงค์เพื่อการท่องเที่ยว การเจรจาธุรกิจ หรือการดูงาน นอกจากนี้ ตั้งแต่วันที่ 15 กรกฎาคม 2024 เป็นต้นมา มีการระบุแนวปฏิบัติว่าผู้ถือหนังสือเดินทางธรรมดาของ 93 ประเทศและดินแดนที่ได้รับการยกเว้นวีซ่าซึ่งรวมถึงญี่ปุ่น อาจเข้าข่ายได้รับการยกเว้นวีซ่าภายใต้เงื่อนไขบางประการแม้จะมีวัตถุประสงค์เพื่อการทำงาน หากพำนักไม่เกิน 15 วันต่อการเข้าเมืองหนึ่งครั้ง
แต่สิ่งสำคัญคือ หากรวมถึงการให้บริการภายในประเทศไทย การสนับสนุนทางเทคนิค งานติดตั้ง หรือการมีส่วนร่วมโดยตรงต่อการดำเนินงานของบริษัทในประเทศไทย สิ่งนั้นจะถือว่าเป็นการทำงาน กรณีที่มีการชี้แนะทางเทคนิคซึ่งมีค่าตอบแทน หรือมีการลงมือทำงานจริง รวมถึงกรณีที่ต้องพำนักเกิน 60 วัน จำเป็นต้องขอวีซ่าประเภทนอนอิมมิแกรนต์ นอกจากนี้ ตั้งแต่ปี 2025 เป็นต้นมา ยังมีการทยอยบังคับให้ผู้ที่เดินทางเข้าประเทศแบบยกเว้นวีซ่าต้องยื่นขอการอนุมัติเดินทางเข้าประเทศไทยทางอิเล็กทรอนิกส์ หรือ ETA ล่วงหน้าด้วย
ผลกระทบของกฎเกณฑ์นี้ต่อโครงการนั้นใหญ่กว่าที่คิด
- กรณีที่ให้วิศวกรระบบชาวญี่ปุ่นมาสัมภาษณ์เก็บความต้องการในพื้นที่ ขั้นตอนที่จำเป็นจะเปลี่ยนไปตามจำนวนวันพำนักและเนื้องาน การกำหนดวันไว้ก่อนจึงทำให้ดำเนินเรื่องไม่ทัน
- แนวทางที่ว่าจะเรียกตัวมาระยะสั้นเฉพาะตอนที่จำเป็นในช่วงว่างของเฟสพัฒนา จะไม่เป็นจริงหากไม่คำนวณระยะเวลารอของขั้นตอนการเดินทางเข้ามาด้วย
- การเข้าร่วมสังเกตการณ์ตอนขึ้นระบบจริงมักเป็นการพำนักที่ยาวที่สุด จึงต้องวางแผนโดยตั้งอยู่บนสมมติฐานว่าจะต้องมีใบอนุญาตทำงาน
ในทางปฏิบัติ วิธีรับมือที่ได้ผลคือเลือกผู้ขายที่มีวิศวกรระบบชาวญี่ปุ่นประจำอยู่ในประเทศไทย หรือแบ่งโครงสร้างทีมด้วยการจำกัดการมีส่วนร่วมของวิศวกรฝั่งญี่ปุ่นไว้ที่การทบทวนการออกแบบและการสนับสนุนทางออนไลน์ ส่วนงานลงมือทำจริงในพื้นที่ให้บุคลากรของนิติบุคคลในประเทศไทยเป็นผู้รับผิดชอบ
อนึ่ง เนื้อหาของกฎเกณฑ์ที่บันทึกไว้ตรงนี้เป็นข้อมูลที่ตรวจสอบได้ ณ เวลาที่เขียนบทความ และแนวปฏิบัติด้านตรวจคนเข้าเมืองกับใบอนุญาตทำงานอาจมีการเปลี่ยนแปลงได้ เมื่อจะวางแผนการเดินทางจริง กรุณาตรวจสอบกฎเกณฑ์ล่าสุดกับสถานทูตหรือผู้เชี่ยวชาญทุกครั้ง
ช่วงปิดบัญชีที่งานล้นมือในเดือนธันวาคมกับแผนการขึ้นระบบจริง
ในประเทศไทยมีนิติบุคคลจำนวนมากที่ปิดบัญชีในเดือนธันวาคม ทำให้เดือนธันวาคมกลายเป็นช่วงที่งานล้นมือ ทั้งสำนักงานบัญชีและสำนักงานสอบบัญชีต่างมีงานปิดบัญชีและงานตรวจสอบกระจุกตัวอยู่ ข้อเท็จจริงนี้ถูกชี้ไว้อย่างกว้างขวางในคำอธิบายด้านการปฏิบัติงานบัญชี
จากตรงนี้ไปไม่ใช่สิ่งที่เขียนไว้โดยตรงในแหล่งอ้างอิง แต่เป็นการอนุมานในเชิงการบริหารโครงการ ในทางปฏิบัติแล้ว การไม่เลือกเดือนธันวาคมเป็นช่วงขึ้นระบบจริงน่าจะปลอดภัยกว่า ด้วยเหตุผลดังนี้
ทันทีหลังขึ้นระบบจริง เป็นช่วงที่ข้อมูลเก่าและใหม่อยู่ปะปนกัน และมีการประมวลผลนอกความคาดหมายเกิดขึ้นต่อเนื่อง ในช่วงนี้จะมีสถานการณ์ที่ต้องขอคำวินิจฉัยจากฝ่ายบัญชีอยู่บ่อยครั้ง แต่เดือนธันวาคมกลับเป็นช่วงที่ฝ่ายบัญชีนั้นขยับตัวได้น้อยที่สุดเพราะติดงานปิดบัญชี ยิ่งถ้ามีงานรองรับการตรวจสอบซ้อนเข้ามา ก็ยังต้องตอบข้อซักถามจากสำนักงานบัญชีภายนอกอีก ส่วนฝั่งหน้างานเองก็แทบไม่เหลือกำลัง เพราะการจัดส่งกระจุกตัวช่วงปลายปีและการเร่งเคลียร์งานก่อนวันหยุดยาว
ด้วยเหตุผลเดียวกัน ช่วงก่อนและหลังเดือนปิดบัญชี เช่น ตั้งแต่ครึ่งหลังของเดือนพฤศจิกายนถึงเดือนมกราคมของปีถัดไป ก็คุ้มค่าที่จะจัดการอย่างระมัดระวัง การสลับระบบที่คร่อมรอบบัญชีมีข้อดีตรงที่เริ่มใช้ระบบใหม่ได้ตั้งแต่ต้นรอบบัญชี แต่ก็มาพร้อมความยากที่การปิดรอบบัญชีกับงานย้ายข้อมูลมาซ้อนกัน จะเลือกทางไหนขึ้นอยู่กับโครงสร้างทีมของฝ่ายบัญชีและปริมาณข้อมูลที่ต้องย้าย
วิธีดำเนินการเชิงปฏิบัติที่แนะนำคือ ในขั้นกำหนดความต้องการ ให้ขอปฏิทินจากฝ่ายบัญชี ระบายทับช่วงที่ขยับตัวไม่ได้ไว้ก่อน แล้วจึงลากหมุดหมายของโครงการโดยหลบช่วงเหล่านั้น หากลากตารางงานเสร็จแล้วค่อยไปปรึกษาฝ่ายบัญชี ส่วนใหญ่จะต้องกลับมาลากใหม่
จะตรวจสอบโครงสร้างทีมวิศวกรระบบชาวญี่ปุ่นของผู้ให้บริการในประเทศไทยอย่างไร
จำนวนวิศวกรระบบชาวญี่ปุ่นที่รองรับภาษาญี่ปุ่นได้ในผู้ให้บริการที่อยู่ในประเทศไทยนั้น เป็นทรัพยากรที่จำกัดไม่ว่าจะเป็นบริษัทใดก็ตาม ตัวอย่างโครงสร้างทีมที่ผู้ขายรายหนึ่งในประเทศไทยเปิดเผยไว้ ระบุว่ามีพนักงานชาวญี่ปุ่นประจำที่กรุงเทพจำนวน 7 คน และพนักงานชาวไทย 40 คน โดยรองรับได้ทั้งภาษาญี่ปุ่นและภาษาไทย นี่เป็นเพียงตัวอย่างของบริษัทเดียวและไม่ได้แสดงถึงมาตรฐานของอุตสาหกรรม แต่โครงสร้างที่บุคลากรชาวญี่ปุ่นเป็นเพียงส่วนหนึ่งของทั้งหมดนั้น เป็นสิ่งที่ผู้ให้บริการในประเทศไทยจำนวนมากมีร่วมกัน
โครงสร้างแบบนี้จะกลายเป็นปัญหาในเฟสกำหนดความต้องการ ความสามารถในการถ่ายทอดนัยของงานที่ผู้รับผิดชอบหน้างานเล่าเป็นภาษาญี่ปุ่นลงไปสู่การออกแบบได้ตรงตามนั้นหรือไม่ คือสิ่งที่กำหนดความแม่นยำของ Fit&Gap เมื่อผ่านล่าม ภาษาของงานจะถูกทำให้เป็นนามธรรมไปหนึ่งชั้น และรายละเอียดปลีกย่อยจะตกหล่น ส่วนที่ตกหล่นเป็นอันดับแรกคือสิ่งที่ว่าปกติทำประมาณนี้ หรือถ้าเป็นกรณียกเว้นจะทำแบบนี้ ซึ่งเป็นแหล่งเพาะช่องว่างโดยตรง
ดังนั้นในการคัดเลือกผู้ขาย เราจึงแนะนำให้ตรวจสอบ 3 ข้อต่อไปนี้ด้วยตัวเลข ข้อแรก มีวิศวกรระบบชาวญี่ปุ่นเข้าร่วมในเฟสกำหนดความต้องการกี่คน และด้วยอัตราการทำงานเท่าใด ข้อที่สอง บุคลากรชุดนั้นเป็นคนเดียวกับผู้รับผิดชอบในเฟสเสนองานหรือไม่ ข้อที่สาม ทีมที่รับคำถามภาษาญี่ปุ่นในงานบำรุงรักษาหลังขึ้นระบบมีกี่คน และรับในช่วงเวลาใด
คำตอบว่ารองรับภาษาญี่ปุ่นได้นั้น จะได้กลับมาจากผู้ขายแทบทุกราย สิ่งที่มีความหมายคืออัตราการทำงานและจำนวนคนที่อยู่ถัดจากคำตอบนั้น
ยังมีอีกมุมมองหนึ่งคือความยั่งยืนของโครงสร้างทีม ตามคำอธิบายเรื่องแนวโน้มด้านแรงงานในประเทศไทย ค่าจ้างของวิศวกร IT และโปรแกรมเมอร์ในประเทศไทยกำลังปรับขึ้นในระดับปีละ 8% ถึง 12% ซึ่งเป็นการเติบโตที่สูงกว่าอย่างชัดเจนเมื่อเทียบกับพนักงานทั่วไปที่ปีละ 3% ถึง 5% ช่วงเงินเดือนก็กว้างตั้งแต่ 35,000 บาท ถึง 80,000 บาท ซึ่งสะท้อนว่าเป็นตลาดที่บุคลากรมีการเคลื่อนย้ายสูง หากตั้งอยู่บนสมมติฐานว่าจะบำรุงรักษาระยะยาว ก็คุ้มค่าที่จะตรวจสอบว่าโครงสร้างทีมนั้นไม่ได้พึ่งพิงตัวบุคคลใดบุคคลหนึ่ง
จะใช้ Generative AI ในงานกำหนดความต้องการและการทดสอบได้อย่างไร
ในช่วงหลังเริ่มมีความเคลื่อนไหวที่นำ Generative AI เข้ามาใช้ในขั้นตอนกำหนดความต้องการ แม้จะยังพูดได้ยากว่าเป็นวิธีการที่ตกผลึกแล้ว แต่ก็คุ้มค่าที่จะรับรู้ไว้ในฐานะความเป็นไปได้
รูปแบบการใช้งานที่มีการนำเสนอมีอยู่ 2 แบบใหญ่ แบบแรกคือใช้ Generative AI เป็นผู้สัมภาษณ์เชิงสนทนา แล้วให้สร้างร่างต้นแบบของเอกสารกำหนดความต้องการขึ้นมาจากบทสนทนากับฝ่ายงาน ฝ่ายงานนั้นคุ้นเคยกับการเล่าเรื่องงานของตัวเอง แต่ไม่คุ้นเคยกับการเรียบเรียงสิ่งนั้นให้อยู่ในรูปของความต้องการ แนวคิดคือใช้ AI ช่วยในการแปลงรูปตรงนั้น
อีกแบบหนึ่งคือการใช้ในขั้นตอนการทบทวน โดยกำหนดมาตรฐานของมุมมองที่ต้องตรวจสอบไว้ล่วงหน้า แล้วให้ Generative AI อ่านเอกสารกำหนดความต้องการเพื่อดึงจุดที่ระบุไว้ไม่ครบ และความขัดแย้งระหว่างข้อความต่าง ๆ ออกมา ซึ่งน่าจะเข้ากันได้ดีกับการตรวจความสอดคล้องภายในเอกสารที่มนุษย์มักมองข้าม
ในทางกลับกัน ก็มีการชี้ปัญหาไว้อย่างชัดเจนเช่นกัน คือผลลัพธ์ของ Generative AI มีความไม่แน่นอน และหากนำไปใช้ตามที่ได้มาโดยตรง อาจเกิดความคลาดเคลื่อนระหว่างสิ่งที่ผู้พัฒนาคาดคิดกับความต้องการจริงของหน้างาน เอกสารกำหนดความต้องการที่ถูกสร้างขึ้นมานั้นเป็นเพียงร่างเท่านั้น ไม่ใช่สิ่งที่ใช้แทนการตรวจยืนยันโดยฝ่ายงานและการทดสอบด้วยหน้าจอจริงได้
สำหรับขั้นตอนการทดสอบ ทิศทางที่พอนึกออกคือการใช้สร้างเคสทดสอบ โดยให้ไล่รายการชุดค่าอินพุตที่คาดว่าจะเกิดขึ้นจากเอกสารกำหนดความต้องการและเอกสารออกแบบ แล้วให้มนุษย์ใช้ความรู้ด้านกระบวนการทำงานคัดเลือกเอาไว้หรือตัดออก แต่วิธีนี้ก็เช่นกัน เพราะรายการที่ครอบคลุมซึ่งถูกสร้างขึ้นมานั้นไม่จำเป็นต้องสะท้อนระดับความสำคัญในกระบวนการทำงานของบริษัทเรา การจัดลำดับความสำคัญจึงยังต้องให้คนเป็นผู้ทำ
ในเวลานี้ การมองว่าเป็นเครื่องมือสำหรับสร้างร่างต้นแบบของการกำหนดความต้องการและการทดสอบให้เร็วขึ้น ไม่ใช่สิ่งที่มาแทนการตัดสินใจ น่าจะเป็นการวางตำแหน่งที่เหมาะสม
ความล้มเหลวที่พบบ่อยและวิธีป้องกัน
การที่โครงการนำระบบมาใช้จบลงไม่ตรงตามที่คาดหวังนั้นไม่ใช่เรื่องแปลกเลย ในผลสำรวจสภาพจริงของโครงการ IT ประจำปี 2018 ซึ่ง Nikkei Computer จัดทำขึ้นในรอบ 10 ปี และรายงานเมื่อวันที่ 27 กุมภาพันธ์ 2018 พบว่าจากโครงการนำระบบมาใช้และปรับปรุงระบบจำนวน 1,745 โครงการ มีถึง 47.2% ที่ถูกตัดสินว่าล้มเหลว เป็นตัวเลขที่บอกว่าเกือบครึ่งหนึ่งไปไม่ถึงผลลัพธ์ที่คาดหวัง
รายละเอียดที่ผลสำรวจนี้แสดงออกมา สอดคล้องอย่างแม่นยำกับโครงสร้างเฟสที่อธิบายมาทั้งหมด
| ผลที่สังเกตได้ | เหตุผลอันดับหนึ่ง | เฟสที่เกี่ยวข้อง |
|---|---|---|
| ไม่ได้รับความพึงพอใจ | การกำหนดความต้องการไม่เพียงพอ | เฟส 1 และเฟส 4 |
| ค่าใช้จ่ายเกินงบ | เกิดงานพัฒนาเพิ่มเติม | เฟส 4 และเฟส 5 |
| ใช้เวลาเกินกำหนด | มีการเปลี่ยนสเปกของระบบต่อเนื่อง | เฟส 5 |
การที่เหตุผลอันดับหนึ่งของการไม่ได้รับความพึงพอใจคือการกำหนดความต้องการไม่เพียงพอ คือเหตุผลโดยตรงที่บทความนี้ให้น้ำหนักกับเฟส 1 และเฟส 4 มากเป็นพิเศษ การที่อันดับหนึ่งของค่าใช้จ่ายเกินงบคือการเกิดงานพัฒนาเพิ่มเติม ยืนยันว่าการตัดสินใจเรื่องส่วนเสริมในการวิเคราะห์ Fit&Gap เป็นตัวการหลักของค่าใช้จ่าย ส่วนการที่อันดับหนึ่งของการใช้เวลาเกินกำหนดคือการเปลี่ยนสเปกของระบบต่อเนื่อง ก็แสดงถึงความสำคัญของการบริหารการเปลี่ยนแปลงหลังเข้าสู่เฟสพัฒนาแล้ว
ในผลสำรวจเดียวกันยังมีการชี้ประเด็นสำคัญอีกข้อหนึ่ง คือบริษัทที่ผู้บริหารและฝ่ายงานโยนทุกอย่างให้ผู้ขาย IT ไปทำนั้นทำให้โครงการสำเร็จได้ยาก โดยระบุว่าจำเป็นที่คนซึ่งรับผิดชอบกระบวนการทำงานต้องเข้าร่วมโครงการ รวบรวมความต้องการ และเฝ้าติดตามความคืบหน้า
ในฐานะข้อมูลเสริม บทความที่แนะนำรายงานผลสำรวจแนวโน้ม IT ขององค์กรประจำปี 2021 ได้แสดงข้อมูลว่า ขึ้นอยู่กับขนาดของโครงการ จะมี 67% ถึง 85% ที่ตารางงานล่าช้า และ 60% ถึง 85% ที่ใช้งบเกิน แม้ช่วงตัวเลขจะแตกต่างกันไปตามขนาด แต่ประเด็นที่ว่าไม่ว่าจะระดับใดก็มีโครงการเกินกว่าครึ่งที่ประสบทั้งความล่าช้าและการใช้งบเกิน คือสมมติฐานที่ควรเผื่อไว้ตั้งแต่ตอนวางแผน
หากจัดระเบียบวิธีป้องกันโดยอิงจากสิ่งเหล่านี้เป็นรายเฟส จะได้ดังนี้
- ให้ผู้รับผิดชอบของฝ่ายงานเข้าร่วมการกำหนดความต้องการทุกครั้ง หากเดินหน้าด้วยผู้ดูแลระบบสารสนเทศเพียงฝ่ายเดียว จะได้ความต้องการที่หน้างานไม่รู้จัก
- อย่าขยายขอบเขตกว้างเกินไปตั้งแต่แรก หากเอาทุกโรงงานและทุกกระบวนการทำงานมาเป็นเป้าหมายพร้อมกัน ทั้งปริมาณความต้องการและจำนวนผู้เกี่ยวข้องจะพุ่งขึ้นทันที จนรักษาคุณภาพของการกำหนดความต้องการได้ยาก การเริ่มจาก 1 ฐานการผลิตและ 1 กระบวนการทำงาน แล้วค่อยขยายออกไป เป็นทางเลือกที่สมจริงในการกระจายภาระนี้
- แปลงผลการวิเคราะห์ Fit&Gap เป็นค่าใช้จ่ายและระยะเวลาก่อน แล้วจึงตัดสินแนวทางรับมือ ลำพังรายการจำนวนส่วนเสริมอย่างเดียวตัดสินใจไม่ได้
- กำหนดขั้นตอนการอนุมัติสำหรับการเปลี่ยนสเปกหลังเริ่มพัฒนา เป้าหมายไม่ใช่การห้ามเปลี่ยนแปลง แต่คือการทำให้มองเห็นได้
- เขียนเกณฑ์การตัดสินความพร้อมขึ้นระบบเป็นลายลักษณ์อักษรก่อนเริ่ม UAT
การวิเคราะห์สาเหตุความล้มเหลวอย่างละเอียดกว่านี้ และรูปแบบที่เกิดขึ้นจริงบ่อย ๆ เราแยกอธิบายไว้ใน สาเหตุที่การนำระบบบริหารการผลิตมาใช้ล้มเหลวและแนวทางรับมือ
คำถามที่พบบ่อย
การนำระบบบริหารการผลิตมาใช้ต้องใช้เวลานานแค่ไหน
เนื่องจากเปลี่ยนแปลงได้มากตามขอบเขตงานและความซับซ้อนของกระบวนการ จึงยากที่จะระบุตัวเลขคร่าวเพียงตัวเดียว สถิติที่น่าเชื่อถือซึ่งระบุระยะเวลามาตรฐานของแต่ละเฟส ก็ยังไม่พบในข้อมูลที่เปิดเผยต่อสาธารณะ อย่างไรก็ตาม มีหลายกรณีที่ว่ากันว่าลำพังการกำหนดความต้องการก็ต้องใช้เวลาประมาณ 3 เดือน และเมื่อคิดว่าจากนั้นยังต้องมีการคัดเลือกผู้ขาย การออกแบบ การพัฒนา การทดสอบ และการย้ายข้อมูลต่อไปอีก ก็ต้องเผื่อระยะเวลาไว้ตามสมควร หากผู้ขายเสนอระยะเวลาที่สั้น กรุณาตรวจสอบว่าในระยะเวลานั้นรวมอะไรไว้บ้างและไม่รวมอะไรบ้าง ไม่ใช่เรื่องแปลกที่ใบเสนอราคาจะตั้งอยู่บนสมมติฐานว่าฝ่ายผู้ว่าจ้างทำการกำหนดความต้องการเสร็จแล้ว
ก้าวแรกของการนำระบบมาใช้ควรเริ่มจากอะไร
อย่าเริ่มจากการรวบรวมเอกสารผลิตภัณฑ์ แต่ให้เริ่มจากการทำให้งานปัจจุบันมองเห็นได้ นั่นคืองานเขียนกระแสข้อมูลตั้งแต่รับคำสั่งซื้อจนถึงจัดส่งออกมาเป็นรายแผนก ในขั้นนี้มักพบข้อเท็จจริงว่าไม่มีใครในบริษัทที่เห็นภาพรวมทั้งหมด จากนั้นให้ไล่รายการว่าสภาพปัจจุบันที่มองเห็นแล้วนั้นมีจุดใดที่กำลังลำบาก แล้วคัดเลือกว่าจุดใดควรแก้ด้วยระบบ หากทำถึงตรงนี้ภายในองค์กรได้ คุณภาพของการสนทนากับผู้ขายจะเปลี่ยนไปอย่างมาก
ควรยอมรับการปรับแต่งแพ็กเกจได้ถึงระดับไหน
เกณฑ์ตัดสินเชิงปฏิบัติคือการตั้งคำถามเป็นรายกรณีว่า วิธีทำงานนั้นเกี่ยวข้องกับความสามารถในการแข่งขันของบริษัทเราหรือไม่ สิ่งที่เกี่ยวข้องน้อยยังมีช่องให้ปรับเข้าหาฟังก์ชันมาตรฐาน ส่วนสิ่งที่เกี่ยวข้องมากคือช่องว่างที่ควรลงทุน อย่างไรก็ตาม ที่ฐานการผลิตในประเทศไทยมีช่องว่างที่เลี่ยงด้วยการปฏิบัติงานไม่ได้ เช่น ข้อกำหนดด้านภาษีของไทยและรูปแบบเอกสารที่คู่ค้าเรียกร้อง ควรแยกสิ่งเหล่านี้ออกมาตั้งแต่ต้นในฐานะส่วนเสริมที่จำเป็นต้องมี แล้วจัดการแยกจากการพิจารณาการปรับแต่งแบบไม่บังคับ จะช่วยให้เป็นระเบียบขึ้น และกรุณารวมประเด็นที่ว่ายิ่งเพิ่มการปรับแต่งมากเท่าใด ภาระการแก้ไขตอนอัปเกรดเวอร์ชันในอนาคตก็ยิ่งพอกพูนขึ้น ไว้ในวัตถุดิบสำหรับการตัดสินใจด้วย
ควรเลือกช่วงเวลาใดในการขึ้นระบบจริง
ในประเทศไทยมีนิติบุคคลจำนวนมากที่ปิดบัญชีในเดือนธันวาคม ทำให้เดือนธันวาคมเป็นช่วงที่งานล้นมือ ทั้งสำนักงานบัญชีและสำนักงานสอบบัญชีต่างมีงานปิดบัญชีและงานตรวจสอบกระจุกตัวอยู่ เนื่องจากทันทีหลังขึ้นระบบจริงจะมีสถานการณ์ที่ต้องขอคำวินิจฉัยจากฝ่ายบัญชีเกิดขึ้นบ่อยครั้ง ในทางปฏิบัติจึงมองว่าการไม่เลือกเดือนธันวาคมเป็นช่วงขึ้นระบบจริงน่าจะปลอดภัยกว่า ช่วงก่อนและหลังเดือนปิดบัญชีก็คุ้มค่าที่จะจัดการอย่างระมัดระวังเช่นกัน วิธีที่สมจริงคือในขั้นกำหนดความต้องการ ให้สอบถามช่วงที่ขยับตัวไม่ได้จากฝ่ายบัญชีไว้ก่อน แล้วลากหมุดหมายโดยหลบช่วงเหล่านั้น
ส่งวิศวกรระบบของบริษัทเราจากญี่ปุ่นมาทำงานติดตั้งระบบได้หรือไม่
ขั้นตอนที่จำเป็นจะเปลี่ยนไปตามจำนวนวันพำนักและเนื้องาน หากเป็นการดูงานหรือการเจรจาธุรกิจ อาจเข้าประเทศได้ภายใต้กรอบการยกเว้นวีซ่า แต่การสนับสนุนทางเทคนิคและงานติดตั้งภายในประเทศไทย รวมถึงการมีส่วนร่วมโดยตรงต่อการดำเนินงานของบริษัทในประเทศไทย จะถือว่าเป็นการทำงาน กรณีที่มีการลงมือทำงานจริงซึ่งมีค่าตอบแทน หรือกรณีที่ต้องพำนักเกิน 60 วัน จำเป็นต้องขอวีซ่าประเภทนอนอิมมิแกรนต์ และตั้งแต่ปี 2025 เป็นต้นมา ยังมีการทยอยบังคับให้ผู้ที่เดินทางเข้าประเทศแบบยกเว้นวีซ่าต้องยื่นขอการอนุมัติเดินทางเข้าประเทศไทยทางอิเล็กทรอนิกส์ หรือ ETA ล่วงหน้าด้วย เนื่องจากกฎเกณฑ์อาจเปลี่ยนแปลงได้ กรุณาตรวจสอบแนวปฏิบัติล่าสุดก่อนวางแผนการเดินทาง หากกำหนดวันไว้ก่อน อาจดำเนินเรื่องไม่ทัน
ถ้าในบริษัทไม่มีผู้ดูแลด้าน IT จะนำระบบมาใช้ได้หรือไม่
ทำได้ แต่มีข้อตั้งต้นว่าผู้รับผิดชอบฝั่งกระบวนการทำงานต้องเข้ามามีส่วนร่วมอย่างเป็นตัวหลักในการกำหนดความต้องการและการวิเคราะห์ Fit&Gap ในผลสำรวจของ Nikkei Computer ก็ชี้ไว้ว่าบริษัทที่ผู้บริหารและฝ่ายงานโยนทุกอย่างให้ผู้ขาย IT ไปทำนั้นทำให้โครงการสำเร็จได้ยาก ส่วนที่เป็นเรื่องเทคนิคมอบให้ผู้ขายได้ แต่การตัดสินว่ากระบวนการทำงานของบริษัทเราควรเป็นอย่างไรนั้นจ้างข้างนอกทำแทนไม่ได้ สิ่งที่ชดเชยการไม่มีผู้ดูแลด้าน IT คือการเข้าร่วมของคนที่รู้จักงานดีที่สุด
สรุป
การนำระบบบริหารการผลิตมาใช้ดำเนินไปด้วย 9 เฟส ได้แก่ การกำหนดความต้องการ การคัดเลือกผู้ขาย การทำสัญญา การออกแบบและวิเคราะห์ Fit&Gap การพัฒนาและปรับแต่ง การทดสอบและ UAT การย้ายข้อมูล การขึ้นระบบจริง และการทำให้ยั่งยืน สิ่งที่ปริมาณงานและความสนใจมักไปกระจุกอยู่คือการคัดเลือกผลิตภัณฑ์ แต่สิ่งที่สถิติความล้มเหลวบอกเราคือข้อเท็จจริงว่า ตัวกำหนดความพึงพอใจคือคุณภาพของการกำหนดความต้องการ ตัวกำหนดค่าใช้จ่ายคือการตัดสินใจเรื่องส่วนเสริมในการวิเคราะห์ Fit&Gap และตัวกำหนดระยะเวลาคือการเปลี่ยนสเปกหลังเริ่มพัฒนา
และที่ฐานการผลิตในอาเซียน จะมีข้อจำกัดเพิ่มเข้ามาอีก 3 ข้อ ข้อแรก การเดินทางของวิศวกรระบบชาวญี่ปุ่นเกี่ยวข้องกับระบบตรวจคนเข้าเมืองและใบอนุญาตทำงาน จึงกำหนดวันไว้ก่อนไม่ได้ ข้อที่สอง เดือนธันวาคมตรงกับช่วงปิดบัญชีที่งานล้นมือ การกำหนดช่วงขึ้นระบบจริงโดยคำนวณย้อนกลับจากปฏิทินของฝ่ายบัญชีจึงน่าจะปลอดภัยกว่า ข้อที่สาม บุคลากรที่รองรับภาษาญี่ปุ่นของผู้ให้บริการในประเทศไทยเป็นทรัพยากรที่จำกัด ระดับการมีส่วนร่วมในการกำหนดความต้องการจึงควรตรวจสอบเป็นตัวเลขก่อนเซ็นสัญญา ทั้ง 3 ข้อนี้คือจุดที่โครงการซึ่งยกวิธีเดินงานแบบในญี่ปุ่นมาใช้ตรง ๆ แทบจะสะดุดทุกราย
พูดกลับกันก็คือ หากเข้าใจกระแสของ 9 เฟสนี้และข้อจำกัด 3 ข้อไว้ตั้งแต่แรก ความชัดเจนของโครงการจะดีขึ้นอย่างมาก ก้าวแรกไม่ใช่การรวบรวมเอกสารผลิตภัณฑ์ แต่คือการเขียนสภาพงานปัจจุบันของบริษัทเราออกมา
TOMAS TECH มีฐานอยู่ที่กรุงเทพ และให้การสนับสนุนการนำระบบบริหารการผลิต PEGASUS ไปใช้กับผู้ผลิตสัญชาติญี่ปุ่นในประเทศไทยและอาเซียน ประเด็นอย่างวิธีดำเนินการกำหนดความต้องการ ขอบเขตที่ฟังก์ชันมาตรฐานจะดูดซับได้ในการวิเคราะห์ Fit&Gap โครงสร้างการมีส่วนร่วมของวิศวกรระบบชาวญี่ปุ่น และการออกแบบช่วงเวลาขึ้นระบบจริง ล้วนคุ้มค่าที่จะจัดระเบียบตั้งแต่ขั้นพิจารณาก่อนตัดสินใจเลือกผลิตภัณฑ์ แม้จะยังอยู่ในขั้นที่ยังไม่ได้ตัดสินใจว่าจะนำระบบมาใช้หรือไม่ เราก็ยินดีรับฟังปัญหาปัจจุบันและร่วมคิดวิธีดำเนินการไปด้วยกัน ปรึกษาเราได้ที่ แบบฟอร์มติดต่อสอบถาม
ข้อมูลอ้างอิง
- 生産管理システム導入の流れ|キッセイコムテック
- ITプロジェクト実態調査2018|日経クロステック
- 企業IT動向調査報告書2021の紹介記事|Promapedia
- タイ出張でビザは必要か|BORDER
- タイのERP・販売管理・生産管理システム|SMRI
- タイの会計の決算時期について|東京コンサルティンググループ
- 生成AIを活用した要件定義書作成・レビュー高度化のポイント|KPMGジャパン
- 中小企業のDXに関する調査結果|創業手帳
- 2026年版ものづくり白書 5分で掴む最重要ポイント|テクノア
- ものづくり白書2026を読み解く|BrainPad DOORS
- 2026年最新版タイ労務・タイ労務管理の最新動向|東京コンサルティンググループ