ขอบเขตของ MES, ERP และ SCADA: แบ่งตามความรับผิดชอบหลักของวัตถุ ไม่ใช่ตามแผนก

ระบบสามชั้นตอบคำถามคนละเรื่อง

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

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

ใช้เมทริกซ์ความรับผิดชอบหลักของวัตถุกำจัดปัญหา ‘ใคร ๆ ก็ดู’

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

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

APS, WMS และ QMS ไม่ควรถูกยัดเข้า MES โดยค่าเริ่มต้น

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

ORPAON เซี่ยงไฮ้ทำงานบูรณาการหรือปรับแต่ง เช่น อัลกอริทึมจัดตารางผลิต อินเทอร์เฟซ WMS และการตรวจสอบย้อนกลับคุณภาพได้ตามโครงการ แต่ไม่ถือว่ามีผลิตภัณฑ์ APS, WMS หรือ QMS แบบอิสระที่พร้อมใช้งานแล้ว ข้อเสนอแนะควรระบุทีละรายการว่าระบบเดิมของลูกค้า ระบบบุคคลที่สาม หรือขอบเขตปรับแต่งของโครงการนี้เป็นผู้รับผิดชอบ และไม่ใช้คำว่า ‘รวมทั้งระบบ’ ปิดบังส่วนที่ยังว่าง

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

การออกแบบอินเทอร์เฟซต้องมีสัญญา การชดเชย และการกระทบยอด

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

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

ตรวจขอบเขตด้วยห่วงโซ่ธุรกิจต้นทางถึงปลายทางหนึ่งเส้น

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

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

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

หลีกเลี่ยงความเข้าใจผิดเรื่องการรวมทั้งระบบ การเรียลไทม์ และการซิงโครไนซ์สองทาง

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

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

• ไม่ใช้ชื่อซอฟต์แวร์แทนคำอธิบายความรับผิดชอบ
• ไม่วัดความครบถ้วนของอินเทอร์เฟซด้วยจำนวนฟิลด์
• ไม่ให้ SCADA รับธุรกรรมธุรกิจขององค์กรโดยตรงโดยไม่ผ่านการประเมิน
• ไม่ให้ MES สั่งการกระทำความเสี่ยงสูงโดยข้ามขอบเขตการควบคุมและความปลอดภัยที่มีอยู่
• ไม่เขียนฟังก์ชัน APS, WMS, QMS หรือ TPM ที่ยังไม่ยืนยันให้เป็นผลิตภัณฑ์มาตรฐานที่มีอยู่แล้ว