ระบบสั่งงานขนย้ายระหว่างกระบวนการผลิต: แนวทางนำไปใช้ตั้งแต่คำขอจนถึงรับเข้า

เมื่อมีการนำระบบคำสั่งขนส่งระหว่างกระบวนการมาใช้ในโรงงานอุตสาหกรรม หากมุ่งเน้นเพียงแค่ให้รถเข็นวิ่งเร็วขึ้น ก็ใช่ว่าปัญหาความล่าช้าจะหมดไป เช่น ฝ่ายก่อนหน้าบอกว่า “ส่งออกแล้ว” ขณะที่ฝ่ายถัดไปบอกว่า “ยังไม่ได้รับ” ระหว่างนั้น การระบุสถานะและผู้รับผิดชอบของ WIP (Work-In-Process) รวมทั้งข้อมูลรายการสินค้า ล็อต ปริมาณ และปลายทาง ไม่ถูกบันทึกเป็นธุรกรรมเดียวกัน บทความนี้ สมมติโรงงานที่ใช้แรงงานคน รถเข็น และ AGV ผสมกัน โดยจะตั้ง “ขอขนส่ง→รับของ→ตรวจสอบสินค้า→ส่งมอบ→รับเข้า→เสร็จสิ้น” เป็นแกนหลักของการออกแบบ อธิบายวิธีป้องกันการส่งผิดและการรับพลาด กำหนดขอบเขตของ MES, ERP, WMS ให้ชัดเจน พร้อมสรุปจุดที่ควรตรวจสอบตั้งแต่ RFP จนถึง FAT/SAT

ขอบเขตภารกิจของระบบระบุคำสั่งการขนส่งระหว่างกระบวนการ

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

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

ISA-95 เป็นกรอบอ้างอิงสำหรับการแลกเปลี่ยนข้อมูลระหว่างการบริหารธุรกิจองค์กรและการปฏิบัติงานในโรงงาน, GS1 ให้มาตรฐานสำหรับการระบุและเหตุการณ์เห็นภาพ แต่ทั้งสองมาตรฐานไม่ได้กำหนดระบบสถานะทั้งหก, หน้าจอ หรือผู้อนุมัติเหมือนบทความนี้แบบบังคับ โมเดลสถานะและรายการตรวจสอบด้านล่าง เป็น “ข้อเสนอแนะการออกแบบ” อ้างอิงแนวคิดนั้น สามารถดู การออกแบบ Routing Master และ การควบคุมการแบ่ง/รวมล็อต WIP เป็นจุดเชื่อมกับกระบวนการที่เกี่ยวข้อง

กำหนด “หน่วยขนส่ง” และรหัสประจำตัวตั้งแต่ต้น

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

รหัสคำสั่งขนส่งที่แนะนำ ควรแยกจากรหัสเอกสาร ERP หรือ Job AGV ใช้เป็น ID คงที่แม้มีการ retry ในรายละเอียดควรมี ชนิดสินค้า คำสั่งผลิต ล็อต รหัสคอนเทนเนอร์ จำนวนและหน่วย สถานที่ต้นทาง สถานที่ปลายทาง เวลาที่ต้องการ ความสำคัญ เหตุผล และสถานะคุณภาพ หากเปลี่ยนคอนเทนเนอร์กลางทาง ต้องไม่ “overwrite” ID เดิม แต่ควรเพิ่มเหตุการณ์ mapping ระหว่างคอนเทนเนอร์เดิมและใหม่ กรณีขนย้ายบางส่วน ให้แยก header-รายละเอียด, ตรวจสอบการรวมจำนวน

หากจะใช้รหัส GS1 ควรตรวจสอบความสอดคล้องกับฉลากที่มีอยู่ GS1 สนับสนุนรหัส GTIN, ล็อต, หน่วย logistics แต่ไม่จำเป็นต้องนำ GS1 มาใช้กับคอนเทนเนอร์ภายในโรงงานทุกใบ สำคัญคือ ต้องนิยามอย่างชัดเจนว่าข้อมูลแต่ละชิ้นอยู่ namespace ใด mapping กับระบบใดอย่างไร ต้องวางแผนกรณีป้ายหลุด ฉลากใหม่ หรือการนำภาชนะเปล่ากลับมาใช้ใหม่

สถานะทั้งหก และการเปลี่ยนแปลงความรับผิดชอบ

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

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

การป้องกันการขนส่งผิดด้วย State Transition

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

กฎแนะนำ ① ห้ามรับคอนเทนเนอร์นอกแผน ② ถ้าตำแหน่งต้นทางไม่ตรงต้องให้หัวหน้าตรวจสอบ ③ ถ้าปลายทางผิดให้ปฏิเสธการส่ง ④ ถ้าสถานะคุณภาพเปลี่ยนต้องตรวจสอบใหม่ ⑤ ถ้ามีความคลาดเคลื่อนต้องกรอกเหตุผลและให้อนุมัติ ⑥ หากมีงานขนส่งเดินอยู่มากกว่าหนึ่งรายการในภาชนะเดียวให้หยุดรับคำขอใหม่ กรณีที่ยกเว้นการสแกน ต้องระบุเหตุผล รองรับด้วยวิธีตรวจสอบอื่น ๆ เช่น ป้ายเสีย, มือเปื้อน ฯลฯ และลงชื่อผู้ปลดล็อกพร้อมวันเวลาและข้อมูลก่อน-หลังไว้ใน log

ไม่ว่าขนส่งโดยแรงงานคน รถเข็น หรือ AGV ให้ใช้ Business Transaction ID และรหัสสินค้าเดียวกัน ส่วนรหัส Job AGV/สถานะ ให้เป็นข้อมูลแนบเพิ่มเติม หากรถเสียแล้วเปลี่ยนไปใช้แรงงานคน ห้ามสร้างคำสั่งใหม่ทับเดิม เมื่อสลับรถให้ยกเลิกงานเดิมก่อนสร้างงานใหม่ ตรวจสอบว่าไม่มีใครสั่งขนส่งซ้อนในคอนเทนเนอร์เดียว

หน้าจอคำสั่งขนส่ง: ฝ่ายส่ง/รับเข้า/ขนส่ง เห็นอะไรบ้าง

หน้าจอฝั่งต้นทาง ต้องแสดง “อะไร เท่าไหร่ ส่งที่ไหน หมดเขตเมื่อไหร่” อย่างชัดเจน หลีกเลี่ยงการให้ใส่ชื่อปลายทางเอง เพราะอาจพิมพ์ผิดแบบและเลือกผิด กรองสถานที่จาก Routing Master โดยตัด process ที่หยุดหรือเต็มออก อย่างไรก็ดี Routing Master คือ “Process ที่อาจใช้” ส่วนคำสั่งขนส่งคือ “สถานที่ปลายทางสำหรับครั้งนี้” ไม่ควรแก้ 2 ชุดแยกกัน

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

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

การเห็นภาพคงค้าง: แสดง “สถานที่” และ “ผู้รับผิดชอบคนถัดไป”

แค่แสดงยอดคงค้างโดยรวม ไม่สามารถผลักดันการปรับปรุงได้ ต้องแยกสาเหตุ เช่น รอรับของ, กำลังขนส่ง, ส่งถึงปลายทางแต่รอรับ, รับเข้าแล้วแต่ยังไม่ update ที่ ERP/MES ต้องแสดงเจ้าของ-ผู้รับผิดชอบ, เวลาเหตุการณ์ล่าสุด, การดำเนินการต่อไป, deadline เช่น หากคอนเทนเนอร์ค้างหลังส่งมอบ 30 นาที สีแดงทั้งหมด แต่ถ้าเป็นรอบกลางคืนที่ไม่มีคนรับ ไม่ควรตีความเหมือน process ที่ละเลยจริง

กำหนดเวลากำหนดตามแต่ละสินค้า/กระบวนการ/กะ เวลาแต่ละสถานะต้องเก็บแยกจากเวลารวมตั้งแต่ขอ ถึง รับ รายงาน dashboard ให้แสดงทั้งยอด รวมถึงค่ามัธยฐานและเปอร์เซ็นไทล์ระดับสูงของเวลาขนส่ง ส่วนที่รับบางส่วน/คืนกลับ/สแกนพลาด/ข้อยกเว้น ฯลฯ ใช้เป็น KPI วัดผลได้ ต้องบันทึกข้อมูล event ของการขนส่งทั้ง รหัส, เวลา, ตำแหน่ง, คนหรืออุปกรณ์, สถานะ, จำนวน, เหตุผล, เวลาใน terminal/บน server กรณีใช้มาตรฐาน EPCIS ให้ตรวจสอบว่า model ตรงนิยามมาตรฐาน/ศัพท์หรือไม่ แค่บันทึก event แบบตัวอย่างบทความ ไม่พอจะอ้างว่าผ่านมาตรฐานทันที

การกำหนดขอบเขต ERP・MES・WMS・ขนส่งระหว่างกระบวนการ

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

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

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

ใช้รูปแบบงานเดียวกันสำหรับคน รถเข็น และ AGV

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

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

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

ให้การจัดการกรณีผิดปกติเป็นส่วนหลักของข้อกำหนด

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

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

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

ข้อกำหนดด้านการทำงานและด้านคุณภาพระบบที่ควรระบุใน RFP

ตกลงโครงสร้างข้อมูลที่ระบบต้องแลกเปลี่ยนก่อนพิจารณาหน้าจอ

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

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

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

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

ข้อกำหนดด้านการทำงานที่ควรใช้เปรียบเทียบอย่างน้อยมี ① การสร้างคำขอและป้องกันคำขอซ้ำ ② การตรวจสอบชิ้นงานจริง ③ การบันทึกรับงาน ส่งมอบ และรับเข้า ④ การรับบางส่วนและการขนย้ายหลายรายการร่วมกัน ⑤ การเชื่อมต่อสถานะพักรอตรวจคุณภาพ ⑥ การแสดงงานค้างและแจ้งเตือนเมื่อเกินเวลา ⑦ การสลับผู้ขนย้ายระหว่างคน รถเข็น และ AGV ⑧ ประวัติเพื่อตรวจสอบย้อนหลัง ⑨ สิทธิและการอนุมัติ ⑩ การเชื่อม ERP/MES/WMS ให้ผู้เสนอระบบระบุว่าแต่ละข้อเป็นความสามารถมาตรฐาน การตั้งค่า การพัฒนาเพิ่ม หรือใช้ผลิตภัณฑ์ภายนอก แล้วสาธิตการทำงานจริง ตรวจสอบด้วยว่าชื่อข้อมูล เหตุผลของกรณีผิดปกติ ข้อความแจ้งเตือน และคู่มือรองรับภาษาที่คนหน้างานใช้

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

FAT・SAT: ตรวจสอบ “ปิดธุรกรรมได้” ไม่ใช่แค่ “ทำงาน”

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

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

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

ลำดับการนำระบบไปใช้และการวัดผล

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

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

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

ฉากสถานการณ์ที่ต้องตรวจสอบในระหว่างการสอบถามในหน้างาน

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

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

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

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

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

งานกำกับคำสั่งขนส่งระหว่างกระบวนการทำได้ใน MES ล้วน ๆ หรือไม่

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

คำสั่งขนส่ง WIP กับการโยกย้ายสต็อกเหมือนกันหรือไม่

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

จุดไหนควรตรวจสอบสินค้าก่อนจบคำสั่งขนส่ง

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

ไม่มี AGV จำเป็นต้องใช้ระบบแบบนี้ไหม

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

อะไรที่ควรเน้นมากที่สุดใน RFP กับ FAT/SAT

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

สรุป

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

หากกำลังพิจารณาว่าควรเริ่มปรับปรุงงานกระดาษหรือเชื่อม MES, WMS และ AGV จากจุดใด สามารถ ติดต่อ TOMAS TECH เพื่อร่วมกันกำหนดขอบเขตชิ้นงาน สถานะ และการเชื่อมต่อระบบได้ตั้งแต่ช่วงวางแผน

ข้อมูลอ้างอิงและข้อสังเกตตำแหน่งในแผนผังการออกแบบ

• ISA, ISA-95 Series of Standards: กรอบอ้างอิงสำหรับการแลกเปลี่ยนข้อมูลระหว่างธุรกิจกับงานผลิต ไม่ได้กำหนดสถานะขนย้ายทั้งหกในบทความนี้
• ISA, Business-to-Manufacturing Transactions: อธิบายรูปแบบธุรกรรมข้อมูลระหว่างระบบระดับ 3 และระดับ 4
• GS1, EPCIS: แนวคิดการบันทึกเหตุการณ์ว่าเกี่ยวกับอะไร เกิดเมื่อใด ที่ไหน และด้วยเหตุผลใด
• GS1, Global Traceability Standard: แนวทางเลือกความละเอียดของรหัสสินค้าสำหรับตามรอย
• GS1, Application Identifiers: คำอธิบายรหัสที่ระบุความหมายของข้อมูลบนฉลาก
• OMG, BPMN 2.0: มาตรฐานสำหรับอธิบายกระบวนการที่ข้ามหน่วยงาน โดยไม่ได้กำหนดหน้าจอหรือค่าเกณฑ์เฉพาะโรงงาน

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