นำระบบตอบยืนยันกำหนดส่งมอบมาใช้ในโรงงาน: ออกแบบ ATP, CTP และการอนุมัติ

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

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

ทำไมคำตอบเรื่องกำหนดส่งมอบจึงไม่ตรงกัน

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

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

เอกสาร Order promising ของ Microsoft อธิบายว่าการใช้เวลานำมาตรฐานไม่พิจารณาสต็อกและอุปสงค์ที่ทราบแล้ว ขณะที่ ATP พิจารณาสต็อกที่ยังไม่ผูกพันและแผนรับเข้า/จ่ายออก ส่วน CTP พิจารณากำลังการผลิตด้วย เอกสาร Oracle Global Order Promising แสดงแหล่งอุปทานจากสต็อก การโอน การซื้อ และการผลิต ทั้งสองเป็นตัวอย่างการทำงานของผลิตภัณฑ์ ขั้นตอนอนุมัติและหลักฐานที่เสนอต่อจากนี้เป็นข้อกำหนดทางธุรกิจที่โรงงานต้องกำหนดเอง ไม่ใช่การอ้างว่าทุกผลิตภัณฑ์มีมาตรฐานเดียวกัน

ATP กับ CTP ตอบคำถามต่างกันอย่างไร

ATP (Available to Promise) ใช้พิจารณาว่า ณ วันหนึ่งยังมีจำนวนเท่าใดที่สามารถผูกพันกับลูกค้าเพิ่มได้ ต้องกำหนดกติกาว่าจะนับแผนรับเข้าอย่างไร หักยอดที่ยืนยันไปแล้วอย่างไร และตัดล็อตที่พักคุณภาพออกหรือไม่ CTP (Capable to Promise) ใช้พิจารณาว่าสินค้าที่ไม่มีอยู่จะผลิต ซื้อ หรือโอนมาได้เมื่อไร โดยคำนึงถึงวัตถุดิบและทรัพยากรที่มีจำกัด ผลลัพธ์จึงขึ้นอยู่กับเส้นทางการผลิต ปฏิทินเครื่องจักร การเปลี่ยนรุ่นการผลิต ของเสีย งานจ้างภายนอก และความน่าเชื่อถือของกำหนดรับวัตถุดิบ

การเปิดใช้ CTP ไม่ได้ทำให้วันที่ถูกต้องเสมอ Microsoft ระบุว่าขอบเขตกรณีที่ CTP รองรับต่างกันตาม planning engine ส่วน Oracle อธิบายว่าผลขึ้นอยู่กับ sourcing rule และ promising rule ที่ตั้งไว้ ดังนั้นการเลือกผลิตภัณฑ์ควรใช้ข้อมูลคำสั่งซื้อของโรงงานทดสอบ และถามว่า ข้อจำกัดใดถูกนำเข้าการคำนวณจริง หากข้อมูลวันรับวัตถุดิบหรือกำลังผลิตยังอัปเดตไม่ได้ การเริ่มจาก ATP พร้อมการอนุมัติของคนอาจเหมาะสมกว่า

วันที่ออกจากโรงงานไม่ใช่วันที่ถึงลูกค้า

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

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

กำหนดแหล่งข้อมูลหลักและความสดของข้อมูลก่อน

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

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

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

ประมาณการยอดสั่งซื้อไม่ใช่คำสั่งซื้อยืนยัน

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

แยกสถานะจากวันที่ขอจนถึงวันที่สัญญา

ช่อง “วันที่วางแผน” ช่องเดียวทำให้ร่างคำตอบทับสิ่งที่ส่งไปแล้ว ตัวอย่างสถานะที่ใช้ได้คือ REQUESTED, CALCULATED, REVIEW, APPROVED, SENT, ACKNOWLEDGED และ REVISED เป็นข้อเสนอในการออกแบบ ไม่ใช่รหัสมาตรฐานบังคับ การคำนวณได้วันที่ยังไม่ใช่การสัญญา งานด่วน การทำล่วงเวลา วัตถุดิบยังไม่ยืนยัน การเปลี่ยนลำดับลูกค้า การแบ่งส่ง หรือสินค้าทดแทน ต้องส่งให้ผู้มีอำนาจตามเกณฑ์ที่ตกลงไว้

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

จัดการการเปลี่ยนพร้อมกันและการจองชนกัน

จำนวนสั่งซื้อเปลี่ยนพร้อมกับวันรับวัสดุที่เลื่อนอาจทำให้ผลคำนวณไหว หากคำนวณทุกนาทีแล้วส่งอีเมลทุกผล ลูกค้าจะได้รับคำตอบสับสน ให้ระบุคำสั่งซื้อที่ได้รับผลกระทบ ปรับ “ตัวเลือกภายใน” และนำบรรทัดที่ยืนยันไปแล้วเข้าคิวตรวจการเปลี่ยน ส่งฉบับใหม่หลังอนุมัติเท่านั้น ใช้ Order ID, line ID และเวอร์ชันคำตอบเป็น idempotency key เพื่อไม่ให้ API ที่ส่งซ้ำออกคำตอบสองฉบับ

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

ตัวอย่างการตอบคำขอ 800 ชิ้น

ตัวเลขทั้งหมดต่อไปนี้เป็น สมมติฐาน ลูกค้าขอสินค้า A จำนวน 800 ชิ้นให้ถึงวันที่ 30 ตุลาคม มีสินค้าสำเร็จรูป 500 ชิ้น แต่ 200 ชิ้นยืนยันให้ลูกค้าอื่น และ 50 ชิ้นพักคุณภาพ ดังนั้นจำนวนที่ดูเหมือนใช้ได้คือ 500 − 200 − 50 = 250 ชิ้น มีแผนรับอีก 300 ชิ้นสัปดาห์หน้า แต่หากวันนั้นเป็นเพียงคำตอบชั่วคราวจากผู้ขาย จะนับเป็นอุปทานแน่นอนหรือไม่ต้องมีกฎรองรับ

สมมติว่าวัตถุดิบสำคัญสำหรับอีก 550 ชิ้นอาจเข้าวันที่ 24 ตุลาคม คอขวดผลิตได้วันละ 200 ชิ้นเริ่มวันที่ 25 แต่ต้องตั้งเครื่องครึ่งวัน ตรวจคุณภาพหนึ่งวัน และส่งของสองวัน การคูณเพียง 200 ชิ้น × 3 วัน แล้วตอบว่าถึง 28 ตุลาคมจะลืมงานก่อนและหลังผลิต วันหยุด การซ่อมเครื่อง และงานเดิมก็มีผล วันที่ CTP เสนอจึงต้องใช้ความแน่นอนของวัตถุดิบและปฏิทินกำลังผลิตจริง

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

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

เชื่อม ERP, MES, จัดซื้อ และโลจิสติกส์อย่างไร

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

อินเทอร์เฟซควรระบุ Order/line ID รุ่นสินค้า โรงงาน คลัง หน่วยนับ เขตเวลา เวอร์ชันคำตอบ และเวลาเหตุการณ์ สำหรับโรงงานไทยที่ส่งต่างประเทศ “ถึงวันที่ 30 ตุลาคม” ต้องระบุวันที่ตามเขตเวลาของลูกค้าและช่วงรับสินค้า การแปลงชิ้น กล่อง พาเลตต้องกำหนดการปัดเศษและจำนวนต่อบรรจุภัณฑ์ เหตุการณ์เก่าที่มาถึงช้าต้องไม่ทับคำตอบใหม่

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

เคารพช่วงตรึงแผนการผลิต

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

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

RFP ต้องถามและเปรียบเทียบอะไร

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

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

ต้นทุนต้องรวมการเชื่อม ERP/MES การทำความสะอาดข้อมูลหลัก ย้ายประวัติ หน้าจอไทย/อังกฤษ ขั้นตอนอนุมัติ EDI/อีเมลลูกค้า การเฝ้าระวัง การฝึกอบรม และบำรุงรักษา CTP ต้องมีข้อมูลกำลังผลิตที่เชื่อถือได้ เครื่องมือที่เก่งแต่ไม่มีปฏิทินทรัพยากรที่ถูกต้องไม่ช่วยให้โครงการสำเร็จ ขอใบเสนอราคาด้วยปริมาณบรรทัดสั่งซื้อ จำนวนโรงงาน จุดเชื่อม และจำนวนข้อยกเว้นในเงื่อนไขเดียวกัน แทนการอ้าง “ราคาเฉลี่ยตลาด” ที่ไม่มีหลักฐาน

FAT และ SAT ต้องทดสอบกรณีที่ล้มเหลวด้วย

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

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

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

วัดคุณภาพของคำสัญญา ไม่ใช่แค่จำนวนส่งออก

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

ตัวอย่าง สมมติ: เดิมตอบ 100 บรรทัดต่อวัน บรรทัดละ 12 นาที รวม 1,200 นาที หลังใช้ระบบ 70 บรรทัดปกติใช้ 4 นาทีและ 30 บรรทัดข้อยกเว้นใช้ 15 นาที รวม 70×4 + 30×15 = 730 นาที ต่าง 470 นาที นี่เป็นโมเดลภาระงาน ไม่ใช่ผลประหยัดที่วัดได้จริง ต้องรวมเวลารักษาข้อมูลหลักและแก้เหตุขัดข้อง แล้ววัดก่อน/หลังด้วยวิธีเดียวกัน

เริ่มใช้งานเป็นระยะอย่างไร

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

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

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

เอกสารและการควบคุมที่ต้องมีเมื่อเริ่มใช้

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

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

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

อย่านำวันที่คำนวณได้ไปสร้างข้อความถึงลูกค้าโดยตรง

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

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

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

ทำให้ข้อมูลตรงกันทุกภาษา

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

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

แสดงความมั่นใจของคำตอบอย่างไร

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

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

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

เริ่มวิเคราะห์ผลกระทบจากการล่าช้าหนึ่งรายการ

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

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

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

ระบบตอบกำหนดส่งมอบต่างจาก production scheduler อย่างไร?

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

ATP อย่างเดียวใช้ยืนยันวันของสินค้าผลิตตามสั่งได้ไหม?

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

ระบบอัตโนมัติทำให้ไม่ต้องอนุมัติโดยฝ่ายขายหรือไม่?

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

เมื่อพบว่าจะส่งช้า สามารถทับวันที่ยืนยันเดิมได้ไหม?

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

สรุป

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

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

เอกสารอ้างอิงหลัก

• Microsoft Learn: Order promising
• Microsoft Learn: Calculate order promising dates
• Microsoft Learn: Delivery alternatives
• Oracle: Overview of Global Order Promising
• Oracle: Specify lead times for assembly operations
• SAP Help: Advanced Available-to-Promise
• SAP Help: Supply Creation-Based Confirmation