Production: จาก Planned Order สู่สินค้าสำเร็จรูปในคลัง
แปดขั้นตอน ตั้งแต่คำขอผลิตที่ยังไม่ผูกพันอะไรเลย ไปจนถึง production order ที่ปิดสมบูรณ์ — บทนี้ตามรอยทุกสถานะ ทุกเอกสาร และทุกจุดที่กระทบบัญชี
1ภาพรวมแปดขั้นตอนของ Production
ตัวกระตุ้นเริ่มต้นมาจากสองแหล่งหลัก: Fulfillment (กรณี make-to-order — ต้องผลิตให้ทันคำสั่งซื้อลูกค้า) หรือ Material Planning (กรณี make-to-stock — ต้องเติมสต็อกให้เพียงพอ) นอกจากนี้ Project Management ก็กระตุ้นได้เช่นกัน (เช่นต้องผลิตชิ้นส่วนประกอบเครื่องบิน)
2Request Production: สร้าง Planned Order
ผู้ร้องขอระบุวัสดุที่ต้องการ ปริมาณ และเวลาที่ต้องการ — ระบบดึง master data ของวัสดุและ BOM มาผนวกเข้ากับ planned order อัตโนมัติ แล้วคำนวณข้อมูลเพิ่มเติมเช่นวันที่สั่งและความพร้อมของวัสดุ งานเดียวในขั้นนี้คือสร้าง Planned Order — เอกสารจะค้างอยู่ในระบบจนกว่าผู้มีอำนาจ (มักเป็นผู้จัดการฝ่ายผลิต) จะตัดสินใจ: ปฏิเสธ, แก้ไข, รวมกับ order อื่น, หรืออนุมัติให้ผลิต
3Authorize Production: สร้าง Production Order
Production Order ต่างจาก Planned Order ตรงที่เป็นข้อผูกพันจริงในการผลิตปริมาณที่ระบุภายในวันที่กำหนด — ทรัพยากรจำนวนมาก (วัสดุ work center PRT) ถูก "จอง" (commit) เพื่อการนี้โดยเฉพาะ มักสร้างโดยแปลงจาก planned order แต่ก็สร้างตรงได้โดยไม่อ้างอิง planned order เลยก็ได้ (เทียบเท่ากับสร้าง PO โดยไม่อ้างอิง requisition ใน Procurement)
สถานะของ Production Order: ลำดับที่ต้องจำ
| รหัสสถานะ | ชื่อเต็ม | ความหมาย |
|---|---|---|
| CRTD | Created | เพิ่งบันทึกสร้างขึ้น — goods movement และ confirmation ยังทำไม่ได้ |
| PREL | Partially Released | บาง operation ถูกปล่อยแล้ว (ปล่อยที่ระดับ operation แทน header) |
| REL | Released | ปล่อยเต็มรูปแบบ — พร้อมเริ่มขั้นตอนถัดไป |
| PCNF | Partially Confirmed | ยืนยันงานที่ทำเสร็จบางส่วนแล้ว |
| CNF | Confirmed | ยืนยันครบทั้งปริมาณที่สั่ง |
| PDLV | Partially Delivered | รับสินค้าสำเร็จรูปเข้าคลังบางส่วนแล้ว |
| DLV | Delivered | รับสินค้าสำเร็จรูปเข้าคลังครบแล้ว |
ข้อมูลใน Production Order
Order Header มี: เลขที่ order (unique), plant ที่ผลิต, scheduler (ผู้รับผิดชอบจัดตาราง), และสถานะ นอกจากนี้ยังมี operations (พร้อม work center และลำดับ — ต้องมีอย่างน้อยหนึ่ง operation เสมอ), capacity split (การกระจายงานระหว่างเครื่องจักร/คน), components (ส่วนใหญ่ดึงจาก BOM แต่แก้ไขเพิ่ม/ลดเองได้), PRTs ที่ต้องใช้, trigger points (จุดที่กระตุ้นกิจกรรมอื่นอัตโนมัติ), ค่าประมาณต้นทุนเบื้องต้น (material + overhead) ที่ผูกกับบัญชี GL, และลิงก์ไปยังเอกสารใน Document Management System (DMS) ถ้ามี
ผลลัพธ์ของการสร้าง Production Order
คำนวณวันที่แต่ละ operation ต้องทำ และ capacity ที่ work center ต้องใช้ — ใช้ข้อมูลจาก order (ปริมาณ วันที่) และพารามิเตอร์ work center (control key, standard value key) หากแก้ไข scheduling data ภายหลัง ระบบสามารถตั้งให้ reschedule อัตโนมัติได้
ตรวจว่าทรัพยากรที่ต้องใช้ (component, PRT, capacity) พร้อมหรือไม่ — ถ้าพร้อม ระบบสร้าง material/machine reservation กันไว้ ต่างจาก scheduling ตรงที่ availability check ไม่ repeat อัตโนมัติเมื่อ order เปลี่ยน ต้องสั่งตรวจสอบเองใหม่
คำนวณต้นทุนทางตรง (material, production) และทางอ้อม (overhead) เบื้องต้น — material cost มาจาก component ที่ผูกกับ order, production cost มาจาก activity type และสูตรใน work center
ถ้า order ต้องใช้ non-stock item (consumable) ระบบสร้าง purchase requisition ให้อัตโนมัติ — ถ้ามี operation ที่ต้องทำโดยบริษัทภายนอก (เช่น พ่นสี ขัดเงา) ก็สร้าง requisition แบบ subcontracting item category โดยมี production order เป็น cost object
3.5Order Release: ปลดล็อกให้เริ่มงานจริง
สถานะ Created จำกัดสิ่งที่ทำได้ (ยังทำ goods movement/confirmation ไม่ได้) — order ต้องถูก Release ก่อนถึงทำขั้นถัดไปได้ ระบบตั้งให้ปล่อยอัตโนมัติทันทีที่สร้างได้ หรือรอให้บริษัทตรวจสอบ/เตรียมพร้อมก่อนก็ได้ การปล่อยทำได้สองระดับ: Header Level (ปล่อยทุก operation พร้อมกัน) หรือ Operations Level (ปล่อยเฉพาะบาง operation — order จะมีสถานะ Partially Released) การปล่อยทำได้ทั้งแบบเดี่ยวหรือรวมกลุ่ม (individually/collectively)
ผลลัพธ์ของการปล่อย order คือสามารถพิมพ์ shop floor paper ได้ เช่น material withdrawal slip (ใบเบิกวัสดุ), time ticket (บันทึกเวลาที่ใช้ทำ operation), operations list (รายการ operation ที่ต้องทำ)
4Goods Issue: เบิกวัตถุดิบเข้าสายผลิต
ตัวกระตุ้นคือการปล่อย order — วัสดุที่เบิกได้ต้องเป็นวัสดุที่ (1) ถูก reserve ไว้แล้ว และ (2) ผูกกับ operation ที่ถูกปล่อยแล้วเท่านั้น งานหลักคือเบิกวัสดุจากคลังเข้าสู่ production order (บางครั้งต้องมี material staging เตรียมวัสดุก่อนใช้งานจริงด้วย)
5-6Production & Confirmation
การผลิตจริงเกิดขึ้นที่ shop floor ในระบบ ERP บางบริษัทเชื่อมกับระบบภายนอกอย่าง Plant Data Collection (PDC) เพื่อส่งข้อมูล order ไปยังหน้างานจริง เมื่อผลิตเสร็จ ผู้ปฏิบัติงานบันทึก Confirmation ซึ่งมีข้อมูล: ปริมาณที่ผลิตได้ (รวมของเสีย/scrap และของที่ต้องแก้ไข/rework), operation ที่ทำเสร็จ, ระยะเวลา (วันเวลาเริ่ม-จบ), work center ที่ใช้, บุคลากรที่ทำ, และเหตุผลของความคลาดเคลื่อนถ้าปริมาณยืนยันต่างจากที่วางแผนไว้
ห้ารูปแบบของ Confirmation
| รูปแบบ | ลักษณะ |
|---|---|
| Time Event Confirmation | บันทึกเวลา setup, processing, teardown — ทั้งเวลาเครื่องจักรและแรงงาน |
| Time Ticket Confirmation | บันทึกเป็นรอบ ๆ — ยืนยันบางส่วน (partial) ได้ เช่น order 30 หน่วย ยืนยันครั้งแรก 20 หน่วย ครั้งที่สอง 10 หน่วยที่เหลือ |
| Collective / Fast Entry | ยืนยันหลาย operation พร้อมกันในครั้งเดียว |
| Milestone Confirmation | การยืนยัน operation หนึ่งจะยืนยัน operation ก่อนหน้าอัตโนมัติ — เช่น operation ตรวจสอบคุณภาพ: หน่วยที่ผ่านตรวจถูกยืนยันย้อนไปยัง operation ก่อนหน้าด้วย ส่วนที่ไม่ผ่านถูกส่งไป rework |
| Progress Confirmation | รายงานความคืบหน้ารวมของ operation เป็นระยะ |
7Goods Receipt: รับสินค้าสำเร็จรูปเข้าคลัง
หลังผลิตเสร็จและ confirm แล้ว สินค้าสำเร็จรูปถูกนำเข้าคลังผ่าน goods receipt กับ production order — ระบบดึงข้อมูลจาก material master เพื่อกำหนดว่าอัปเดตบัญชี inventory ตัวไหน และตีราคาด้วยวิธีไหน (standard price หรือ moving average price) รวมถึงตรวจว่าจัดเก็บที่ตำแหน่งนั้นได้หรือไม่
8Periodic Processing และ Completion
Periodic Processing (หรือ period-end closing) ทำเป็นรอบ (เดือน/ไตรมาส) ครอบคลุม: Overhead Allocation (จัดสรรต้นทุนทางอ้อม เช่นค่าน้ำค่าไฟ เงินเดือนผู้บริหารที่ไม่เกี่ยวข้องโดยตรงกับการผลิต เข้า production order ตามกฎที่กำหนดไว้ล่วงหน้า), Work-in-Process (WIP) Determination (ระหว่างที่ order ยังไม่เสร็จ วัสดุ/สินค้าที่ยังไม่จบกระบวนการจะไม่นับเป็น inventory item ในงบดุล แต่จัดเป็น WIP แทน), และ Order Settlement (ผลต่างระหว่างเดบิตกับเครดิตรวมใน order เรียกว่า variance ต้อง settle โดยโพสต์เข้าบัญชี GL ที่เหมาะสม — manufacturing output settlement account ถูกเครดิตด้วยยอด variance)
สองมุมมองของ Completion
เมื่อไม่จำเป็นหรือไม่สามารถผลิตต่อได้อีก — reservation ที่ยังเปิดอยู่ถูกลบ ผลกระทบต่อกระบวนการอื่น (เช่น purchase requisition ที่เกี่ยวข้อง) ถูกยกเลิก วัสดุใน order ไม่ถูกนับรวมในแผนอีกต่อไป แต่ยังโพสต์บัญชีที่เกี่ยวกับ settlement ได้อยู่
เกิดขึ้นหลัง order ถูก settle ครบแล้ว — ต้องอยู่ในสถานะ Released หรือ Technically Complete มาก่อน หลังปิดแล้วไม่สามารถประมวลผลหรือโพสต์การเงินใด ๆ เพิ่มได้อีก (order ที่ปิดแล้วจะถูก archive และลบออกจากระบบตามรอบ แต่เรียกดูย้อนหลังได้)
9การรายงาน: Stock/Requirements List
รายงานฝั่งการผลิตครอบคลุม work list (งานที่ต้องทำ), online list (เอกสารตามชั้นข้อมูล/master data), รายงานสถานะ planned/production order, capacity availability/utilization, material consumption — รายงานที่สำคัญที่สุดคือ Stock/Requirements List ซึ่งรวบรวมกิจกรรมทั้งหมดในระบบที่อาจกระทบปริมาณวัสดุในคลัง (เป็นจุดเชื่อมโดยตรงกับ Material Planning ซึ่งขยายความในหัวข้อถัดไป)
10Material Requirements Planning (MRP): แนวคิดสำคัญที่ผูกทุกอย่างเข้าด้วยกัน
BOM Explosion: การไล่คำนวณความต้องการแบบเวียนซ้ำ
เมื่อมี demand สำหรับสินค้าสำเร็จรูป MRP ต้อง "ระเบิด" BOM ออกเป็นชั้น ๆ (BOM Explosion) — คำนวณความต้องการของสินค้ากึ่งสำเร็จรูปและวัตถุดิบทุกระดับที่ประกอบกันเป็นสินค้าสำเร็จรูปนั้น กระบวนการนี้เป็นการไล่ผ่านโครงสร้างต้นไม้/กราฟแบบเวียนซ้ำ (recursive) และมีข้อควรระวังทางเทคนิคสองข้อ:
ถ้าโครงสร้าง BOM มีการอ้างอิงวนกลับ (เช่น A ใช้ B และ B ใช้ A ทางอ้อม) การไล่คำนวณแบบ recursive จะวนไม่จบ — ระบบ ERP ต้องมีกลไกตรวจจับและป้องกัน cycle ในโครงสร้าง BOM
ถ้าวัสดุตัวเดียวกัน (เช่น น็อตมาตรฐาน) ถูกใช้ในหลายกิ่งของ BOM เดียวกัน การไล่คำนวณต้องรวม (aggregate) ความต้องการจากทุกกิ่งให้ถูกต้อง ไม่ใช่คำนวณซ้ำหรือนับตกหล่น — นี่คือเหตุผลที่ MRP ต้องมองความต้องการวัสดุเป็น "กราฟ" (ที่โหนดใช้ซ้ำได้) ไม่ใช่ "ต้นไม้" (tree) อย่างเคร่งครัด
Safety Stock และการตัดสินใจ Lot Size
Safety Stock คือสต็อกกันชนที่เก็บไว้เผื่อความไม่แน่นอนของ demand หรือ lead time — ยิ่งตั้ง safety stock สูง ความเสี่ยง stock-out ยิ่งต่ำ แต่ต้นทุนถือครองสินค้าคงคลัง (inventory holding cost) ยิ่งสูงตาม การตั้งค่านี้จึงเป็นการ trade-off ระหว่างระดับบริการ (service level) กับต้นทุน
Lot Size (ปริมาณต่อรอบการสั่ง/ผลิต) ก็มี trade-off เช่นกัน: สั่ง/ผลิตปริมาณมากต่อรอบ → ลดความถี่และต้นทุนการตั้งค่า/สั่งซื้อ (setup cost) ต่อหน่วย แต่เพิ่มต้นทุนถือครองสินค้าคงคลังเพราะต้องเก็บของไว้นานขึ้น ส่วนปริมาณน้อยต่อรอบ → กลับกัน (setup cost ต่อหน่วยสูงขึ้น แต่ inventory cost ต่ำลง) — นี่คือแนวคิดเดียวกับ Economic Order Quantity (EOQ) ในวิชา Operations Management
11เชื่อมกับศัพท์ ERP ค่ายอื่นและ Odoo
| ศัพท์ SAP | ศัพท์ทั่วไป / Odoo |
|---|---|
| Planned Order | Manufacturing Order (Draft) / Procurement Proposal |
| Production Order | Manufacturing Order (MO — Odoo ไม่แยก planned/authorized เป็นสอง object ชัดเจนเท่า SAP) |
| Backflushing | Automatic Consumption (Odoo: ตั้งค่า "Consumption" เป็น Flexible/Strict บน BOM) |
| MRP (Material Requirements Planning) | MRP (Odoo มี MRP Scheduler ในตัว ทำงานคล้ายกันมาก — รันการคำนวณ replenishment อัตโนมัติเป็นรอบ) |
12ทันสมัย: การผลิตยุค 2026
- เรียงลำดับแปดขั้นตอนของ Production และอธิบายว่าขั้นไหนที่เริ่มมีผลกระทบทางบัญชีเป็นครั้งแรก
- อธิบายสถานะทั้งเจ็ดของ Production Order (CRTD, PREL, REL, PCNF, CNF, PDLV, DLV) เรียงตามลำดับที่เกิดขึ้นจริง
- อธิบาย Backflushing และเหตุผลที่บริษัทจำนวนมากเลือกใช้เทคนิคนี้แทนการติดตาม goods issue แบบละเอียด
- อธิบายความแตกต่างระหว่างสถานะ Technically Complete (TECO) กับ Closed (CLSD)
- อธิบาย BOM Explosion และความเสี่ยงสองข้อ (cycle, double-counting) ที่ระบบ MRP ต้องจัดการ
- อธิบาย trade-off ของการตั้งค่า Safety Stock และ Lot Size