ระบบจัดการรีเวิร์กในโรงงาน: แนวทางติดตั้งและตรวจรับในไทย

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

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

รีเวิร์ค (Rework) คือการดำเนินการเพิ่มเติมกับผลิตภัณฑ์หรือชิ้นงานที่ไม่เป็นไปตามข้อกำหนด เพื่อให้กลับมาสอดคล้องกับข้อกำหนดที่กำหนดไว้ ต้องแยกรีเวิร์คออกจากการซ่อมแซม (Repair) ที่อาจไม่คืนสู่ข้อกำหนดเดิม, การอนุมัติใช้แบบมีเงื่อนไข (Concession/Use-as-is) ที่อนุญาตให้ใช้หรือจัดส่งโดยรับรู้ข้อบกพร่อง, และการทำลาย (Scrap) ซึ่งห้ามนำกลับมาใช้จริง ชื่อเรียกในแต่ละบริษัทหรือมาตรฐานอุตสาหกรรมอาจต่างกัน ดังนั้นในการกำหนดความต้องการควรระบุให้ชัดว่าหลังดำเนินการแล้วต้องสอดคล้องกับข้อกำหนดใด และใครเป็นผู้อนุมัติ

หากเพียงแค่บันทึกข้อบกพร่อง ระบบ QMS (Quality Management System) อาจเพียงพอ แต่การเคลื่อนย้ายชิ้นงาน การนำกลับเข้าสู่ไลน์ผลิต การบันทึกชิ้นส่วนและแรงงาน การตรวจสอบซ้ำ และการคืนสถานะสต็อกให้ครบวงจรนั้น QMS อาจไม่ครอบคลุม ในทางกลับกัน MES (Manufacturing Execution System) ที่บันทึกผลการรีเวิร์คได้ อาจขาดการอนุมัติจากฝ่ายคุณภาพหรือจากลูกค้า จุดสำคัญของการนำระบบคือ “ไม่ใช่เพิ่มระบบใหม่” แต่ต้องตัดสินใจว่า QMS, MES, ERP, WMS ระบบใดเป็นแหล่งข้อมูลหลัก และแต่ละสถานะจะส่งข้อมูลไปยังระบบใด

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

สิ่งแรกที่ต้องกำหนด: “ขอบเขต” และ “หน่วยการแยกกัก”

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

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

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

ระบบจัดการรีเวิร์กในโรงงาน: แนวทางติดตั้งและตรวจรับในไทย - figure 1

ออกแบบการเปลี่ยนสถานะตั้งแต่พบข้อบกพร่องจนคืนสต็อก

สถานะขั้นต่ำที่ควรมี ได้แก่ ①ตรวจพบ, ②แยกกัก, ③รอพิจารณาวิธีดำเนินการ, ④อนุมัติรีเวิร์ค, ⑤กำลังรีเวิร์ค, ⑥รอตรวจสอบซ้ำ, ⑦ผ่านการตรวจสอบซ้ำ, ⑧พร้อมจัดส่ง ส่วนสถานะไม่ผ่าน, ทำลาย, อนุมัติใช้แบบมีเงื่อนไข, คืนซัพพลายเออร์, รอลูกค้าอนุมัติ เป็นทางแยก ไม่จำเป็นต้องใช้ชื่อเดียวกันทุกบริษัท แต่ต้องกำหนดให้ชัดว่า “ใคร”, “บนพื้นฐานข้อมูลใด”, “สามารถเปลี่ยนไปสถานะถัดไปได้” มิฉะนั้นจะกลายเป็นแค่ช่องสถานะ

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

เมื่อย้ายไปสถานะแยกกัก ต้องตรวจสอบรหัสชิ้นงานกับรหัสสต็อก และยืนยันว่าจำนวนดังกล่าวถูกตัดออกจากสต็อกที่พร้อมใช้งาน หากเวลาการอัปเดตใน ERP, WMS, MES ไม่ตรงกัน ต้องกำหนดให้ชัดว่าสถานะแยกกักของระบบใดเป็นเกตสุดท้ายที่ห้ามจัดส่ง หากการเชื่อมต่อขัดข้องและข้อมูลไม่ถึงปลายทาง ต้องไม่แสดงว่า “แยกกักแล้ว” แต่ต้องค้างไว้ในคิวข้อยกเว้น ต้องมีการจัดการ event ID และ idempotency เพื่อป้องกันการลดจำนวนซ้ำซ้อนจากการส่งซ้ำ

ในการพิจารณาวิธีดำเนินการ ต้องกำหนดบทบาทของฝ่ายคุณภาพ, วิศวกรรมการผลิต, ฝ่ายผลิต, และลูกค้า (ถ้ามี) ห้ามใช้ปุ่มเดียวกันในการอนุมัติรีเวิร์คมาตรฐานกับการดำเนินการพิเศษที่ไม่มีขั้นตอนมาตรฐาน หากเป็นอุตสาหกรรมยานยนต์ที่มีข้อกำหนดลูกค้าเฉพาะ อาจต้องขออนุมัติล่วงหน้าสำหรับรีเวิร์คที่ไม่ได้วางแผนไว้ เช่น ข้อกำหนดลูกค้า Stellantis ระบุให้รีเวิร์คที่วางแผนไว้ต้องรวมใน flow, FMEA, control plan และรีเวิร์คที่ไม่ได้วางแผนต้องขออนุมัติล่วงหน้า อย่างไรก็ตาม อย่านำข้อกำหนดนี้ไปใช้กับผลิตภัณฑ์อื่นโดยไม่ตรวจสอบสัญญา

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

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

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

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

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

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

การแบ่งหน้าที่ของ QMS, MES, ERP, WMS

QMS มักใช้สำหรับรายงานข้อบกพร่อง, วิเคราะห์สาเหตุ, ตัดสินใจดำเนินการ, อนุมัติ, และการแก้ไข MES มักใช้สำหรับเส้นทางกระบวนการ, ผลงาน, การนำกลับเข้าไลน์, และการตรวจสอบซ้ำ ERP ใช้สำหรับใบสั่งผลิต, รหัสสินค้า, ต้นทุน, บัญชี, ประเมินสต็อก WMS ใช้สำหรับที่เก็บ, การเคลื่อนย้าย, และการห้ามหยิบสินค้า แต่ขอบเขตเหล่านี้ต่างกันในแต่ละผลิตภัณฑ์ อย่าตัดสินใจจากชื่อระบบ ให้สร้าง “แมทริกซ์ความรับผิดชอบ” ระบุแหล่งข้อมูลหลักในแต่ละข้อมูล

เหตุการณ์ขั้นต่ำที่แนะนำ ได้แก่ NONCONFORMANCE_OPENED, HOLD_APPLIED, DISPOSITION_APPROVED, REWORK_STARTED, REWORK_COMPLETED, REINSPECTION_PASSED, RELEASE_APPROVED ชื่อเรียกเป็นตัวอย่างแนวคิด ต้องมี event ID, ชิ้นงานเป้าหมาย, จำนวน, เวลา, ผู้ดำเนินการ, เวอร์ชันอนุมัติ, แหล่งข้อมูล, และเหตุการณ์ก่อนหน้าที่เกี่ยวข้อง เพื่อป้องกันการอัปเดตซ้ำซ้อนเมื่อระบบต่างกันรับเหตุการณ์เดียวกัน

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

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

ระบบจัดการรีเวิร์กในโรงงาน: แนวทางติดตั้งและตรวจรับในไทย - figure 2

การออกแบบการตรวจสอบย้อนกลับและการแบ่งล็อต

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

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

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

วิธีประเมินต้นทุนและผลตอบแทนจากการนำระบบ

ต้นทุนของระบบรีเวิร์คไม่ได้ขึ้นกับจำนวนหน้าจอเพียงอย่างเดียว ต้องตรวจสอบก่อนว่า QMS, MES, ERP, WMS เดิมใช้งานได้ถึงจุดใด แล้วแยกฟังก์ชันที่ต้องเพิ่ม ในใบเสนอราคาต้องรวมความละเอียดของรหัสชิ้นงาน, อุปกรณ์ปลายทาง/สแกนเนอร์/ฉลาก, หลายไซต์และหลายภาษา, flow การอนุมัติ, การแยกเส้นทางกระบวนการ, การย้ายข้อมูล, อินเทอร์เฟซ, การทำงานออฟไลน์, log การตรวจสอบ, การบำรุงรักษาและอบรม ราคาขึ้นกับสภาพแวดล้อมและเงื่อนไขสัญญา จึงไม่ระบุราคาเฉลี่ยที่ไม่มีที่มารองรับ

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

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

ฟังก์ชันและข้อมูลที่ควรระบุใน RFP

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

ในตารางฟังก์ชันควรมี ①การระบุชิ้นงาน/ล็อต/จำนวน, ②การแยกกักและห้ามจัดส่ง, ③ประเภทการดำเนินการ, ④สิทธิ์อนุมัติ, ⑤เวอร์ชันขั้นตอน, ⑥วัสดุและแรงงานที่ใช้, ⑦แผนการตรวจสอบซ้ำ, ⑧สิทธิ์ปล่อย, ⑨การซิงค์สต็อกกับ ERP/WMS, ⑩การค้นหาและ log การตรวจสอบ แต่ละรายการให้ระบุว่า “ฟังก์ชันมาตรฐาน”, “ตั้งค่าได้”, “ต้องพัฒนาเพิ่ม”, “ไม่รองรับ” และขอหลักฐานแสดงในเดโม การมีเครื่องหมายในสเปคอย่างเดียวไม่พอสำหรับตัดสินใจ

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

การเปรียบเทียบผู้ขายอย่าดูแค่ราคา ต้องทดสอบกับข้อมูลจริงว่าการอนุมัติและการควบคุมชิ้นงานทำงานร่วมกันได้หรือไม่ แม้ฟังก์ชันของผลิตภัณฑ์เดิมจะไม่ครบ อาจแก้ไขด้วยการเพิ่ม workflow หรือ event รอบข้างมากกว่าการแก้ไข core product อย่างลึก แต่ยิ่งเพิ่มขอบเขตมาก ความรับผิดชอบเมื่อเกิดปัญหาจะซับซ้อน ต้องตกลงแบ่งหน้าที่ระหว่างบริษัทผู้ติดตั้ง, ผู้ปฏิบัติงาน, และผู้รับผิดชอบคุณภาพก่อนเซ็นสัญญา

เกณฑ์การรับมอบใน PoC, FAT, SAT

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

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

ในการทดสอบ SAT ให้ใช้เครื่องปลายทาง, บาร์โค้ด, ฉลาก, ไร้สาย, การปฏิบัติงานกับอุปกรณ์, ที่เก็บจริง, หน้าจอหลายภาษา (ไทย/ญี่ปุ่น) ตรวจสอบกรณีที่หน้าจอแสดงแยกกักแต่ไม่มีป้ายที่ชิ้นงาน หรือชิ้นงานแยกกักแต่ ERP ยังจองสต็อกได้ ตั้งใจสร้างความคลาดเคลื่อนเพื่อดูว่าใครสังเกตเห็นและแก้ไขอย่างไร อย่าเปิดเกตปล่อยสินค้าจริงเพียงเพราะทดสอบผ่านกับข้อมูลตัวอย่าง

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

ระบบจัดการรีเวิร์กในโรงงาน: แนวทางติดตั้งและตรวจรับในไทย - figure 3

ข้อผิดพลาดที่พบบ่อยและวิธีป้องกัน

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

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

ลำดับการนำระบบและการจัดทีมในโรงงานไทย

หากสำนักงานใหญ่กำหนดขั้นตอนคุณภาพและโรงงานไทยดูแลชิ้นงานจริง ความแตกต่างของภาษามีผลมากกว่าแค่การแสดงผล หากแต่ละฝ่ายใช้ “hold”, “rework”, “repair”, “concession”, “release” ต่างความหมาย จะรายงานสถานะเดียวกันเป็นคนละกรณี ต้องจัดทำ glossary ไทย-อังกฤษ-ญี่ปุ่น พร้อมตารางเงื่อนไขเข้า-ออกแต่ละสถานะให้เห็นชัด หน้าจอหน้างานใช้คำสั้นได้ แต่คำอธิบายสำหรับผู้อนุมัติต้องครบถ้วน

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

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

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

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

Dashboard อย่าดูแค่ “อัตราข้อบกพร่อง”

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

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

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

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

เอกสารที่ควรมอบให้เมื่อส่งมอบระบบ

หากขอแค่รายชื่อหน้าจอจากผู้ขาย ผู้รับช่วงต่อจะไม่เข้าใจสถานะและความรับผิดชอบ ต้องมีอย่างน้อย diagram การเปลี่ยนสถานะ, ตารางสิทธิ์, กฎรหัสชิ้นงาน, ตารางแหล่งข้อมูลหลัก, รายการ event ระหว่างระบบ, วิธีฟื้นฟูเมื่อเชื่อมโยงล้มเหลว, การจัดการเวอร์ชันแผนตรวจสอบ, นโยบาย log, คำตอบ RFP, ผล FAT/SAT การกำหนดระยะเวลาจัดเก็บขึ้นกับกฎหมายหรือสัญญาในแต่ละผลิตภัณฑ์ ฝ่ายคุณภาพ/กฎหมายต้องกำหนดระยะเวลา ระบบต้องตั้งค่าและดึงข้อมูลได้

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

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

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

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

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

ขึ้นกับฟังก์ชัน QMS/MES/ERP/WMS เดิม, จำนวนการเชื่อมโยง, ความละเอียดของรหัสชิ้นงาน, สิทธิ์อนุมัติและข้อกำหนดลูกค้า, อุปกรณ์ปลายทาง/ฉลาก, หลายภาษา, การทำงานออฟไลน์ ควรเลือก flow ปัจจุบันหนึ่งรายการและขอใบเสนอราคาที่แยกฟังก์ชันและการเชื่อมโยงที่ต้องเพิ่ม อย่าดูแค่ราคา ต้องเปรียบเทียบขอบเขตการย้ายข้อมูลและการจัดการข้อยกเว้น

เริ่มจาก Excel บันทึกข้อบกพร่องได้หรือไม่

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

หลังรีเวิร์คควรเปลี่ยนเลขล็อตหรือไม่

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

ควรปรับ QMS หรือ MES ก่อน

หากขาดประวัติการอนุมัติข้อบกพร่องให้ปรับ QMS ก่อน หากติดตามการนำกลับเข้าไลน์และผลงานไม่ได้ให้ปรับ MES ก่อน หากห้ามจัดส่งไม่ได้ให้ปรับ ERP/WMS ก่อน ให้ติดตามกรณีข้อบกพร่องจริงและเริ่มจากจุดที่ควบคุมไม่ได้ อย่ากำหนดลำดับระบบตายตัวตั้งแต่แรกเพื่อหลีกเลี่ยงการกรอกข้อมูลซ้ำ

สรุป

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

หากต้องการจัดระเบียบขอบเขต QMS, MES, ERP, WMS หรือเส้นทางอนุมัติรีเวิร์คในโรงงานไทย สามารถ ปรึกษา TOMAS TECH ได้ โดยจะช่วยพิจารณาขอบเขตขั้นต่ำและกรณีทดสอบจากใบข้อบกพร่องและ flow ชิ้นงานปัจจุบัน