ระบบจัดสรรและจองสต็อกสำหรับโรงงาน: จากคำมั่นส่งมอบถึงจัดสรรใหม่

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

ระบบจองสต็อกต้องควบคุมอะไร

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

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

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

โควตาจัดสรรกับการจองตามคำสั่งซื้อไม่ใช่ข้อมูลเดียวกัน

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

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

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

อย่าบีบ “พร้อมขาย” ให้เป็นตัวเลขเดียว

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

ATP หรือ available-to-promise ประเมินอุปสงค์และอุปทานเพื่อเสนอวันส่งมอบ Oracle อธิบายว่า ATP rule ระบุแหล่งอุปทานที่ค้นหาได้ เช่น ของคงคลัง ใบสั่งซื้อจากซัพพลายเออร์ หรือคำสั่งงานจากโรงงาน และระบุความต้องการที่อุปทานนั้นรองรับได้ Oracle: Available-to-Promise Rules วันที่ ATP เสนอจึงไม่ใช่หลักฐานว่าคลังหยิบสินค้านั้นแล้ว หากใช้ของในอนาคตเป็นฐานคำมั่น ต้องกำหนดผู้รับผิดชอบคำนวณใหม่และแจ้งลูกค้าเมื่อการรับเข้าหรือการผลิตล่าช้า

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

ระบุเหตุการณ์ที่เปลี่ยนยอดพร้อมจอง

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

ตัวอย่าง soft reservation ของ Microsoft ให้หลายช่องทางสั่งซื้อเรียกดูจำนวนพร้อมจองจากจุดร่วมเดียว เมื่อจองสำเร็จ จำนวน soft reserved เพิ่มและจำนวนที่ยังจองได้ลดลง เมื่อคำสั่งซื้อเปลี่ยนเป็นการจองจริงใน ERP ต้องหักล้างรายการชั่วคราว ไม่ให้นับซ้ำ Microsoft: Inventory Visibility reservations

กำหนดสถานะตั้งแต่รับคำสั่งซื้อถึงจัดส่ง

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

การจองบางส่วนและหลายวันส่งเป็นงานปกติ

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

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

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

ตัดสินใจว่าจะล็อกล็อตและตำแหน่งเมื่อใด

คำสั่งซื้ออาจรับปากส่ง 10 ชิ้นจากคลังได้โดยยังไม่ล็อกชั้นวางหรือพาเลต หากคลังใช้ wave picking และ FIFO ให้คำสั่งซื้อล็อกโรงงาน คลัง และสถานะสต็อก แล้วให้ WMS เลือกตำแหน่งตอนหยิบ แต่ถ้าลูกค้าต้องการล็อต ซีเรียล วันหมดอายุ หรือใบรับรองเฉพาะ เงื่อนไขเหล่านั้นควรถูกผูกกับคำสั่งซื้อและการจองก่อน

เอกสาร Microsoft แยกลำดับการจองที่ฝ่ายความต้องการกำหนดโรงงาน คลัง และสถานะ แล้วตรรกะคลังเลือกตำแหน่ง ออกจากลำดับที่ต้องระบุล็อตหรือซีเรียลตามเงื่อนไขลูกค้าตั้งแต่คำสั่งซื้อ Microsoft: Flexible warehouse-level dimension reservation policy ล็อกละเอียดเกินไปทำให้ต้องคืนและจองใหม่ทุกครั้งที่ย้ายช่องเก็บ ล็อกหยาบเกินไปทำให้หยิบของผิดข้อกำหนดลูกค้า ต้องรวมการอนุมัติล็อตทดแทนและการแจ้งลูกค้าในกระบวนการ

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

แบ่งเจ้าของข้อมูลระหว่าง ERP, WMS และ MES

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

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

ป้องกันหักซ้ำเมื่อย้ายจากการจองชั่วคราวเป็นยืนยัน

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

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

ออกแบบการคืนและจัดสรรใหม่เป็นงานประจำ

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

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

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

เปรียบเทียบวิธีนำระบบมาใช้ด้วยพฤติกรรมจริง

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

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

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

เขียน RFP เป็นสถานการณ์ที่ทดสอบได้

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

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

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

FAT และ SAT ตรวจคนละขอบเขต

FAT ตรวจตรรกะและการเชื่อมต่อในสภาพแวดล้อมควบคุม: คำสั่งพร้อมกัน การจองบางส่วน การคืน การส่งซ้ำ สิทธิ และ audit log จำลอง timeout ที่ระบบปลายทางทำงานสำเร็จแต่คำตอบไม่กลับมา หน้าจอดูถูกต้องไม่พอถ้ายอดถูกหักซ้ำ ต้องเทียบก่อนและหลังตามสินค้า โรงงาน และล็อต

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

ย้ายคำมั่นค้างเปิด ไม่ใช่เพียงยอดสต็อก

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

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

วัดคุณภาพของคำมั่นหลังเริ่มใช้

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

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

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

การจองสต็อกต่างจากการจัดการสต็อกอย่างไร?

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

โควตาจัดสรรอย่างเดียวใช้ยืนยันวันส่งของลูกค้าได้หรือไม่?

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

คืนสิทธิแล้วของใช้กับคำสั่งอื่นได้ทันทีหรือไม่?

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

ERP หรือ WMS ควรเป็นเจ้าของการจอง?

แยกคำมั่นต่อลูกค้า การเลือกตำแหน่งและล็อตจริง และผลส่ง ERP หรือบริการร่วมอาจดูแลคำมั่น ส่วน WMS ดูแลการหยิบและผลจริง เลือกตามฟังก์ชันเดิม จำนวนช่องทาง ข้อจำกัดล็อต และเวลาหน่วงที่ยอมรับได้

ก่อนขอข้อเสนอควรเตรียมอะไร?

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

สรุป: กำหนดสถานะคำมั่นก่อนซื้อฟังก์ชันสต็อก

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

TOMAS TECH ช่วยโรงงานในไทยจัดแผนผังความรับผิดชอบระหว่างคำสั่งซื้อ สต็อก คลัง และการผลิต รวมทั้งเปลี่ยนกรณีการจองและคืนเป็น RFP และแผนทดสอบได้ สามารถปรึกษาเราได้ตั้งแต่ขั้นกำหนดขอบเขต

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

• Microsoft Learn: Reserve inventory quantities
• Microsoft Learn: Inventory Visibility reservations
• Microsoft Learn: Inventory Visibility inventory allocation
• Microsoft Learn: Flexible warehouse-level dimension reservation policy
• Oracle Supply Chain Planning: Available-to-Promise Rules