ระบบจัดการ MOQ สำหรับโรงงาน: ออกแบบ MRP จำนวนสั่งซื้อ และการอนุมัติข้อยกเว้น

การติดตั้งระบบจัดการปริมาณสั่งซื้อขั้นต่ำ หรือ MOQ (minimum order quantity) ในโรงงาน ไม่ได้จบที่การกรอกค่า “ขั้นต่ำ 100 ชิ้น” ในข้อมูลสินค้า หากความต้องการสุทธิอยู่ที่ 63 ชิ้น ผู้ขายกำหนด MOQ 100 ชิ้น และบรรจุภัณฑ์หนึ่งกล่องมี 24 ชิ้น ระบบ MRP ควรเสนอให้สั่งกี่ชิ้น ใครเป็นผู้อนุมัติส่วนเกิน และหากราคาต่อชิ้นลดลงเมื่อสั่งจำนวนมากขึ้นควรตัดสินใจอย่างไร ถ้าไม่ตอบคำถามเหล่านี้ร่วมกัน ผู้ซื้อจะยังต้องกลับไปคำนวณใน Excel แม้หน้าจอใหม่ดูเหมือนทำงานอัตโนมัติ บทความนี้อธิบายข้อกำหนดด้านข้อมูล กฎการตัดสินใจ และการทดสอบระบบสำหรับโรงงานในไทยและอาเซียน

MOQ ต่างจากจุดสั่งซื้อและจำนวนสั่งซื้อเป็นทวีคูณอย่างไร

จุดสั่งซื้อช่วยตอบว่า “ควรเริ่มเติมสินค้าเมื่อใด” ส่วน MOQ บอกจำนวนขั้นต่ำที่ผู้ขายยอมรับต่อคำสั่งซื้อหนึ่งครั้ง จำนวนสั่งซื้อเป็นทวีคูณ (order multiple) บอกช่วงเพิ่มของจำนวนที่อนุญาต ส่วนจำนวนต่อกล่องบอกข้อจำกัดทางกายภาพในการจัดส่ง สี่เงื่อนไขนี้ไม่ใช่ข้อมูลช่องเดียวกัน จุดสั่งซื้ออาจถูกต้อง แต่จำนวนที่ MRP คำนวณได้ยังต่ำกว่า MOQ ของผู้ขาย

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

เอกสาร Oracle Supply Planning อธิบาย Minimum Order Quantity และ Fixed Lot Multiplier แยกกัน ขณะที่เอกสาร Microsoft แยกค่า minimum, maximum และ multiple ในการตั้งค่าคำสั่งซื้อเริ่มต้น ตัวอย่างของผลิตภัณฑ์เหล่านี้ชี้ให้เห็นว่าควรเก็บข้อจำกัดแต่ละชนิดพร้อมหน่วยและช่วงเวลาที่มีผล แทนการรวมทุกอย่างเป็นช่อง “lot size” ช่องเดียว ดู คำอธิบาย order modifiers ของ Oracle และ default order settings ของ Microsoft

ต้องผูก MOQ กับผู้ขายและช่องทางสั่งซื้อที่ถูกต้อง

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

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

MRP ควรแปลงความต้องการสุทธิเป็นข้อเสนอที่สอดคล้องกับ MOQ อย่างไร

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

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

หน้าจอควรแสดงร่องรอย เช่น “ต้องการ 63 → MOQ 100 → กล่องละ 24 → เสนอ 120” ถ้าหน่วยซื้อคือกล่องแต่หน่วยสต็อกคือชิ้น ควรเห็น “5 กล่อง × 24 ชิ้น = 120 ชิ้น” SAP อธิบาย rounding profile สำหรับปัดปริมาณจัดซื้อให้สอดคล้องกับจำนวนที่ส่งหรือขนส่งได้ Microsoft ก็แยกการตั้งค่าหน่วยในคลังออกจากปริมาณสั่งซื้อ และเน้นความจำเป็นของการแปลงหน่วย หากไม่มีอัตราแปลง อย่าให้ระบบอนุมัติข้อเสนออัตโนมัติ ควรแจ้งให้แก้ข้อมูล SAP Rounding Profile และ คำอธิบายหน่วยของ Microsoft

เปรียบเทียบจำนวนที่สั่งได้จริง ไม่ใช่เลือกจำนวนต่ำสุดเสมอ

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

ตัวอย่างสมมติ: 120 ชิ้นราคาชิ้นละ 40 บาทเป็นเงิน 4,800 บาท ส่วน 240 ชิ้นราคาชิ้นละ 38 บาทเป็นเงิน 9,120 บาท แม้ราคาต่อชิ้นลดลง 2 บาท เงินที่จ่ายเพิ่มคือ 4,320 บาท และส่วนเกินจากความต้องการ 63 ชิ้นเพิ่มจาก 57 เป็น 177 ชิ้น หากมีคำสั่งผลิตที่ยืนยันว่าจะใช้ 177 ชิ้นในเดือนถัดไป การซื้อ 240 ชิ้นอาจสมเหตุสมผล แต่ถ้าไม่มีหลักฐานนั้น คำว่า “ราคาต่อชิ้นถูกกว่า” ยังอธิบายการตัดสินใจไม่ได้ ตัวเลขนี้เป็นเพียงตัวอย่างคำนวณ ไม่ใช่ราคาเสนอจริงหรือผลประหยัดที่รับประกัน

เชื่อมขั้นราคาเข้ากับการอนุมัติข้อยกเว้น

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

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

ตรวจสอบคำสั่งซื้อที่ป้อนด้วยมือด้วย

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

เขียนข้อกำหนดระบบจัดการ MOQ ใน RFP อย่างไร

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

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

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

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

ความถูกต้องของสต็อกเป็นเงื่อนไขตั้งต้น

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

โรงงานในอาเซียนต้องระบุหน่วย สกุลเงิน และวันที่สัญญา

อะไหล่นำเข้าอาจเสนอราคา USD มีต้นทุนในประเทศเป็น THB เก็บสต็อกเป็นชิ้น และสั่งเป็นกล่อง ค่า “MOQ 100” จึงกำกวมจนกว่าจะมีหน่วย เก็บอัตราแปลงพร้อมวันที่และหลักฐาน ระบุว่าจะรวมค่าขนส่ง อากร และภาษีหรือไม่ และใช้อัตราแลกเปลี่ยนวันที่ใด สำหรับวัสดุที่ต้องติดตามล็อตหรืออยู่ภายใต้เงื่อนไขนำเข้าเฉพาะ ส่วนเกินอาจย้ายไปใช้งานอื่นไม่ได้ง่าย นี่เป็นประเด็นออกแบบระบบ ไม่ใช่คำวินิจฉัยภาษีหรือศุลกากรเฉพาะราย

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

ประเมินต้นทุนและผลการติดตั้งอย่างไร

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

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

ลำดับติดตั้งภายใน 90 วัน

ช่วงที่ 1: นิยามเงื่อนไขผู้ขาย

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

ช่วงที่ 2: คำนวณคำสั่งซื้อย้อนหลัง

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

ช่วงที่ 3: เดินระบบคู่กับผู้ซื้อ

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

ช่วงที่ 4: ดูแลเงื่อนไขต่อเนื่อง

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

คำถามที่พบบ่อยเกี่ยวกับระบบ MOQ

MOQ กับ order multiple เหมือนกันหรือไม่

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

ถ้า MOQ ทำให้สต็อกเกินควรทำอย่างไร

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

มี MRP แล้วจำเป็นต้องซื้อระบบใหม่หรือไม่

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

ค่าใช้จ่ายติดตั้งเท่าไร

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

อนุญาตคำสั่งซื้อฉุกเฉินต่ำกว่า MOQ หรือไม่

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

ควรทบทวนเงื่อนไข MOQ บ่อยแค่ไหน

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

สรุป

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

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

แหล่งข้อมูล

• Oracle: Item Attributes and Order Modifiers for Supply Planning
• Microsoft: Default order settings
• Microsoft: Source products and materials from multiple vendors
• Microsoft: Set up unit sequence groups
• Microsoft: Purchase agreements
• SAP: Rounding Profile