ทำไมผู้ผลิตเซมิคอนดักเตอร์และอิเล็กทรอนิกส์ในเอเชียตะวันออกเฉียงใต้กำลังโตเกินกว่าที่ MES แบบเดิมจะรองรับได้

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

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

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

ทำไมกลุ่มนี้ถึงทำให้สมมติฐาน MES แบบเดิมพังทลาย

แนวคิด MES ส่วนใหญ่ — รวมถึงกรอบคิดเริ่มต้นของเราเอง — เริ่มจากโรงงานเดียว ชุดสายการผลิตที่ค่อนข้างคงที่ และโมเดล execution ที่บันทึก work order สถานะเครื่องจักร และจุดตรวจคุณภาพตามที่เกิดขึ้นจริง โมเดลนี้ใช้ได้ดีกับงานประกอบทั่วไปและการผลิตแบบ discrete

การผลิตเซมิคอนดักเตอร์และอิเล็กทรอนิกส์ขั้นสูงสร้างแรงกดดันต่อโมเดลนี้ใน 3 ทางที่เจาะจง:

High-mix และการเปลี่ยนรุ่นบ่อย โรงงานแพ็กเกจจิ้งหรือทดสอบที่ผลิตสินค้าหลายสิบรุ่นบนอุปกรณ์ร่วมกัน สร้าง production context ที่เปลี่ยนรูปแบบตลอดเวลา — พารามิเตอร์ recipe การตั้งค่า tooling และเกณฑ์การตรวจสอบที่ต่างกันไปในแต่ละสาย แต่ละรอบการผลิต schema เหตุการณ์ของ MES ที่สร้างขึ้นบนสมมติฐาน "สินค้าเดียวกัน recipe เดียวกัน ส่วนใหญ่แล้ว" จะเริ่มสูญเสียความแม่นยำอย่างรวดเร็ว

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

สัญญาณคุณภาพที่มีความหมายก็ต่อเมื่อมองในบริบท นี่คือส่วนที่สำคัญที่สุด และควรอธิบายให้เห็นภาพชัดเจน

ตัวอย่างที่เป็นรูปธรรม: ความเบี่ยงเบนของ yield ที่ไม่ได้เป็นอย่างที่มันดูเหมือน

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

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

นี่คือข้อโต้แย้งเชิงโครงสร้างสำหรับ connected manufacturing intelligence เหนือกว่า insight แบบแยกระบบ: MES ที่ปฏิบัติต่อข้อมูลการตรวจสอบ ข้อมูล telemetry ของอุปกรณ์ บันทึกการบำรุงรักษา และบันทึกผู้ปฏิบัติงานเป็น silo แยกจากกัน จะให้ root cause ที่ฟังดูสมเหตุสมผลแต่ผิด ส่วน MES ที่เชื่อมโยงข้อมูลเหล่านี้เป็น context เดียวที่ query ได้ จะสามารถหามันเจอได้จริง

flowchart TD
    A["ตรวจพบรูปแบบข้อบกพร่อง\nการตรวจสอบเวเฟอร์หรือแผงวงจร"] --> B{"มองแยกส่วนหรือไม่"}
    B -->|"ใช่"| C["ดูเหมือน recipe เลื่อน\nปรับ recipe แต่ข้อบกพร่องยังอยู่"]
    B -->|"ไม่ - context ที่เชื่อมโยงกัน"| D["เชื่อมโยงกับ telemetry อุปกรณ์\nประวัติอุณหภูมิ chamber บันทึกเครื่องมือ"]
    D --> E["เชื่อมโยงกับบันทึกการบำรุงรักษา\nและการกระทำของผู้ปฏิบัติงาน"]
    E --> F["Root cause: การเลื่อนของการสอบเทียบอุปกรณ์\nบนเครื่องมือเฉพาะ"]
    F --> G["แก้ไขแบบเจาะจง: สอบเทียบเครื่องมือใหม่\nไม่ใช่ recipe"]

สิ่งที่ "เชื่อมโยงกัน" ต้องการจริงๆ ใน Event Model

สถาปัตยกรรม MES ทั่วไปของเราเป็นแบบ event-driven โดยค่าเริ่มต้น — ทุกการกระทำที่สำคัญถูกบันทึกเป็น event ที่แก้ไขไม่ได้ โดยแดชบอร์ดและ OEE ถูกคำนวณจาก event stream นั้นแทนที่จะเป็นตาราง status ที่ถูกเขียนทับตลอดเวลา สำหรับการผลิตเซมิคอนดักเตอร์และอิเล็กทรอนิกส์แบบ high-mix หลายไซต์ พื้นฐาน event-driven เดียวกันนี้ต้องพก context เพิ่มเติมเป็น field หลัก ไม่ใช่สิ่งที่เพิ่มเข้ามาทีหลัง:

• ตัวตนและประวัติสถานะของอุปกรณ์ ไม่ใช่แค่ "เครื่องจักรกำลังทำงาน" — chamber ไหน เครื่องมือไหน ประวัติการสอบเทียบและบำรุงรักษาเป็นอย่างไร ณ เวลาที่ event เกิดขึ้น
• บริบท recipe และ lot ที่แนบไปกับทุก quality event เพื่อให้สามารถสืบย้อนข้อบกพร่องกลับไปยังชุดพารามิเตอร์และ lot วัตถุดิบที่แน่นอน ไม่ใช่แค่ "สายนี้ กะนี้"
• คีย์เชื่อมโยงข้ามไซต์ — รูปแบบตัวระบุร่วมที่ทำให้ quality event ที่ไซต์หนึ่งสามารถเชื่อมโยงกับข้อมูลอุปกรณ์และซัพพลายเออร์จากอีกไซต์ที่ป้อนเข้าสู่ production order เดียวกันได้
• บันทึกการกระทำของผู้ปฏิบัติงาน เป็น structured event ไม่ใช่บันทึกข้อความอิสระ เพื่อให้ "คนทำอะไรจริงๆ" สามารถ query ควบคู่กับ "อุปกรณ์ทำอะไร" ได้

ทั้งหมดนี้ไม่จำเป็นต้องละทิ้งการออกแบบ MES แบบ event-driven แต่ต้องออกแบบ event schema ล่วงหน้าให้พก context ที่การสืบสวน root-cause จะต้องใช้ในที่สุด แทนที่จะค้นพบช่องว่างนี้ระหว่างเกิด yield excursion จริง

ทำไม Multi-Site ถึงเปลี่ยนสถาปัตยกรรม ไม่ใช่แค่การ Deploy

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

ทางแก้ในทางปฏิบัติไม่ใช่ MES instance เดียวขนาดใหญ่ที่ครอบคลุมทุกไซต์ — นั่นสร้างปัญหา latency และ resilience ของตัวเอง แต่เป็น shared context layer: แต่ละไซต์รัน MES ของตัวเองเพื่อความเร็วในการ execution และ resilience ระดับท้องถิ่น แต่ event ด้านการผลิต คุณภาพ และอุปกรณ์จะไหลเข้าสู่ store ที่ query ได้ร่วมกัน ซึ่งรองรับการเชื่อมโยงข้ามไซต์สำหรับการสืบสวนแบบที่อธิบายไว้ข้างต้นได้พอดี นี่คล้ายกันในเชิงสถาปัตยกรรมกับวิธีที่ชั้น OEE หรือ reporting ที่ออกแบบมาอย่างดีแยก "การ execution ท้องถิ่นที่รวดเร็ว" ออกจาก "การวิเคราะห์ที่ลึกกว่าและช้ากว่า" อยู่แล้ว — การดำเนินงานเซมิคอนดักเตอร์หลายไซต์เพียงแค่ต้องนำการแยกส่วนแบบเดียวกันนี้มาใช้กับ root-cause และ quality intelligence ไม่ใช่แค่กับแดชบอร์ด

ความหมายในทางปฏิบัติ

หากการดำเนินงานของคุณเป็นสายการผลิตเดียวที่ผลิตสินค้าไม่กี่รุ่นที่ค่อนข้างคงที่ เรื่องทั้งหมดนี้ยังไม่เร่งด่วน — แนวคิด MES ทั่วไปยังใช้ได้อยู่ แต่หากคุณกำลังผลิตแบบ high-mix หลายไซต์ หรือมีเครือข่ายซัพพลายเออร์ที่ป้อนเข้าสู่ production order ร่วมกัน คำถามที่ควรถามก่อนการลงทุน MES ครั้งถัดไปจะต่างออกไป:

1. Event schema พก context ของอุปกรณ์ recipe และ lot เป็น field หลักหรือไม่ หรือเป็นแค่ metadata ที่ผูกเพิ่มทีหลัง
2. Quality event ที่ไซต์หนึ่งสามารถเชื่อมโยงกับข้อมูลอุปกรณ์และซัพพลายเออร์ที่อีกไซต์ได้หรือไม่ หรือ MES แต่ละไซต์เห็นแค่ตัวเอง
3. การกระทำของผู้ปฏิบัติงานถูกบันทึกเป็น structured event ที่ query ได้หรือไม่ หรือเป็นบันทึกข้อความอิสระที่ join กับ telemetry อุปกรณ์ไม่ได้
4. มี shared context layer ที่แท้จริงสำหรับการสืบสวนข้ามไซต์หรือไม่ หรือเป็นแค่ MES เดียวกัน N ชุดที่ชี้ไปยัง N ไซต์

MES ที่สร้างขึ้นเฉพาะ — ด้วย Python บนโครงสร้างพื้นฐานที่คุณควบคุมเอง deploy แบบ on-premise หรือ private cloud — ให้ความยืดหยุ่นในการออกแบบ event model รอบคำถามเหล่านี้ตั้งแต่วันแรก แทนที่จะทำงานภายใต้ข้อจำกัดของแพลตฟอร์มผู้จำหน่ายรายใหญ่ที่สร้างมาสำหรับโปรไฟล์การผลิตที่ต่างออกไป บริการพัฒนา MES ของเรา ถูกสร้างขึ้นโดยเฉพาะเพื่อสถาปัตยกรรมแบบ purpose-fit เช่นนี้ แทนที่จะเป็นการตั้งค่าแบบ one-size-fits-all

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

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

MES แบบ single-site ที่มีอยู่แล้วสามารถขยายให้รองรับการเชื่อมโยงหลายไซต์ในภายหลังได้หรือไม่ หรือต้องออกแบบตั้งแต่ต้น
ออกแบบตั้งแต่ต้นง่ายกว่า แต่ไม่ใช่ว่าเป็นไปไม่ได้ที่จะเพิ่มทีหลัง หาก event log พื้นฐานเป็นแบบ append-only จริงและพก context เพียงพอในแต่ละ event หากระบบที่มีอยู่เก็บแค่ current-state snapshot แทนที่จะเป็นประวัติ event เต็มรูปแบบ การเพิ่มการเชื่อมโยงข้ามไซต์ทีหลังมักหมายถึงการสร้าง data model ใหม่ ไม่ใช่แค่เพิ่มชั้น reporting ด้านบน

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

กำลังขยายการผลิตข้ามหลายไซต์ หรือเจอปัญหา yield ที่ไม่มีคำอธิบายจากระบบเดียวที่ชัดเจนอยู่ใช่ไหม? ติดต่อ Simplico →