ระบบควบคุมการเปลี่ยนแปลงคำสั่งผลิต: RFP และการทดสอบรับมอบ

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

เหตุใดการเปลี่ยนคำสั่งหลังปล่อยจึงต่างจากการแก้แผน

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

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

กำหนดขอบเขตการแก้ไขตามสถานะคำสั่ง

เอกสาร RFP ควรมีตารางระบุว่าสถานะใดแก้คุณลักษณะใดได้ และต้องมีการควบคุมแบบใด คำว่า “แก้หลังปล่อยได้” ไม่บอกว่าจะเขียนทับขั้นตอนที่เริ่มแล้วหรือวัสดุที่เบิกแล้วได้หรือไม่ ฟังก์ชันเปลี่ยนรายการ BOM ในนาทีสุดท้ายของ Microsoft จำกัดคำสั่งที่เปลี่ยนได้ไว้ที่สถานะ Estimated หรือ Scheduled ขณะที่เอกสาร SAP Business ByDesign ยกตัวอย่างการเปลี่ยนจำนวนหรือวันที่บางรายการหลังปล่อยหรือเริ่มงานแล้ว นี่คือความต่างเฉพาะผลิตภัณฑ์ ไม่ใช่กฎสากลของ MES/ERP Microsoft: Last-minute changes SAP: Production Orders Quick Guide

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

ทำให้คำขอเป็นข้อมูลที่ตรวจประเมินได้

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

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

กรณีวันส่ง ควรแยกวันสัญญากับลูกค้า วันเสร็จตามแผนของคำสั่ง เวลาเริ่ม/จบรายขั้นตอน และวันวัสดุเข้า การแก้วันที่ช่องเดียวไม่ได้ทำให้กำลังการผลิตกับวัสดุสอดคล้องกัน Microsoft ระบุว่าการแก้ planned order อาจยังไม่สะท้อนในแผนส่วนอื่นจนกว่าจะรันแผนใหม่ และความล่าช้าของชิ้นส่วนอาจส่งผลต่อสินค้าขั้นบน จึงควรระบุเวลาและวิธีแสดงผลการคำนวณใหม่ใน RFP Microsoft: Production planning

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

การตรวจผลกระทบต้องชี้ว่าใครและงานใดได้รับผล

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

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

จับคู่สายอนุมัติกับจุดเริ่มมีผลจริง

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

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

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

การส่งรุ่นใหม่ต้องหยุดการใช้คำสั่งเก่าทุกทาง

การแสดงรุ่นใหม่บนแท็บเล็ตหนึ่งเครื่องไม่ทำให้ใบงานพิมพ์ แคชออฟไลน์ ค่าที่ส่งไปเครื่อง หรือใบหยิบของคลังหมดอายุโดยอัตโนมัติ RFP ต้องระบุวิธีหยุดรุ่นเก่า รับรุ่นใหม่ ตรวจเครื่องที่ยังไม่อัปเดต และเงื่อนไขเริ่มงานอีกครั้งสำหรับแต่ละช่องทาง เอกสาร SAP ME แสดงตัวอย่างเฉพาะผลิตภัณฑ์ที่เมื่อรับการปรับคำสั่งซึ่งปล่อยแล้ว จะพัก shop order และ SFC ที่กำลังทำ พร้อมแจ้งผู้ปฏิบัติ ตัวอย่างนี้ช่วยออกแบบกรณีทดสอบการหยุดงานระหว่างเปลี่ยน ไม่ใช่พฤติกรรมของทุกระบบ SAP: Update of Released Production Order

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

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

กระทบยอด ERP, MES และผลผลิตจริงตามรุ่น

รูปแบบหนึ่งคือให้ ERP เป็นแหล่งหลักของหัวคำสั่งและจำนวนตามแผน ส่วน MES เป็นแหล่งหลักของการปฏิบัติงานและผลผลิตจริง แต่ระบบเดิมของแต่ละโรงงานอาจต่างกัน จัดทำตารางความรับผิดชอบรายช่อง ส่งเลขคำสั่ง รุ่น และรหัสการเปลี่ยนในข้อความเชื่อมต่อ เพื่อแยกรุ่นที่ใช้แล้ว รุ่นเก่า และรุ่นกลางที่หาย การรับข้อความเดิมซ้ำต้องไม่ปรับซ้ำ ความล้มเหลวต้องมีเหตุผลและวิธีส่งใหม่ ISA-95 Part 5 กล่าวถึงธุรกรรมระหว่างระบบธุรกิจกับระบบผลิต ส่วน idempotency และ retry ในที่นี้เป็น ข้อกำหนดการติดตั้งที่เสนอ ISA: Part 5

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

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

เก็บกรณีเปลี่ยนจริงและนิยามข้อมูลก่อนจัดซื้อ

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

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

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

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

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

ควบคุมการเปลี่ยนฉุกเฉินและการยกเลิกในกระบวนการเดียวกัน

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

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

เขียน RFP ให้ตรวจรับได้

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

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

FAT: ทดสอบทั้งเหตุการณ์ปกติและผิดปกติ

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

1. เพิ่มจำนวนก่อนเริ่ม: คำนวณวัสดุและกำลังใหม่ หน้างานยังเห็นรุ่นเดิมก่อนอนุมัติ และเปลี่ยนหลังอนุมัติ
2. ลดจำนวนระหว่างผลิต: แยกงานเสร็จ WIP และยอดไม่เริ่ม พร้อมระบุล็อตที่กระทบ
3. เลื่อนวันให้เร็วขึ้น: เตือนเมื่อเครื่องหรือวัสดุไม่พอ และแสดงทางเลือกกับคำตอบลูกค้า
4. เปลี่ยนวัสดุ: ไม่ปะปนวัสดุเก่าที่เบิกแล้วกับวัสดุใหม่ และตามล็อตที่ใช้จริงได้
5. เปลี่ยนขั้นตอน: ไม่เขียนทับประวัติขั้นตอนที่เริ่มแล้ว และใช้ขั้นตอนใหม่จากจุดที่กำหนด
6. คำขอพร้อมกัน: ตรวจการเปลี่ยนสองรายการบนคำสั่งและรุ่นเดียวกัน และบังคับประเมินรายการหลังใหม่
7. เน็ตขาดและส่งซ้ำ: ไม่รับคำสั่งเก่า และหลังฟื้นตัวใช้ข้อความเพียงครั้งเดียว
8. สิทธิ์และการยกเลิก: ผู้ไม่มีสิทธิ์อนุมัติไม่ได้ และการยกเลิกหลังอนุมัติเป็นเหตุการณ์ใหม่

เกณฑ์ตัวเลขต้องอิงปริมาณงานและเครือข่ายจริง แทนที่จะตั้งเวลา “ทุกเครื่องภายใน X วินาที” โดยไม่มีฐาน ให้ระบุจำนวนปลายทาง ระยะขาดสัญญาณที่ยอมรับได้ และขั้นตอนที่ต้องหยุด แล้ววัดในทดสอบ เอกสารการตรวจ ISO/TC 176 กล่าวถึงการทบทวนและควบคุมการเปลี่ยนการผลิต แต่ไม่ได้กำหนดหน้าจอหรือเวลาตอบสนอง ISO/TC 176 Auditing Practices Group

SAT: ตรวจสิ่งเฉพาะของโรงงานจริง

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

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

ลำดับติดตั้งและสิ่งที่กำหนดต้นทุน

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

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

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

ติดตั้งระบบควบคุมการเปลี่ยนคำสั่งผลิตใน MES อย่างเดียวได้ไหม?

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

เมื่อเปลี่ยน engineering BOM คำสั่งที่ปล่อยแล้วจะเปลี่ยนอัตโนมัติหรือไม่?

อย่าสันนิษฐานเช่นนั้น บางผลิตภัณฑ์คัดลอก production BOM และ route เข้าคำสั่งเมื่อสร้าง และจำกัดการแก้ตามสถานะ Microsoft อธิบายการคัดลอกและการแก้ก่อนเริ่มคำสั่ง Microsoft: Production order lifecycle ต้องตรวจรุ่น BOM วัสดุที่เบิก และสถานะเริ่มของคำสั่งเป้าหมาย พร้อมระบุคำสั่งที่อยู่ในขอบเขต

ใครควรอนุมัติการเปลี่ยนจำนวนและวันส่ง?

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

FAT และ SAT ต้องทดสอบเรื่องเดียวกันหรือไม่?

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

สรุป

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

แม้ใบเปลี่ยนและขั้นตอน ERP/MES ปัจจุบันยังไม่เรียบร้อย ก็สามารถเริ่มจากกรณีล่าสุดในหนึ่งไลน์เพื่อกำหนดคำถาม RFP ได้ ปรึกษา TOMAS TECH

เอกสารต้นทาง

• ISA: ISA-95 Standard
• ISA: ISA-95 Part 5
• Microsoft: Release production orders
• Microsoft: React to last-minute changes
• Microsoft: Production planning
• SAP: Production Orders Quick Guide
• SAP: Update of Released Production Order
• Oracle: Using Manufacturing
• ISO/TC 176: Auditing Practices Group