ระบบควบคุมการเปลี่ยนแปลงคำสั่งซื้อของลูกค้าในโรงงาน

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

ขอบเขต: การเปลี่ยนแปลงหลังตกลงใบสั่งซื้อ

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

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

ระบบควบคุมการเปลี่ยนแปลงคำสั่งซื้อของลูกค้าในโรงงาน - figure 1

กำหนดแหล่งข้อมูลใบสั่งซื้อที่เชื่อถือได้ก่อนเลือกซอฟต์แวร์

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

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

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

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

ใช้งานเวิร์กโฟลว์เดียวสำหรับปริมาณ, วันที่, และข้อกำหนด พร้อมการตรวจสอบที่แตกต่างกัน

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

เก็บวันที่ส่งมอบที่ลูกค้าร้องขอ, วันที่ที่คำนวณได้ว่าเป็นไปได้, และวันที่ยืนยันสัญญาไว้เป็นฟิลด์แยกกัน เอกสารของ Microsoft เรื่อง order promising อธิบาย ATP ในแง่ของซัพพลายที่มีอยู่ และ CTP ในแง่วัสดุและกำลังการผลิต นอกจากนี้ยังแสดงให้เห็นว่าการอัปเดตไม่จำเป็นต้องคำนวณสัญญาใหม่หากวันที่เดิมยังเป็นไปได้ นี่เป็นลักษณะเฉพาะของผลิตภัณฑ์หนึ่ง ไม่ใช่พฤติกรรมสากลของ ERP ระบุให้ชัดเจนว่าระบบของคุณต้องคำนวณใหม่เมื่อใด ทั้งสำหรับคำขอก่อนหน้าและหลัง และใครเป็นผู้อนุมัติการตอบกลับ

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

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

การประเมินผลกระทบต้องแสดงตัวเลขและหลักฐานประกอบ

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

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

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

ระบบควบคุมการเปลี่ยนแปลงคำสั่งซื้อของลูกค้าในโรงงาน - figure 2

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

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

แยกอำนาจในการตอบกลับออกจากอำนาจในการดำเนินการ

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

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

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

ปล่อยเวอร์ชันที่ยืนยันแล้วเข้าสู่ ERP และ MES

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

OPC Foundation ภาพรวมของ ISA-95 อธิบายโมเดลข้อมูลระหว่างการวางแผนองค์กรและการดำเนินงานการผลิต โดยไม่ได้กำหนดขั้นตอนการเปลี่ยนแปลงคำสั่งนี้โดยเฉพาะ แต่มีประโยชน์เมื่อกำหนดขอบเขตระบบและรหัสประจำตัว เช่น คำสั่งซื้อ รายการ เวอร์ชัน คำสั่งงาน ล็อตหรือซีเรียล เวลาเหตุการณ์ และระบบต้นทาง ให้แต่ละการเปลี่ยนแปลงมี idempotency key เพื่อป้องกันการเปลี่ยนปริมาณซ้ำซ้อนจากการ retry; เก็บข้อความที่ล้มเหลวไว้ในคิวข้อยกเว้นที่สามารถกู้คืนได้

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

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

ระบบควบคุมการเปลี่ยนแปลงคำสั่งซื้อของลูกค้าในโรงงาน - figure 3

รักษาร่องรอยการตรวจสอบที่สามารถสร้างใหม่ได้

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

ประกาศ ISO 10013:2021 ของ ISO กล่าวถึงแนวทางสำหรับข้อมูลที่บันทึกในสภาพแวดล้อมดิจิทัล ภาพรวม ISO 9001:2026 ของ ISO เน้นความมุ่งเน้นลูกค้า แนวทางกระบวนการ การคิดเชิงความเสี่ยง และการปรับปรุง ทั้งสองแหล่งไม่ได้บังคับใช้หน้าจอเฉพาะที่อธิบายไว้ที่นี่ ช่องสำหรับเวอร์ชันที่เสนอ หลักฐาน การอนุมัติ และการติดตามเป็นการออกแบบเพื่อการสร้างกระบวนการตัดสินใจใหม่

หากต้องเชื่อมโยงกับสินค้าจริง ให้เชื่อมโยงหมายเลขล็อตหรือซีเรียลที่จัดส่งกับเวอร์ชันคำสั่งที่มีผลบังคับใช้ GS1 EPCIS 2.0.1 กำหนด TransactionEvent ที่เชื่อมโยงวัตถุจริงหรือดิจิทัลกับธุรกรรมทางธุรกิจ ซึ่งเป็นมาตรฐานอ้างอิงที่เป็นไปได้สำหรับการตรวจสอบย้อนกลับข้ามบริษัท ไม่ใช่ข้อบังคับให้ทุกโรงงานต้องใช้ EPCIS

สิ่งที่ควรใส่ใน RFP

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

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

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

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

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

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

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

จะจัดการกับคำขอเปลี่ยนแปลงที่ได้รับพร้อมกันอย่างไร

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

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

การตัดสินข้อยกเว้นที่ข้ามขอบเขตการมีผลบังคับ

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

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

ชุดข้อมูลทดสอบการรับมอบที่แนบกับ RFP

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

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

FAT และ SAT: ทดสอบการเปลี่ยนแปลงระหว่างการทำงาน

สำหรับ FAT ให้ปกปิดข้อมูลกรณีจริงและทดสอบการสร้าง V4 จาก V3 ที่ได้รับการยืนยันแล้ว, การคำนวณผลกระทบ, การอนุมัติ, การสร้างการตอบกลับลูกค้า, และการจำลองข้อความ ERP/MES การเพิ่มปริมาณควรแสดงให้เห็นถึงการขาดแคลนวัตถุดิบ; การเร่งวันควรแสดงข้อจำกัดด้านกำลังการผลิต ตรวจสอบว่าข้อเสนอที่ยังไม่ได้รับอนุมัติไม่สามารถส่งถึง MES, ผู้อนุมัติสามารถอ่านหลักฐานประกอบ, และการแก้ไขที่ถูกปฏิเสธจะไม่มีวันมีผลบังคับใช้

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

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

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

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

การทยอยเปิดใช้งานและการวัดผล

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

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

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

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

ควรคำนวณผลตอบแทนการลงทุนอย่างไร?

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

ฟังก์ชันเปลี่ยนแปลงใน ERP เดิมเพียงพอหรือไม่?

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

ควรแก้ไขคำสั่งผลิตเมื่อใด?

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

สรุป

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

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

แหล่งข้อมูล

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