การอนุมัติชิ้นส่วนทดแทน: BOM, MRP และการตามล็อต

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

การอนุมัติชิ้นส่วนทดแทนคือการกำหนดเงื่อนไขการใช้

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

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

เอกสาร Microsoft Dynamics 365 Supply Chain Management อธิบาย plan group และลำดับความสำคัญของวัสดุทดแทนใน BOM/สูตรการผลิต โดยระบบวางแผนสามารถพิจารณารายการสำรองเมื่อวัสดุที่ต้องการไม่เพียงพอ นี่เป็นตัวอย่างความสามารถของผลิตภัณฑ์และมีเงื่อนไขด้านเวอร์ชัน/การตั้งค่า ไม่ได้หมายความว่าระบบตรวจเงื่อนไขลูกค้า QA และล็อตทั้งหมดให้โดยอัตโนมัติ ควรแยกการอนุมัติ “ความสัมพันธ์ระหว่างชิ้นส่วน” ออกจากการอนุญาตให้ใช้ “ล็อตนี้กับใบสั่งผลิตนี้” ดู คำอธิบายการใช้วัสดุทดแทนของ Microsoft

รายการเสนอ ความสัมพันธ์ที่อนุมัติ และสิทธิ์ป้อนงานไม่ใช่สถานะเดียวกัน

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

แยกการใช้ทดแทนควบคู่จากการเปลี่ยนแบบถาวร

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

ลำดับอนุมัติ: แยกหน้าที่วิศวกรรม QA จัดซื้อ และวางแผน

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

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

การอนุมัติของลูกค้าต้องเป็นสถานะแยก

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

การเบี่ยงเบนฉุกเฉินไม่ควรกลายเป็นสิทธิ์ถาวร

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

แสดงรายการทดแทนใน BOM, MRP, ERP และ MES อย่างไร

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

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

ตัวเลือกที่ MRP วางแผน ไม่เท่ากับชิ้นส่วนที่ใช้จริง

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

วันมีผลเพียงอย่างเดียวไม่พอ

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

หน่วยแปลง อัตราใช้ และต้นทุน

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

ให้ MES และคลังหยุดการป้อนผิด และตามล็อตกลับได้

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

บันทึกเหตุการณ์จริง เช่น “รายการ B ล็อตรับเข้า L จำนวน Q ใช้ที่ขั้นตอน P ของใบสั่ง O เวลา T” ไม่ใช่เพียงสำเนาข้อมูลมาสเตอร์ว่า “A มีทางเลือก B” เมื่อแก้ไขให้ผูกเหตุการณ์แก้กับรายการเดิม ไม่ลบอดีตเงียบ ๆ เอกสาร electronic batch records ของ Microsoft มีตัวอย่างการสืบค้นเวอร์ชัน BOM/สูตร ปริมาณที่วางแผนและใช้จริง วัสดุที่ถูกแทนระหว่างผลิต คุณลักษณะล็อต และ quality order ขอให้ผู้ขายระบบที่พิจารณาสาธิตการค้นและส่งออกข้อมูลที่เทียบเท่า เพราะฟังก์ชันอาจต่างกัน

GS1 EPCIS/CBV 2.0 เป็นมาตรฐานภาษาเหตุการณ์สำหรับระบุว่าอะไร เมื่อใด ที่ไหน ทำไม และอย่างไร ช่วยออกแบบการแลกเปลี่ยนเหตุการณ์ของชิ้นส่วนและล็อตระหว่างองค์กร แต่ไม่ได้กำหนด workflow อนุมัติของ ERP หรือโครงสร้าง BOM โรงงานยังต้องผูกเลขอนุมัติ ล็อตที่ใช้ ล็อตสินค้าสำเร็จ และการจัดส่งในโมเดลข้อมูลของตนเอง ดู ภาพรวม EPCIS ของ GS1

ตามรอยสองทิศทางขั้นต่ำ

จากล็อตสินค้าสำเร็จต้องค้นใบสั่งผลิต รุ่น BOM ชิ้นส่วน/ล็อตที่ใช้จริง ล็อตผู้ขาย และใบอนุมัติได้ ในทิศกลับ จากล็อตชิ้นส่วนต้องค้นทุกล็อตสินค้าสำเร็จ สต็อกค้าง และคำสั่งหรือลูกค้าที่ส่งออกไป เก็บทุก input เมื่อหลายล็อตเข้ารวมกัน และบันทึกการแบ่ง งานแก้และการคืนเป็นเหตุการณ์แยก GS1 Global Traceability Standard ให้หลักการระบุตัวตนและบันทึกข้อมูล ส่วนความละเอียดที่โรงงานต้องมีขึ้นอยู่กับความเสี่ยงสินค้า สัญญา และข้อกำหนดที่ใช้จริง

QA hold และการยกเลิกสิทธิ์

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

เงื่อนไขเฉพาะโรงงานไทย: สำนักงานใหญ่ โรงงาน และผู้ขาย

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

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

เป้าหมายเวลาตอบข้ามประเทศ

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

ข้อกำหนดที่ควรเขียนใน RFP ระบบจัดการชิ้นส่วนทดแทน

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

Data contract ต้องมีเงื่อนไข ไม่ใช่เพียงเลขอนุมัติ

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

เปรียบเทียบต้นทุนทั้งหมด

กลุ่ม substitute มาตรฐานอาจช่วย MRP แต่ไม่ครอบคลุมข้อจำกัดลูกค้า QA hold หรือการย้อนล็อต เปรียบเทียบค่าเตรียมมาสเตอร์ ทบทวน BOM เก่า ย้ายหลักฐานอนุมัติ เครื่องอ่านและฉลาก อินเทอร์เฟซ FAT/SAT อบรม บำรุงรักษาและกู้คืน ถ้าประเมิน ROI ให้ใช้ปริมาณการเปลี่ยนจริง เวลาแก้งานจริงและจำนวนล็อตที่กระทบ พร้อมแยกสมมติฐาน บทความนี้ไม่สร้างราคาตลาดหรือเปอร์เซ็นต์ผลดีขึ้น

กรณี FAT/SAT สำหรับการอนุมัติชิ้นส่วนทดแทน

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

• อนุมัติปกติ: เสนอ B แทน A สำหรับสินค้า P/BOM V1 ผ่านวิศวกรรม QA จัดซื้อ และลูกค้าหากต้องมี ก่อนครบทุกขั้น B ต้องไม่ถูกเลือกเพื่อใช้จริง
• จำกัดโรงงาน: B ใช้ได้ที่โรงงาน T ในไทย แต่ใช้ไม่ได้ที่โรงงาน U ระบบให้ผลต่างตาม site ของคำสั่ง
• ขอบเขต revision: B ใช้ได้เฉพาะ BOM V2 คำสั่งเดิม O1/V1 ไม่ถูกเขียนทับเงียบ ๆ คำสั่งใหม่ O2/V2 เลือกได้
• เวลาเริ่มใช้: สมมติ 15 ตุลาคม 08:00 ICT ทดสอบ 07:59, 08:00 เครื่องสำนักงานใหญ่คนละเขตเวลา และ MRP กลางคืน
• เพดานจำนวน: สมมติอนุญาตครั้งเดียว 300 ชิ้น เมื่อใช้ไป 299 ชิ้น ชิ้นถัดไปผ่าน อีกชิ้นต้องถูกปฏิเสธ การยกเลิก/ลองใหม่ต้องไม่เพิ่มยอดสิทธิ์ผิด
• QA hold: ล็อต L1 ของ B ถูกกัก แต่ L2 ผ่าน ตรวจผล MRP แยกจากสิทธิ์เบิกและป้อนงาน
• จำกัดลูกค้า: คำสั่ง C1 ผ่าน C2 รออนุมัติ สต็อกร่วมในคลังไม่ทำให้สิทธิ์เฉพาะลูกค้ากลายเป็นสิทธิ์ทั่วไป
• เครือข่ายขาด: MES ออฟไลน์ก่อนรับการยกเลิก แสดงเวอร์ชันกฎที่ cache และวันหมดอายุ หยุดใช้เมื่อเกินเกณฑ์ แล้วซิงก์โดยไม่สร้างรายการซ้ำ
• ย้อนล็อต: สมมติล็อต L1 ของ B ใช้ในสินค้าสำเร็จ F1/F2 ค้นจาก F1 ไปถึง B/L1/เลขอนุมัติ และจาก L1 ไปถึง F1/F2/ที่ส่งออก
• ยกเลิก: แสดงคำสั่งยังไม่เริ่ม ของเบิกแล้ว WIP สินค้าเสร็จ และสินค้าส่งออก คงประวัติการใช้เดิมแต่ห้ามใช้ใหม่

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

แผนขอบเขต 90 วันและตัวชี้วัด

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

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

ตัวอย่างจัดลำดับความสำคัญ

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

FAQ: การอนุมัติชิ้นส่วนทดแทน

ใส่รายการทดแทนใน BOM แล้วถือว่าอนุมัติครบหรือไม่?

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

เมื่อของเดิมขาด MRP จะเลือกของทดแทนที่อนุมัติอัตโนมัติหรือไม่?

ขึ้นกับผลิตภัณฑ์ เวอร์ชันและการตั้งค่า ตัวอย่างของ Dynamics มี plan group และลำดับความสำคัญ แต่ยังต้องตรวจเงื่อนไขลูกค้า QA ล็อต โรงงาน และวันใช้ ทดสอบผลวางแผนและการป้อนงานจริงแยกกัน

ใครควรอนุมัติชิ้นส่วนทดแทน?

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

สต็อกชิ้นส่วนเดิมใช้ต่อได้ถึงเมื่อใด?

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

EPCIS จำเป็นสำหรับการตามล็อตชิ้นส่วนทดแทนหรือไม่?

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

RFP และ FAT/SAT ควรทดสอบอะไรเป็นอันดับแรก?

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

สรุป

การอนุมัติชิ้นส่วนทดแทนเริ่มจากหลักฐานรายการเสนอ ผ่านวิศวกรรม QA จัดซื้อ และลูกค้าตามเงื่อนไข ไปสู่การเริ่มใช้ใน BOM/MRP การตรวจซ้ำที่คลัง/MES และการตามล็อตที่ใช้จริงสองทิศทาง เขียนเงื่อนไขและเจ้าของข้อมูลใน RFP และใช้กรณีปฏิเสธกับการย้อนล็อตเป็นหัวใจของ FAT/SAT ฟังก์ชันทดแทนของ ERP มีประโยชน์ แต่ต้องตรวจขอบเขตกับความต้องการของโรงงานจริง

หากโรงงานไทยของคุณมีทะเบียนอนุมัติ BOM, MRP และบันทึกหน้างานที่ยังไม่เชื่อมกัน TOMAS TECH ช่วยจัดโฟลว์ปัจจุบัน ข้อกำหนด RFP และกรณีทดสอบ FAT/SAT ได้ตั้งแต่ช่วงพิจารณา ติดต่อผ่านหน้าติดต่อเพื่อเริ่มจากคำถามว่า “ใครตัดสินว่าใช้ชิ้นส่วนนี้กับคำสั่งนี้ได้”

แหล่งอ้างอิง

• Microsoft Learn: Item substitution for formulas and bills of materials
• Microsoft Learn: Bills of materials and formulas
• Microsoft Learn: Manage changes to engineering products
• Microsoft Learn: Quality orders
• Microsoft Learn: Electronic batch records
• GS1: EPCIS and CBV
• GS1: Global Traceability Standard