ระบบจัดซื้อชิ้นส่วนระยะเวลานานล่วงหน้า: แนวทางนำไปใช้ในโรงงาน

เมื่อจะนำการบริหารจัดการการสั่งซื้อชิ้นส่วนที่มี Lead Time ยาวล่วงหน้าเข้าสู่ระบบในโรงงานอุตสาหกรรมการผลิต สิ่งแรกที่ควรตัดสินใจไม่ใช่แค่ “ปุ่มสั่งซื้อเร็ว” แต่คือการกำหนดกระบวนการตัดสินใจว่า ใครจะเป็นผู้กำหนดความต้องการเบื้องต้นโดยอาศัยหลักฐานใด ในขณะที่แบบหรือ BOM ยังไม่แน่นอน จะให้สัญญากับซัพพลายเออร์ถึงระดับใด และใครจะเป็นผู้รับผิดชอบค่าใช้จ่ายกรณีเปลี่ยนแปลงหรือยกเลิก หากจุดนี้ไม่ชัดเจนแล้วนำ MRP ไปเชื่อมกับฝ่ายจัดซื้อ อาจเกิดการสั่งซื้อซ้ำซ้อนหรือมีสต็อกค้างโดยไม่ตั้งใจ ทั้งที่ต้องการป้องกันการขาดแคลน บทความนี้จัดทำขึ้นสำหรับผู้รับผิดชอบการคัดเลือกและนำระบบไปใช้ในโรงงานไทยและอาเซียน โดยจะเรียบเรียงขั้นตอนการออกแบบงาน, RFP, FAT/SAT ในหน่วยงานปฏิบัติจริง

ทำไมเฉพาะชิ้นส่วน Lead Time ยาวจึงไม่สามารถรอให้ BOM ยืนยันได้

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

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

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

แบ่งการสั่งซื้อล่วงหน้าออกเป็น 4 ขั้นตอน: “ความต้องการชั่วคราว”, “อนุมัติ”, “ข้อตกลงภายนอก”, “คำสั่งซื้ออย่างเป็นทางการ”

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

การแบ่งประเภทนี้ไม่ใช่ชื่อสถานะมาตรฐานของผลิตภัณฑ์เฉพาะ แต่เป็นตัวอย่างของการออกแบบกระบวนการที่กำหนดขึ้นในช่วงเริ่มต้นการนำระบบมาใช้ ในเอกสารของ SAP ได้อธิบายไว้ว่าหากแปลง Planned Order เป็น Purchase Requisition แล้ว Requisition นั้นจะไม่ถูกเปลี่ยนแปลงโดยอัตโนมัติในกระบวนการวางแผนถัดไป ในเอกสารของ Microsoft Dynamics 365 ได้แสดงให้เห็นว่าการอนุมัติและการยืนยัน Planned Order, Purchase Requisition และการอนุมัติ PO เป็นการดำเนินการที่แยกจากกัน พฤติกรรมจริงขึ้นอยู่กับผลิตภัณฑ์และการตั้งค่าที่เลือกใช้ ดังนั้นใน RFP จึงต้องตรวจสอบให้แน่ชัดว่า “สถานะใดถูกนำมาคำนวณเป็น Supply ใน MRP”

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

ระบบจัดซื้อชิ้นส่วนระยะเวลานานล่วงหน้า: แนวทางนำไปใช้ในโรงงาน - figure 1

จะสร้าง “ความต้องการชั่วคราว” ในกรณีที่แบบร่างยังไม่ยืนยันได้อย่างไร

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

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

ตัวอย่างเช่น ต้องการใช้ 100 ชิ้น มีโอกาสสูงที่จะเลือกใช้ตัวเลือก A แต่เวอร์ชันแบบร่างยังไม่ยืนยัน ระยะเวลาจัดซื้อมาตรฐานจากซัพพลายเออร์คือ 16 สัปดาห์ เหลือเวลาให้ลูกค้าอีก 12 สัปดาห์ ความต่าง 4 สัปดาห์นี้ยังไม่เพียงพอที่จะสั่งซื้อ PO 100 ชิ้นทันที ต้องตรวจสอบว่าสามารถจองโควตาที่สามารถยกเลิกได้ 50 ชิ้นหรือไม่, สามารถเปลี่ยนไปใช้ตัวเลือก B ได้หรือไม่, หรือจะมีการตัดสินใจเรื่องแบบร่างภายใน 2 สัปดาห์หรือไม่ ตัวเลขที่ยกตัวอย่างนี้เป็นสมมติฐานเพื่ออธิบายเท่านั้น ไม่ใช่ระยะเวลานำเข้า (Lead Time) หรือปริมาณสต็อกแนะนำโดยทั่วไป

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

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

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

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

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

ในเอกสารสาธารณะของ Microsoft Dynamics 365 หากเปิดใช้การจัดการการเปลี่ยนแปลง PO จะมีการไหลงานอนุมัติจากร่าง และการเปลี่ยนแปลง PO ที่อนุมัติแล้วจะถูกจัดการด้วยคำขอเปลี่ยนแปลงหรือกฎการอนุมัติใหม่ นอกจากนี้ สถานะการอนุมัติของ PO ที่สร้างจาก Planned Order ยังมีข้อยกเว้นตามการตั้งค่า เนื่องจากมีพฤติกรรมเฉพาะของแต่ละผลิตภัณฑ์ จึงไม่ควรสรุปว่า “มีฟังก์ชันอนุมัติในมาตรฐาน” แล้วถือว่าเพียงพอต่อความต้องการ ต้องทดสอบกับข้อมูลตัวอย่างว่ากระบวนการอนุมัติที่ต้องการสำหรับกรณีความต้องการชั่วคราวสามารถดำเนินการได้จริงหรือไม่

ระบบจัดซื้อชิ้นส่วนระยะเวลานานล่วงหน้า: แนวทางนำไปใช้ในโรงงาน - figure 2

กำหนดความรับผิดชอบค่าใช้จ่ายจากการเปลี่ยนแปลงหรือยกเลิกไว้ล่วงหน้า

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

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

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

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

การป้องกันการสั่งซื้อซ้ำซ้อนเมื่อเปลี่ยนจาก BOM อย่างเป็นทางการไปยังคำขอจัดซื้อของ MRP

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

ลำดับการดำเนินการพื้นฐานประกอบด้วย ① การอนุมัติรุ่นการออกแบบ ② การเปรียบเทียบความต้องการชั่วคราวกับรหัสสินค้าและปริมาณใน BOM ที่ยืนยันแล้ว ③ การเปรียบเทียบกับการจอง PO ที่คงเหลือและปริมาณที่รับเข้าแล้ว ④ ส่งเฉพาะส่วนต่างไปยัง MRP หรือฝ่ายจัดซื้อ ⑤ ปิดความต้องการชั่วคราวเดิมโดยระบุว่า “เปลี่ยนเป็นคำสั่งอย่างเป็นทางการแล้ว” หากจำเป็นต้องเปลี่ยนเพียงบางส่วน ให้แยกปริมาณเป็นรายบรรทัด เช่น หากจากความต้องการชั่วคราว 100 ชิ้น มี 60 ชิ้นที่ยืนยันเป็นสินค้า A และอีก 40 ชิ้นยังคงเป็นตัวเลือก B ห้ามปิดทั้ง 100 ชิ้นพร้อมกัน ต้องเชื่อมโยงเฉพาะ 60 ชิ้นที่ยืนยันแล้ว และเว้นระยะเวลาในการตัดสินใจสำหรับ 40 ชิ้นที่เหลือ

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

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

ระบบจัดซื้อชิ้นส่วนระยะเวลานานล่วงหน้า: แนวทางนำไปใช้ในโรงงาน - figure 3

ควรเขียนอะไรใน RFP สำหรับการนำระบบมาใช้

ขอบเขตข้อมูลระหว่างบัญชีสั่งซื้อล่วงหน้าและ ERP

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

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

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

กำหนดการรีวิวข้อยกเว้นรายวันเป็นข้อกำหนดการใช้งาน

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

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

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

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

รายการ RFP ขั้นต่ำ ได้แก่ การเชื่อมโยงระหว่าง ID ชั่วคราวกับรหัสสินค้าจริง, เวอร์ชัน BOM และวันที่มีผล, ช่วงจำนวนตามแต่ละโปรเจกต์, การแยกประเภทการจองแบบมีเงื่อนไข/แจ้งล่วงหน้า/PO, กำหนดเส้นตายการยกเลิกและวงเงินสูงสุด, การอนุมัติตามสิทธิ์, การวิเคราะห์ผลกระทบของการเปลี่ยนแปลง, การดึงข้อมูล PO คงเหลือ/สต็อก/งานระหว่างผลิต, การนับรวมซัพพลายใน MRP, การแปลงบางส่วน, การแจ้งเตือนการสั่งซื้อซ้ำซ้อน, ล็อกการตรวจสอบ, หลักฐานการแจ้งเตือนผู้ขาย, หน้าจอและการแจ้งเตือนภาษาไทย/อังกฤษ/ญี่ปุ่น, การเชื่อมต่อ API หรือไฟล์กับ ERP เดิม ไม่จำเป็นต้องติดตั้งทุกข้อในเฟสแรกของโครงการ ต้องกำหนดล่วงหน้าว่าจะตัดสินใจที่จุดใดในระบบเดิม และจะส่งอีเวนต์ไปที่ใด

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

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

FAT/SAT ควรมีการทดสอบสถานการณ์ใดบ้าง

ในการ FAT (Factory Acceptance Test) ไม่เพียงแต่ต้องตรวจสอบว่าหน้าจอสามารถบันทึกข้อมูลได้หรือไม่ แต่ยังต้องตรวจสอบด้วยว่าในกรณีข้อยกเว้น ข้อมูลจะไม่ขัดแย้งกันหรือไม่ ตัวอย่างเช่น สร้างกรณีทดสอบขึ้นมา 1 กรณี โดยกำหนดค่าตัวเลขเพื่ออธิบาย เช่น ความต้องการชั่วคราว 100 ชิ้น, การจอง 60 ชิ้น, จำนวนที่ต้องการหลังยืนยัน 80 ชิ้น, และของที่รับเข้าแล้ว 20 ชิ้น จากนั้นเมื่อคำนวณ MRP ใหม่ ให้ตรวจสอบว่าจำนวนที่เสนอเป็นส่วนต่างนั้นตรงกับค่าที่คาดหวังหรือไม่ เงื่อนไขที่ว่าการจองจะถือเป็นการจัดหาหรือไม่นั้น ขึ้นอยู่กับว่าเป็น “ได้รับการยืนยันจากซัพพลายเออร์แล้ว” หรือ “เฉพาะการอนุมัติภายใน” ซึ่งจะทำให้ผลลัพธ์แตกต่างกัน ดังนั้นควรเขียนค่าที่คาดหวังไว้ล่วงหน้า

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

SAT (Site Acceptance Test) จะดำเนินการด้วยรหัสสินค้า, คำตอบจากซัพพลายเออร์, วันหยุด, สกุลเงิน, ระบบอนุมัติ, และเครือข่ายจริงของโรงงานไทย แม้การเชื่อมโยงข้อมูลจะผ่านด้วยข้อมูลตัวอย่าง แต่ในสถานที่จริงอาจล้มเหลวเพราะจำนวนหลักของรหัสสินค้า, การระบุเวอร์ชัน, การแปลงหน่วย, หรือความแตกต่างของชื่อภาษาไทย ต้องตรวจสอบให้แน่ใจว่ารายการที่ฝ่ายจัดซื้อใช้ประจำวันจะแสดงสถานะเช่น ยังไม่ได้รับการยืนยันจากฝ่ายออกแบบ, รอคำตอบ, ใกล้ถึงกำหนดยกเลิก, หรือยังไม่ได้เปลี่ยนเป็นคำสั่งซื้ออย่างเป็นทางการ และมีการทบทวนประจำวัน FAT คือหลักฐานว่าระบบทำงานตามแบบที่ออกแบบไว้ ส่วน SAT คือหลักฐานว่าหน้างานสามารถทำงานจบได้จริงตามแบบนั้น

จะวัดผลตอบแทนจากการลงทุนอย่างไร

การวัดคุณค่าของระบบสั่งซื้อจัดหาล่วงหน้า ไม่สามารถดูแค่ “การออกใบสั่งซื้อเร็วขึ้นกี่นาที” เท่านั้น สิ่งที่ควรติดตามคือ จำนวนกรณีที่ส่งผลให้ส่งมอบล่าช้าเพราะชิ้นส่วน Lead Time ยาว, ค่าใช้จ่ายในการยกเลิกหรือค้างหลังเปลี่ยนแบบ, จำนวน PO ซ้ำสำหรับความต้องการเดียวกัน, ยอดคงเหลือของความต้องการชั่วคราวที่ยังไม่ได้เปลี่ยนเป็นคำสั่งซื้อ, เวลาที่ใช้จนถึงการอนุมัติ, เวลาที่ใช้จนถึงการยืนยันจากซัพพลายเออร์ หากสามารถเก็บค่ามาตรฐาน 3-6 เดือนก่อนใช้งานระบบใหม่ด้วยนิยามเดียวกัน จะเปรียบเทียบได้ง่ายขึ้น หากเก็บไม่ได้ ให้สร้าง baseline ช่วงทดสอบแยกต่างหาก และไม่ควรเขียนอัตราการปรับปรุงโดยการคาดเดา

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

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

หากต้องการดำเนินการติดตั้งใน 90 วัน

30 วันแรก ให้จำกัดกลุ่มชิ้นส่วนเป้าหมายและวัดสถานะปัจจุบัน ตรวจสอบประวัติงานที่ผ่านมาของสินค้าที่มี Lead Time ยาวที่สุด โดยเรียงลำดับวันที่ต้องใช้, วันที่ยืนยันแบบ, วันที่สอบถามซัพพลายเออร์ครั้งแรก, วันที่ออก PO, วันที่รับเข้า เลือกกรณีที่เกิดค่าใช้จ่ายยกเลิกจากการเปลี่ยนแบบ และกรณีที่เกิดการสั่งซื้อซ้ำอย่างละ 1 กรณี และตรวจสอบว่าความรับผิดชอบขาดตอนตรงจุดใด ในขั้นตอนนี้ หากพยายามแก้ไข Master ของทุกรหัสสินค้าพร้อมกันจะทำให้โครงการหยุดชะงัก ดังนั้นควรจำกัดเฉพาะกลุ่มชิ้นส่วนที่ต้องตัดสินใจสั่งซื้อล่วงหน้าจริง

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

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

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

ชิ้นส่วนที่ยังไม่ได้ข้อสรุปแบบควรสั่งจองล่วงหน้าด้วย PO อย่างเป็นทางการเสมอหรือไม่?

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

การอนุมัติใบขอซื้อ (PR) จาก MRP กับการอนุมัติสั่งจองล่วงหน้าเหมือนกันหรือไม่?

วัตถุประสงค์ต่างกัน ใบขอซื้อจาก MRP คือกระบวนการสั่งซื้อที่เกิดจากแผนและข้อมูลหลักที่ได้รับการยืนยันแล้ว ส่วนการอนุมัติสั่งจองล่วงหน้าคือการตัดสินใจว่าบริษัทจะรับความเสี่ยงมากน้อยแค่ไหนในกรณีที่สเปคหรือความต้องการยังไม่แน่นอน แม้จะใช้ Workflow เดียวกัน แต่ควรแยกหลักฐานที่ต้องใช้ วงเงินสูงสุด และเงื่อนไขการอนุมัติใหม่ให้ชัดเจน พฤติกรรมของการยืนยันแผนสั่งซื้อและการอนุมัติ PO อาจแตกต่างกันไปตามแต่ละผลิตภัณฑ์ ควรตรวจสอบกับระบบจริง

สามารถนำการจองล่วงหน้ามาคิดเป็นซัพพลายใน MRP ได้หรือไม่?

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

ใน RFP หรือ FAT/SAT ควรตรวจสอบสิ่งใดเป็นลำดับแรก?

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

สรุป

กรณีตัวอย่างสามแบบที่มักสร้างความสับสนในการปฏิบัติงาน

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

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

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

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

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

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

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

การสั่งจองล่วงหน้าสำหรับชิ้นส่วนที่มี Lead Time ยาว ไม่ใช่แค่การเร่งออก PO เท่านั้น แต่เป็นการบันทึกความต้องการที่ยังไม่แน่นอนโดยมีหลักฐานและเหตุผลรองรับ อนุมัติวงเงินที่บริษัทต้องรับผิดชอบ แยกข้อผูกพันกับซัพพลายเออร์ เก็บประวัติการเปลี่ยนแปลงแบบและการยกเลิก และเปลี่ยนเป็น BOM, MRP, ใบขอซื้ออย่างเป็นทางการเพียงครั้งเดียว ระบบที่นำมาใช้ควรเชื่อมโยงสถานะและประวัติทั้งหมดนี้ได้ RFP และ FAT/SAT ควรใช้กรณีข้อยกเว้นที่ยุ่งยากที่สุดเป็นข้อมูลทดสอบ

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

ข้อมูลอ้างอิง

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