การนำระบบจัดการวัตถุดิบที่ลูกค้าจัดหาให้โรงงานมาใช้ ไม่ควรเริ่มจากการเลือกชนิดบาร์โค้ด คำถามแรกคือ ลูกค้าและโรงงานจะตรวจสอบตรงกันได้อย่างไรว่าใครเป็นเจ้าของวัสดุ ล็อตใดเข้ามา อยู่ที่ไหน ใช้กับใบสั่งผลิตใดเท่าไร และวัสดุที่เหลือถูกจัดการอย่างไร บทความนี้จัดลำดับตั้งแต่รับเข้า กักกันคุณภาพ เบิกเข้าผลิต ใช้จริง ของเสีย คืนลูกค้า กระทบยอดรายเดือน ขอบเขตการเรียกเก็บเงิน ไปจนถึงข้อกำหนด ERP, MES, WMS, RFP, FAT และ SAT สำหรับโรงงานรับจ้างผลิตในประเทศไทย
กำหนดขอบเขตสามเรื่องก่อนตั้งค่าระบบ
“วัตถุดิบที่ลูกค้าจัดหา” ในที่นี้หมายถึงลูกค้าส่งชิ้นส่วนเข้ามาในโรงงานของผู้รับจ้างผลิต เพื่อใช้ผลิตหรือประกอบตามคำสั่งซื้อของลูกค้ารายนั้น โรงงานเป็นผู้ครอบครองกล่องและดูแลสถานที่ แต่กรรมสิทธิ์อาจยังเป็นของลูกค้าตามสัญญา ทิศทางการไหลสำคัญมาก กรณีบริษัทของเราส่งวัสดุออกไปให้ผู้รับจ้างช่วง แม้หน้าจอคล้ายกัน แต่เจ้าของสินทรัพย์ ผู้สั่งงาน และผู้รับรายงานกลับด้านกัน ดูกรณีส่งออกได้จากบทความควบคุมงานจ้างช่วง บทความนี้เน้นวัสดุของลูกค้าที่เข้ามาในโรงงานเรา
เรื่องแรกคือ กรรมสิทธิ์ โรงงานซื้อวัสดุเมื่อรับเข้าหรือไม่ ลูกค้ายังเป็นเจ้าของหลังแปรรูปหรือไม่ ใครรับผิดชอบความสูญเสียตามปกติและความเสียหายผิดปกติ ต้องทำให้สัญญา ข้อมูลหลักสินค้า ประเภทธุรกรรม และการบัญชีสอดคล้องกัน เรื่องที่สองคือ จุดยืนยันจำนวน จำนวนตามใบส่งของ จำนวนที่นับได้ จำนวนที่ผ่านตรวจคุณภาพ จำนวนที่เบิก และจำนวนที่ใช้จริงไม่ใช่ค่าเดียวกัน เรื่องที่สามคือ เงิน โรงงานซื้อและขายมูลค่าวัสดุหรือคิดเฉพาะค่าจ้างผลิต การใช้เกิน ของเสีย ค่าเก็บรักษา และการคืนจะชำระอย่างไร การบัญชีและภาษีต้องพิจารณาตามสัญญาและผู้เชี่ยวชาญท้องถิ่น ช่องทำเครื่องหมาย “วัสดุลูกค้า” ในซอฟต์แวร์ไม่ได้ตัดสินเรื่องนี้
Oracle อธิบายตัวอย่างการผลิตตามสัญญาที่ OEM ติดตามทั้งชิ้นส่วนที่จัดหาและสินค้าสำเร็จรูปในสถานที่ของผู้รับจ้างผลิต ส่วนตัวอย่างสินค้าฝากขายของ Microsoft เป็นอีกรูปแบบหนึ่ง: รับสินค้าที่ผู้จัดหายังเป็นเจ้าของ แล้วโอนกรรมสิทธิ์ก่อนใช้ในการผลิต อย่านำสองกรณีนี้มาปะปนกัน หรือถือว่าวัสดุที่เก็บในโรงงานต้องเป็นสินค้าที่โรงงานซื้อแล้ว ตรวจสัญญาแยกสำหรับวัสดุและสินค้าสำเร็จรูป อ่านกระบวนการ contract manufacturing ของ Oracleและconsignment ของ Microsoftเพื่อใช้ตั้งคำถาม ไม่ใช่แทนข้อสรุปทางบัญชีของบริษัท
ออกแบบบัญชีเหตุการณ์ ไม่ใช่ดูเพียงยอดคงเหลือ
ยอดคงเหลือตอบว่า “มีกี่ชิ้น” แต่ไม่ตอบว่า “ทำไมต่างกัน” ให้บันทึกเหตุการณ์แยกกัน ได้แก่ กำหนดส่ง รับที่ประตู นับจำนวน กักกัน ตรวจผ่าน ย้ายตำแหน่ง จองให้ใบสั่งผลิต เบิกจากคลัง ส่งเข้าไลน์ ใช้จริง คืนของไม่ใช้ เป็นของเสีย คืนลูกค้า และปรับยอดตรวจนับ ทุกเหตุการณ์ต้องเชื่อมเอกสารต้นทาง ลูกค้า รหัสสินค้าลูกค้าและโรงงาน รุ่นแบบ ล็อต หน่วย จำนวน สถานที่ เวลา ผู้ปฏิบัติ ผู้อนุมัติ เหตุผล และสถานะก่อน-หลัง การแก้ไขควรมีรายการกลับรายการและรายการใหม่ ไม่เขียนทับประวัติเดิมเงียบ ๆ
มาตรฐาน GS1 EPCIS 2.0.1 อธิบายเหตุการณ์ผ่านสิ่งที่เกี่ยวข้อง เวลา สถานที่ บริบททางธุรกิจ และสภาพของสิ่งนั้น โรงงานไม่จำเป็นต้องติดตั้ง EPCIS ทุกแห่ง แต่แนวคิด “อะไร เมื่อไร ที่ไหน ทำไม และอยู่ในสภาพใด” ช่วยจัดโครงสร้างข้อมูลสำหรับแจ้งลูกค้าและย้อนสอบ เชื่อม ASN ของลูกค้า ฉลากบนกล่อง ผลรับเข้า และผลผลิตด้วยคีย์ที่ตกลงกัน
ถ้าล็อตลูกค้าเดียวกันเข้ามาสองเที่ยว การรวมเป็นยอดเดียวทันทีทำให้หายไปว่าเที่ยวใดขาดหรือเสียหาย จึงเก็บรหัสการรับและรหัสภาชนะก่อนรวมยอดเพื่อรายงาน ถ้าแบ่งกล่องให้เก็บความสัมพันธ์กล่องแม่-กล่องลูก หากล็อตเดียวจ่ายให้หลายใบสั่งผลิต ต้องเก็บปลายทางที่เบิกและต้นทางที่คืน เลขล็อตอย่างเดียวไม่ใช่หลักฐานการเคลื่อนไหวครบถ้วน
รับเข้า นับจำนวน กักกัน และปล่อยใช้
ถ้าลูกค้าส่ง ASN หรือแผนจัดหามาก่อน ให้ลงรายการรับที่คาดไว้ แต่ยอดคาดรับยังไม่ใช่สต็อกพร้อมใช้ เมื่อรถมาถึง ตรวจลูกค้า คำสั่งจัดหา รหัสสินค้า รุ่นแบบ ลักษณะบรรจุ จำนวนกล่อง ซีล ล็อตลูกค้า และวันผลิตหรือวันหมดอายุสำหรับสินค้าที่ต้องใช้ข้อมูลนั้น กำหนดการแปลงหน่วยชิ้น กล่อง ม้วน และน้ำหนัก รวมทั้งการปัดเศษ หากยืนยันรับตามใบส่งของโดยไม่นับจริง เมื่อพบส่วนต่างปลายทางจะไม่ทราบจุดเกิด
แยกสถานะ “มาถึง” “นับแล้ว” “กักกันคุณภาพ” “ผ่าน” และ “ไม่ผ่าน” จำนวนที่นับได้ไม่ได้หมายความว่าเบิกเข้าผลิตได้ กล่องเสียหาย ฉลากไม่ตรง ไม่ทราบล็อต รุ่นแบบผิด เอกสารรับรองไม่ครบ หรือเงื่อนไขเก็บรักษาผิด ต้องไปพื้นที่กักกันและห้ามจองหรือเบิกจนฝ่ายคุณภาพหรือลูกค้าอนุมัติ ใน SAT ให้ตรวจว่าระบบล็อกตรงกับป้ายและกรงกักกันจริง หาก ERP ยังแสดงเป็นของพร้อมใช้ MRP อาจวางแผนใช้วัสดุที่หน้างานห้ามใช้
ใช้บาร์โค้ดภายในได้ แต่หากฉลากลูกค้ามี GS1 ต้องอ่านความหมายให้ถูก AI (10) คือ batch/lot, (21) คือ serial และ (241) คือรหัสสินค้าของลูกค้า อย่างไรก็ดีฉลากอาจไม่มีข้อมูลทั้งหมดที่โรงงานต้องใช้ ไม่ควรบังคับให้รหัสสินค้าลูกค้าตรงกับรหัสภายในแบบหนึ่งต่อหนึ่งเสมอไป ให้ตารางจับคู่มีรุ่นทดแทน วันเริ่มใช้ และการอนุมัติ เทียบฉลากจริงกับรายการ GS1 Application Identifiers
เมื่อรับขาดหรือเกิน ต้องเก็บจำนวนแจ้งส่ง จำนวนที่นับ จำนวนกักกัน และจำนวนที่ลูกค้ายอมรับแยกกัน เปิดกรณีส่วนต่างพร้อมใบแจ้ง ภาพถ่าย หลักฐาน ผู้อนุมัติ การส่งเพิ่ม และการปิดกรณี ความเสียหายระหว่างขนส่งกับหลังส่งมอบอาจมีผู้รับผิดต่างกัน เวลาและจุดตรวจพบจึงสำคัญ การปรับยอดให้ตรง Excel ลูกค้าตอนสิ้นเดือนไม่เพียงพอ
แยกการจอง การเบิก และการใช้จริง
จองคือ “ตั้งใจใช้กับใบสั่งผลิตนี้” เบิกคือ “ย้ายจากคลังไปพื้นที่ผลิตจริง” ใช้จริงคือ “เข้าชิ้นงานหรือสูญเสียตามผลกระบวนการที่บันทึกแล้ว” การทำทั้งสามด้วยปุ่มเดียวเป็นที่มาของยอดต่าง เมื่อยกเลิกใบสั่ง ระบบอาจคืนยอดจองได้ แต่ของที่อยู่ข้างไลน์ไม่กลับคลังเอง ต้องนับ คืน และระบุว่ากล่องเปิดแล้วหรือยังและใช้ซ้ำได้ไหม ตอนเบิกให้สแกนทั้งภาชนะและใบสั่ง ตรวจล็อต รุ่นแบบ และสถานะรับผ่าน
BOM เป็นปริมาณมาตรฐาน แต่ของใช้จริงอาจเพิ่มจากตั้งเครื่อง ทดลอง ผลได้ไม่เต็ม หรือแก้งาน การตัดอัตโนมัติตาม BOM อย่างเดียวอาจซ่อนส่วนต่างของวัสดุลูกค้าที่มีราคาแพง Microsoft อธิบายหลักการบันทึกการใช้วัตถุดิบว่ามีหลายจังหวะ เช่น เริ่มผลิตหรือเริ่มขั้นตอน ให้เลือกตัดอัตโนมัติหรือสแกนจริงตามวัสดุและข้อตกลงกับลูกค้า พร้อมผู้อนุมัติส่วนต่าง
ตัวอย่างสมมติ: รับล็อต A 100 ชิ้น กักกัน 2 ชิ้น ผ่าน 98 ชิ้น เบิกไปหนึ่งใบสั่ง 60 ชิ้น ใน 60 ชิ้นนั้นเป็นงานดี 56 ของเสีย 2 และคืนส่วนที่ไม่ใช้ 2 ยอดพร้อมใช้จึงกลับเป็น 40 ชิ้น ส่วนกักกัน 2 อยู่คนละยอด ตัวเลขนี้ใช้แสดงวิธีคำนวณ ไม่ใช่อัตราผลได้มาตรฐานหรือเกณฑ์ยอมรับความสูญเสีย หากรายงานเพียง “เบิก 60 งานดี 56” อีก 4 ชิ้นจะไร้คำอธิบาย ลูกค้าต้องเห็นการแจกแจง
ของเสีย งานแก้ไข ของเหลือคืน และคืนลูกค้า
ของเสียไม่ใช่แค่ธุรกรรมลดสต็อก ให้เชื่อมขั้นตอนผลิต สาเหตุเสียหาย ล็อต จำนวน หลักฐานตรวจ ผู้รับผิด การแจ้งลูกค้า การจัดการของจริง และการเงินเป็นกรณีเดียว แยกชิ้นตัวอย่างที่ต้องเก็บสอบสวน ของรอลูกค้ารับ และของที่อนุมัติทำลาย สถานที่จริงต้องตรงกับยอดระบบ การทำลายก่อนอนุมัติอาจทำลายหลักฐานแม้ยอดท้ายเดือนตรง
งานแก้ไขต้องแยกวัสดุที่ใช้ครั้งแรกกับวัสดุเพิ่ม ระบุใบสั่งและรุ่นแบบ ป้องกันการตัดตาม BOM เดิมซ้อนกับการหยิบจากกล่องใหม่ ของไม่ใช้ที่คืนจากไลน์ต้องตรวจว่าซองเปิดหรือไม่ สภาพเก็บรักษายังดีไหม และระบุตัวล็อตเดิมได้ไหม ย้ายกลับคลังไม่ได้แปลว่ากลายเป็นของใหม่ที่จองได้ทันที
การคืนลูกค้าคือสายเหตุการณ์ตั้งแต่คำขอ เลือกของ แพ็ก รายการล็อต ออกคลัง ส่งมอบขนส่ง จนลูกค้ารับ ระหว่างทางยอดของสองฝ่ายอาจต่างกันโดยมีเหตุผล จึงมีคอลัมน์ “กำลังคืนระหว่างขนส่ง” และตกลงว่าฝ่ายใดตัดยอดเมื่อไร ของเหลือเมื่อหมดอายุหรือจบสัญญาต้องกำหนดค่าขนส่ง สิทธิ์ทำลาย และค่าใช้จ่ายด้วย
กระทบยอดรายเดือนและขอบเขตการออกใบแจ้งหนี้
เริ่มจากยอดต้นเดือนที่ตกลงกัน บวกรับเข้า หักการใช้ ของเสีย และการคืนที่อนุมัติ แล้วแสดงยอดกักกัน ของข้างไลน์ และของระหว่างขนส่งเพื่อไปสู่ยอดปลายเดือน ต้องตกลงความหมายของ “ใช้แล้ว” เวลา cutoff เขตเวลา รายการข้ามเดือน และวิธีแสดงการแก้ย้อนหลัง หากโรงงานไทยกับสำนักงานใหญ่ญี่ปุ่นปิดคนละวันที่ ให้เก็บเวลาพร้อมเขตเวลาและระบุวันที่ใช้รวมรายงาน
จัดประเภทส่วนต่างก่อนปรับ ได้แก่ ลูกค้ายังไม่บันทึก โรงงานยังไม่บันทึก ล็อตผิด หน่วยแปลงผิด สถานะกักกัน ของคืนอยู่ระหว่างทาง หรือวันตัดยอดไม่ตรง อย่าลบส่วนต่างด้วยแถว “ปรับยอด” ที่ไม่มีเหตุผลในเดือนถัดไป ผูกเหตุการณ์ต้นทาง ผู้พบ สาเหตุ ผู้อนุมัติ การยืนยันของอีกฝ่าย และเอกสารแก้ไข ตรวจนับต้องแยกของลูกค้าจากของบริษัทแม้ใช้ชั้นเดียวกัน รวมของในกรงคุณภาพและข้างไลน์ด้วย แนวทางจัดการวัสดุช่วยจัดข้อมูลหลักสินค้า สถานที่ และธุรกรรม
ใบแจ้งหนี้ขึ้นกับสัญญา หากคิดเฉพาะค่าจ้างผลิต อย่าสร้างรายการซื้อและขายวัสดุอัตโนมัติเพียงเพราะมีการรับและใช้ ถ้าคิดค่าการใช้เกิน ความเสียหายผิดปกติ ค่าเก็บ ค่าคัดแยก หรือค่าทำลาย ต้องมีจำนวน อัตรา และการอนุมัติรองรับ แต่หากเป็น consignment ที่โอนกรรมสิทธิ์เมื่อใช้ เส้นบัญชีและการชำระต่างออกไป ให้ทีมพาณิชย์ บัญชี และผู้เชี่ยวชาญตรวจเงื่อนไขสัญญา ศุลกากร และภาษี แล้วกำหนด transaction type ของ ERP ระบบทั่วไปไม่อาจสรุปภาษีแทนได้
ERP, MES และ WMS ควรรับผิดชอบอะไร
ERP มักเก็บลูกค้า สัญญา คำสั่งขาย ใบสั่งผลิต บัญชี ใบแจ้งหนี้ และยอดยืนยัน WMS ดูรับเข้า ตำแหน่ง ภาชนะ ตรวจนับ และการเคลื่อนย้ายจริง MES ดูการป้อนเข้าไลน์ ผลผลิต งานดี-เสีย และของเสีย แต่ชื่อระบบไม่ได้กำหนดขอบเขตจริง สำหรับแต่ละเหตุการณ์ระบุระบบที่รับข้อมูล ระบบต้นฉบับ ระบบที่อ่าน ผู้มีสิทธิ์แก้ และวิธีส่งซ้ำเมื่อเชื่อมต่อผิดพลาด แม้ ERP เป็นเจ้าของยอดสต็อก ก็ห้ามนำรายการในเครื่องสแกนที่ยังไม่ซิงก์มาใช้เป็นยอดพร้อมใช้ที่ยืนยันแล้ว
ข้อมูลหลักที่ต้องพิจารณา ได้แก่ ลูกค้า รหัสลูกค้า รหัสภายใน รุ่นแบบ หน่วยและการแปลง BOM ใบสั่งผลิต ล็อต ภาชนะ เงื่อนไขเก็บรักษา เจ้าของ สถานะคุณภาพ สถานที่ ประเภทจัดการ และประเภทการเรียกเก็บเงิน หากรหัสลูกค้าเดียวมาสองรุ่นแบบ การทำรุ่นหายตอนรับจะทำให้ MES หยุดการเบิกผิดไม่ได้ ย้ายตารางแปลงรหัสออกจาก Excel ส่วนตัว และควบคุมวันเริ่มใช้กับผู้อนุมัติ ระบุด้วยว่า “หนึ่งกล่องเท่ากับ 100 ชิ้น” จริงเสมอไหม แปลงน้ำหนักเป็นชิ้นอย่างไร และปัดเศษที่จุดใด
ข้อความเชื่อมต่อควรมี event ID และเอกสารต้นทางที่ไม่ซ้ำ ส่งซ้ำแล้วไม่ลงรายการสองรอบ ทดสอบลำดับสลับ ข้อมูลล่าช้า และล้มเหลวบางส่วน ถ้าคำอนุญาตเบิกมาถึงก่อนข่าวกักกัน ต้องมีข้อกำหนดปฏิเสธหรือพักรายการ อุปกรณ์ออฟไลน์ต้องเก็บทั้งเวลาที่เครื่องบันทึกและเวลาที่เซิร์ฟเวอร์รับ แยกรายการยังไม่ยืนยันจากยอดทางการ ตรวจทั้งความผิดพลาดในการส่ง API และความล้มเหลวของการลงบัญชีธุรกิจ เพราะ API ตอบสำเร็จไม่ได้พิสูจน์ว่าการใช้กับใบสั่งถูกต้อง
สำรวจงานจริงและจำกัดขอบเขตนำร่อง
เริ่มจากตามเอกสารและกล่องจริงของลูกค้าสองรายกับวัสดุตัวแทนหลายชนิด ตั้งแต่รับถึงคืน ถามแต่ละฝ่ายว่าจำนวนและกรรมสิทธิ์เปลี่ยนเมื่อใด รวบรวมรูปแบบแจ้งส่ง ฉลาก ตารางจับคู่รหัส เงื่อนไขเก็บ ข้อยอมรับความสูญเสีย Excel กระทบยอด รายการใบแจ้งหนี้ และส่วนต่างค้าง เดินดูคลัง ชั้นข้างไลน์ กรงกักกัน พื้นที่แก้งาน และจุดรอส่งคืน ไม่ใช่ดูเฉพาะรายการหน้าจอ
จำกัดนำร่องสามแกน: ลูกค้าและวัสดุ พื้นที่จริง และเหตุการณ์ ตัวอย่างสมมติคือแผงวงจรและชิ้นส่วนเรซินของลูกค้า A ในคลัง 1 กับไลน์ประกอบ 2 ครอบคลุมรับ กักกัน เบิก ใช้จริง คืนส่วนไม่ใช้ และกระทบยอด ไม่ใช่จำนวนที่แนะนำให้ทุกโรงงานใช้ เลือกโดยความถี่ส่วนต่าง มูลค่าวัสดุ ความต้องการติดตามย้อน ความร่วมมือของลูกค้า และความพร้อมหน้างาน อัตราสแกนสูงขึ้นแต่ยอดลูกค้ายังไม่ตรงไม่ถือว่าสำเร็จ
ใช้ธุรกรรมจริงของเดือนก่อนเพื่อกำหนดยอดตั้งต้นและจำลองเดือนนั้น รวมหน่วยกล่องและชิ้น ล็อตปะปน เบิกด่วน ปลดกักกัน ยกเลิกใบสั่ง แก้งาน ของเสีย และของคืนระหว่างทาง สืบความต่างกับระบบเดิม รับอนุมัติ และให้ผู้เกี่ยวข้องลงนามยอด ณ วันเปลี่ยนระบบ หากยอดตั้งต้นไม่ตรง ระบบใหม่จะบันทึกธุรกรรมถูกต้องทุกครั้งก็ยังไม่ตรงกับลูกค้า
RFP และการเปรียบเทียบผู้ขาย
อย่าเขียนเพียง “รองรับวัตถุดิบลูกค้า” ระบุรูปแบบกรรมสิทธิ์ วัสดุที่ไม่ประเมินเป็นสินทรัพย์บริษัท ยอดแยกลูกค้า การติดตามล็อต/ภาชนะ กักกัน การใช้ตามใบสั่ง ของเหลือคืน ของเสีย คืนลูกค้า กระทบยอด อนุมัติส่วนต่าง และเชื่อมใบแจ้งหนี้ สำหรับทุกเหตุการณ์บอกผู้บันทึก จุดยืนยัน วิธีแก้ ประวัติ และปลายทาง ERP/MES/WMS หากมีพอร์ทัลลูกค้า ระบุยอดที่เห็น รายการยังไม่ยืนยัน ความล่าช้า และสิทธิ์แยกลูกค้า
เปรียบเทียบราคาให้รวมทำความสะอาดข้อมูลหลัก อ่านฉลากเดิม เครื่องสแกน/พิมพ์ เชื่อมต่อ ย้ายยอดตั้งต้น พัฒนาข้อยกเว้น FAT/SAT อบรม ใช้ระบบคู่ขนาน บำรุงรักษา และเปลี่ยนรายงานลูกค้า ให้ผู้ขายทดลองข้อมูลชุดเดียวกัน แล้วแยกคำตอบเป็นฟังก์ชันมาตรฐาน ตั้งค่า พัฒนาเพิ่ม ทำมือ และไม่รวม สาธิตแดชบอร์ดสต็อกอย่างเดียวพิสูจน์เรื่องการใช้และการชำระไม่ได้
ให้น้ำหนักกับการจัดการส่วนต่างและตรวจสอบย้อนหลัง ขอให้สาธิตการรับที่นับไม่ตรง ล็อตกักกันที่ต้องห้ามจอง วัสดุที่เบิกไปแล้วแต่ยกเลิกใบสั่ง สแกนซ้ำหรือส่งซ้ำโดยยอดไม่เปลี่ยน และการแก้รายการเดือนที่ปิดแล้ว ระบุงานที่ลูกค้าต้องทำเอง เช่น ข้อมูลหลักและการอนุมัติ ในใบเสนอราคาด้วย
FAT และ SAT ต้องทดสอบผลที่คาดหวัง
FAT ทดสอบการตั้งค่าและการเชื่อมต่อในสภาพแวดล้อมทดสอบ ตัวอย่างข้อมูลสมมติ: คาดรับ 100 นับได้ 98 กักกัน 2 ดังนั้นพร้อมใช้ 96 สแกนภาชนะเดิมสองครั้งแต่รับเข้าครั้งเดียว รหัสลูกค้าหรือรุ่นแบบไม่ตรงต้องห้ามเบิก ยกเลิกใบสั่งหลังเบิกไม่ทำให้ยอดคลังเพิ่มเองโดยไม่มีของคืน บันทึกของไม่ใช้คืน ของเสีย ส่งคืนระหว่างทาง และแก้หลังปิดเดือนเป็นคนละเหตุการณ์ ตัวเลขนี้ไม่ใช่เกณฑ์ผลได้หรือ tolerance สากล
SAT ใช้ฉลาก แสง ขนาดกล่อง จุด Wi-Fi อ่อน ถุงมือ เครื่องพิมพ์ กรงกักกัน และวิธีตรวจนับจริง ทดสอบเน็ตหลุดและกลับมา ฉลากชำรุด หน่วยผสม กะกลางคืน และวันเปลี่ยนเดือน เกณฑ์ผ่านไม่ใช่แค่ “สแกนได้” หลังแต่ละเหตุการณ์ ภาชนะจริง สถานะระบบ รายงานลูกค้า และรายการบัญชี ERP ที่ควรหรือไม่ควรเกิดต้องตรงกับแบบที่อนุมัติแล้ว
ก่อนเปลี่ยนระบบ ให้ผู้รับผิดชอบลูกค้า คลัง คุณภาพ และบัญชียืนยันยอดตั้งต้นตามล็อตและภาชนะ แยกของกักกันและของคืนระหว่างทาง อย่าปิดส่วนต่างที่ยังหาสาเหตุไม่พบ สัปดาห์แรกกระทบยอดเหตุการณ์ทุกวัน และใช้การปิดเดือนแรกกับลูกค้าเป็นเงื่อนไขรับงาน การอบรมต้องจำลองว่าเมื่อพบความต่าง ใครหยุด ใครแจ้งลูกค้า และใครอนุมัติการแก้
สิทธิ์ ประวัติ และแผนเมื่อระบบขัดข้อง
ไม่ควรให้ทุกคนแก้ยอดเพื่อ “ทำให้ตรง” ผู้รับเข้าบันทึกจำนวน ฝ่ายคุณภาพกักกันและปล่อย ฝ่ายผลิตบันทึกเบิกและใช้ ผู้บริหารที่ได้รับสิทธิ์อนุมัติปรับยอด โรงงานเล็กอาจแยกหน้าที่ไม่ได้ทั้งหมด จึงใช้ผู้อนุมัติแทน การตรวจทวนภายหลัง เหตุผล และเก็บหลักฐานต้นทาง อย่าใช้สิทธิ์ administrator แบบไม่จำกัดในงานประจำ
จำกัดสิทธิ์ข้อมูลแยกลูกค้าในหน้าจอ ดาวน์โหลด และ API ลูกค้า A ไม่ควรเห็นวัสดุ ผลผลิต หรือข้อมูลต้นทุนของโรงงาน ประวัติต้องระบุใครเปลี่ยนรายการต้นทางใด จากค่าใดเป็นค่าใด เมื่อไร และจากอุปกรณ์ใด ถ้าใช้ใบกระดาษหรือเครื่องออฟไลน์เมื่อระบบดับ ต้องกำหนดเลขเอกสาร วิธีป้องกันซ้ำ ลำดับลงข้อมูลหลังฟื้น เครื่องหมายบนของจริง และการอนุมัติ ตอนกู้ระบบให้เทียบรหัสภาชนะกับเอกสารต้นทางก่อนบันทึกซ้ำ ระหว่างปิดเดือนที่ล้มเหลวต้องเห็นรายงานใดแน่นอนแล้วและข้อความใดยังไม่ส่ง
วัดจำนวนส่วนต่างค้าง ปริมาณหรือมูลค่าที่เสี่ยง เวลาหาสาเหตุ วันรออนุมัติลูกค้า อายุของกักกัน สัดส่วนการใช้จริงตามใบสั่ง และจำนวนคืนระหว่างทาง แยกตามลูกค้าและวัสดุ ตั้งเป้าจากฐานจริง ไม่สร้างค่าเฉลี่ยอุตสาหกรรมขึ้นมาเอง คำนวณผลตอบแทนจากเวลาที่ใช้กระทบยอด สืบส่วนต่าง แก้ใบแจ้งหนี้ และตอบลูกค้า แยกเงินสดที่ประหยัดได้จากการตัดสินใจเร็วขึ้น รวมค่าทดแทนอุปกรณ์ ฉลาก คลาวด์ การเฝ้าดูเชื่อมต่อ การเปลี่ยนข้อกำหนดลูกค้า และดูแลข้อมูลหลักในต้นทุน ตรวจผลหลังปิดเดือนแรกสำเร็จ
หากส่วนต่างเกิดจากการแปลงหน่วย ให้แก้ตารางแปลงและฉลาก หากพลาดการคืนจากไลน์ ให้แก้ตำแหน่งชั้นคืนและขั้นตอนสแกน เพิ่มแจ้งเตือนอย่างเดียวโดยไม่ปรับทางเดินของจริงอาจเพิ่มเพียงงานอนุมัติ วัดตัวชี้วัดเดิมในเดือนถัดไปเพื่อดูว่าสาเหตุย้ายไปจุดอื่นหรือไม่
จัดการการเปลี่ยนข้อกำหนดลูกค้าหลังเริ่มใช้
รหัสสินค้า รุ่นแบบ ฉลาก อัตราสูญเสียที่ยอมรับ และเงื่อนไขเรียกเก็บเงินเปลี่ยนได้ อย่าทำตามอีเมลในระบบเดียว บันทึกวันเริ่มใช้ ล็อตที่เกี่ยวข้อง ของเหลือ งานระหว่างผลิต การคำนวณใบสั่งเดิม และหลักฐานอนุมัติ ช่วงรุ่นเก่าและใหม่อยู่พร้อมกัน ให้แสดงชัดในฉลากและหน้าจอ แล้วทดสอบว่าล็อตใดใช้กับใบสั่งใดได้
การเพิ่มคอลัมน์รายงานหรือฟิลด์ API อาจทำให้ระบบลูกค้าอ่านผิด ต้องตกลงเวอร์ชันและทดสอบฝั่งรับ หากต้องแก้เหตุการณ์เดือนที่ปิดแล้ว ให้เก็บทั้งวันแก้และเดือนที่ได้รับผล ไม่เขียนทับรายงานเก่าเงียบ ๆ การควบคุมการเปลี่ยนควรอยู่ใน RFP และขั้นตอนดำเนินงานเพื่อรองรับลูกค้าใหม่ในอนาคต
คำถามที่พบบ่อย
ใช้รหัสสินค้าเดียวกับวัสดุที่บริษัทซื้อเองได้ไหม?
บางระบบทำได้ หากแยกเจ้าของ การประเมินมูลค่า บัญชี สถานะจอง และประเภทเรียกเก็บเงินได้แน่นอน แยกรหัสอย่างเดียวแต่ตามล็อตจริงไม่ได้ก็ไม่พอ ข้อสรุปบัญชีอาศัยสัญญาและผู้เชี่ยวชาญ
ต้องติดตามล็อตละเอียดเท่าไร?
พิจารณาข้อกำหนดลูกค้า ความเสี่ยงคุณภาพ และขอบเขตเรียกคืน อย่างน้อยควรพิจารณาความสัมพันธ์ระหว่างล็อตรับ รหัสและรุ่นสินค้า กับใบสั่งผลิต เพิ่มรหัสภาชนะเมื่อมีส่วนต่างรายกล่องหรือคืนบางส่วน ล็อตลูกค้าไม่ใช่รหัสการรับของโรงงาน
ใช้การตัดตาม BOM อัตโนมัติอย่างเดียวพอไหม?
อาจพอเมื่อมาตรฐานกับใช้จริงนิ่งและลูกค้ายอมรับระดับรายงาน แต่การทดลอง แก้งาน ของเสีย หยิบมือ และคืนบางส่วนอาจหายไป ให้เลือกตามวัสดุและกำหนดผู้อนุมัติส่วนต่าง
ประเมินต้นทุนระบบอย่างไร?
ขึ้นกับลูกค้า สินค้า สถานที่ ฉลาก ระบบเดิม ยอดตั้งต้น รายงาน ข้อยกเว้น เครื่องมือ การทดสอบ และอบรม ใช้สถานการณ์เดียวกันให้ผู้ขายสาธิตและเสนอราคาเป็นส่วน ๆ ราคาช่วงเดียวอาจปิดบังงานตามสัญญาที่สำคัญ
ต่างจากการส่งชิ้นส่วนให้ผู้รับจ้างช่วงอย่างไร?
กรณีจ้างช่วง บริษัทส่งวัสดุของตัวเองออกไปและติดตามที่ผู้รับจ้าง แต่กรณีนี้ลูกค้าส่งวัสดุเข้ามาโรงงานเรา การเคลื่อนย้ายคล้ายกันแต่เจ้าของ การรายงาน การคิดเงิน และความรับผิดกลับด้าน บริษัทที่ทำทั้งสองแบบต้องระบุเจ้าของกับคู่ธุรกรรมในทุกรายการ
สรุป
ระบบนี้สำเร็จเมื่อทั้งสองฝ่ายเริ่มจากล็อตและจำนวนที่ส่งมอบเดียวกัน แล้วไล่ยอดผ่านรับเข้า กักกัน พร้อมใช้ เบิก ใช้จริง ของเสีย คืน และแก้ไข ไปถึงยอดปิดและหลักฐานชำระเดียวกัน กำหนดกรรมสิทธิ์กับการเรียกเก็บเงินก่อน แยกเหตุการณ์ กำหนดระบบต้นฉบับ และทดสอบข้อยกเว้นใน FAT/SAT
TOMAS TECH สามารถเริ่มจากเอกสารและตารางกระทบยอดของโรงงานในประเทศไทย เพื่อจัดโครงสร้างเหตุการณ์ การสแกน และขอบเขตเชื่อม ERP/MES/WMS หากยังอยู่ก่อนทำ RFP สามารถแจ้งจุดที่ยอดต่างและเงื่อนไขรายงานของลูกค้าผ่านหน้าติดต่อได้
