การวิเคราะห์ปัญหาด้วย 4M และ Fishbone Diagram – จากอาการสู่ Root Cause
ปัจจัยในกระบวนการผลิต 4 ด้าน ( 4M in Production Process)
การวิเคราะห์ปัญหาด้วย 4M และ Fishbone Diagram – จากอาการสู่ Root Cause
เมื่อเข้าใจ Man, Machine, Material และ Method ครบทั้ง 4 ด้านแล้ว หนึ่งในการประยุกต์ใช้ 4M ที่สำคัญที่สุดคือ การวิเคราะห์ปัญหาในกระบวนการผลิต เพราะเมื่อเกิด Defect, Breakdown, Delay หรือ Productivity ลดลง สิ่งที่องค์กรต้องการไม่ใช่เพียงทำให้ปัญหาหายไปชั่วคราว แต่ต้องค้นหาให้ได้ว่า “อะไรคือสาเหตุที่แท้จริงของปัญหา” แนวคิดนี้เรียกว่า Root Cause Analysis (RCA) และเครื่องมือที่สามารถนำมาใช้ร่วมกับ 4M ได้อย่างมีประสิทธิภาพคือ Fishbone Diagram หรือ Ishikawa Diagram
หลักคิดสำคัญคือ
Problem → Possible Causes → Evidence → Root Cause → Corrective Action → Standardization
หรือพูดง่าย ๆ ว่า
“อย่ารีบแก้สิ่งที่เห็น จนกว่าจะรู้ว่าสิ่งที่เห็นเกิดจากอะไร”
อาการของปัญหาไม่ใช่ Root Cause ความผิดพลาดที่เกิดขึ้นบ่อยคือการนำ Symptom หรืออาการ ไปถือว่าเป็น Root Cause
ตัวอย่างเช่น เครื่องจักรหยุดทำงานเพราะ Motor ร้อนเกินไป หากทีมงานเปลี่ยน Motor แล้วเครื่องกลับมาทำงานได้ เราอาจคิดว่าปัญหาจบแล้ว แต่คำถามคือ
ทำไม Motor จึงร้อน?
เมื่อตรวจต่ออาจพบว่า Cooling Fan ไม่ทำงาน
แล้วทำไม Cooling Fan จึงไม่ทำงาน?
พบว่า Bearing ของ Fan เสีย
ทำไม Bearing จึงเสีย?
พบว่าไม่มีการหล่อลื่นตามระยะ
ทำไมไม่มีการหล่อลื่น?
พบว่า Fan ตัวนี้ไม่ได้อยู่ใน PM Checklist
ดังนั้น Root Cause อาจไม่ใช่ Motor เสีย แต่คือ ระบบ Preventive Maintenance ไม่ครอบคลุม Critical Component หากเปลี่ยน Motor อย่างเดียว ปัญหาก็มีโอกาสกลับมาอีก
ทำไมต้องใช้ 4M ในการวิเคราะห์ปัญหา
มนุษย์มีแนวโน้มจะมองหาสาเหตุที่เห็นง่ายที่สุด โดยเฉพาะในโรงงานมักเริ่มจากคำถามว่า “ใครทำผิด?” 4M ช่วยบังคับให้ทีมวิเคราะห์ มองรอบด้าน โดยพิจารณาอย่างน้อย 4 กลุ่ม
Man: คน ความรู้ ทักษะ พฤติกรรม ความเหนื่อยล้า การสื่อสาร
Machine: เครื่องจักร Tool, Jig, Fixture, Sensor, Calibration, Maintenance
Material: วัตถุดิบ Lot, Supplier, Specification, Storage, Handling
Method: ขั้นตอน WI, SOP, Parameter, Inspection Method, Control Plan
แทนที่จะรีบสรุปว่า Operator ทำผิด เราจึงสามารถถามว่า ระบบทั้งหมดมีส่วนทำให้ปัญหาเกิดขึ้นหรือไม่
Fishbone Diagram คืออะไร
Fishbone Diagram หรือ Cause-and-Effect Diagram / Ishikawa Diagram เป็นเครื่องมือสำหรับจัดระเบียบสาเหตุที่เป็นไปได้ของปัญหา โครงสร้างมีลักษณะคล้ายก้างปลา โดยส่วนหัวคือ Problem หรือ Effect และก้างหลักคือกลุ่มของสาเหตุ เมื่อนำ 4M มาใช้ ก้างหลักจะประกอบด้วย Man | Machine | Material | Method → Problem จากนั้นแตกสาเหตุย่อยออกจากแต่ละก้าง จุดประสงค์ของ Fishbone ไม่ใช่เพื่อบอกว่าอะไรคือ Root Cause ทันที แต่เพื่อช่วยทีมสร้าง รายการสมมติฐานของสาเหตุอย่างเป็นระบบ หลังจากนั้นต้องใช้ข้อมูลและหลักฐานพิสูจน์ต่อ
ตัวอย่าง: ของเสียเพิ่มขึ้นในกระบวนการฉีดพลาสติก สมมติโรงงานพบว่า Defect เพิ่มจาก 2% เป็น 7% โดยชิ้นงานมีรอยไหม้และสีไม่สม่ำเสมอ หากใช้ 4M สามารถระดมสาเหตุที่เป็นไปได้ เช่น
Man Operator ตั้ง Parameter ผิด, พนักงานใหม่ยังไม่มีประสบการณ์, ไม่มีการตรวจสอบค่าก่อน Start, พนักงานไม่ปฏิบัติตาม WI
Machine Heater ทำงานผิดปกติ, Temperature Sensor คลาดเคลื่อน, Cooling System มีปัญหา, Screw หรือ Barrel สึก
Material Resin มีความชื้นสูง, Material ผสมผิดสัดส่วน, ใช้ Material ผิด Lot, สี Masterbatch ไม่สม่ำเสมอ
Method Temperature Setting ไม่เหมาะสม, Drying Time ไม่เพียงพอ, Cycle Time เปลี่ยน, ไม่มีมาตรฐาน Purging ที่ชัดเจน
ตอนนี้เรามี Possible Causes จำนวนมาก แต่ยังไม่ควรเลือกสาเหตุจากความคิดเห็น ขั้นต่อไปคือ พิสูจน์ด้วยข้อมูล
Fishbone เป็นจุดเริ่มต้น ไม่ใช่คำตอบสุดท้าย
ข้อผิดพลาดอีกอย่างคือ หลังประชุม Brainstorm ทีมงานวงสาเหตุหนึ่งใน Fishbone แล้วประกาศว่า “นี่คือ Root Cause” แต่ Fishbone แสดงเพียง Possible Cause Root Cause ต้องมี Evidence รองรับ
ตัวอย่างทีมสงสัยว่า Defect เกิดจาก Material Moisture จึงต้องตรวจข้อมูล เช่น
Lot ที่มีปัญหาคือ Lot ใด?
Moisture เท่าไร?
Lot ที่ไม่มีปัญหามี Moisture เท่าไร?
เมื่อ Dry Material เพิ่ม Defect ลดลงหรือไม่?
หากข้อมูลแสดงว่า Lot ปกติมี Moisture 0.05% แต่ Lot ที่มีปัญหามี 0.20% และเมื่ออบ Material ตามมาตรฐานแล้ว Defect ลดจาก 7% เหลือ 1.5% สมมติฐานจึงมีหลักฐานรองรับมากขึ้น
หลักการคือ Opinion → Hypothesis → Data → Verification → Root Cause
5 Why – ถาม “ทำไม” ให้ลึกกว่าสิ่งที่เห็น
หลังจากระบุสาเหตุที่น่าสงสัยแล้ว สามารถใช้ 5 Why Analysis เพื่อเจาะลึกลงไป
ตัวอย่าง
Problem: เครื่องจักรหยุด
Why 1: ทำไมเครื่องหยุด? เพราะ Motor Overload
Why 2: ทำไม Motor Overload? เพราะ Bearing ฝืด
Why 3: ทำไม Bearing ฝืด? เพราะไม่มี Lubrication
Why 4: ทำไมไม่มี Lubrication? เพราะไม่ได้ทำ PM
Why 5: ทำไมไม่ได้ทำ PM? เพราะ Bearing จุดนี้ไม่ได้อยู่ใน PM Checklist
แนวทางแก้ที่ระดับอาการคือ Reset Motor
แนวทางแก้ระดับกลางคือ เปลี่ยน Bearing
แต่แนวทางป้องกันการเกิดซ้ำคือ ปรับ PM Standard และ Asset Checklist
นี่คือความแตกต่างระหว่าง Correction กับ Corrective Action
Correction กับ Corrective Action ต่างกันอย่างไร
Correction คือ การแก้ไขสิ่งผิดปกติที่เกิดขึ้นแล้ว
Corrective Action คือ การกำจัดสาเหตุเพื่อป้องกันไม่ให้ปัญหาเกิดซ้ำ
ตัวอย่างพบสินค้าติดฉลากผิด Correction คือเปลี่ยนฉลากให้ถูก Corrective Action อาจเป็นติดตั้ง Barcode Verification เพื่อป้องกันการใช้ฉลากผิดรุ่น หากทำเพียง Correction ปัญหาอาจกลับมาอีกในวันถัดไป
ตัวอย่าง Human Error ที่จริงอาจเป็น Method Error สมมติ Operator ใส่ชิ้นส่วนกลับด้าน หัวหน้างานอาจสรุปว่า Root Cause = Operator ไม่ระวัง และ Corrective Action คือ อบรมพนักงานใหม่ แต่เมื่อวิเคราะห์ 4M พบว่า
Man: พนักงานใหม่
Machine: Fixture ใส่ได้ทั้งสองด้าน
Material: ชิ้นส่วนสองด้านคล้ายกัน
Method: WI ไม่มีภาพบอก Orientation
ดังนั้น Human Error เป็นเพียงส่วนหนึ่งของระบบ แนวทางที่ดีกว่าอาจเป็น
ปรับ Fixture ให้ใส่ได้ทางเดียว
ทำ Marking บนชิ้นส่วน
เพิ่มภาพใน WI
ติด Sensor ตรวจ Orientation
วิธีเหล่านี้ทำให้กระบวนการ ไม่ต้องพึ่งความระมัดระวังของคนเพียงอย่างเดียว
เก็บข้อมูลก่อนประชุมวิเคราะห์
การวิเคราะห์ปัญหาที่ดีควรเริ่มจาก Fact ไม่ใช่ Feeling ข้อมูลที่ควรเก็บอาจประกอบด้วย
เกิดอะไรขึ้น?
เกิดเมื่อใด?
เกิดที่เครื่องใด?
เกิดกับ Product ใด?
เกิดกับ Material Lot ใด?
Operator คนใด?
Defect จำนวนเท่าไร?
ก่อนเกิดปัญหามีอะไรเปลี่ยนแปลง?
ตัวอย่าง Defect เกิด 500 ชิ้น หากตรวจพบว่า 480 ชิ้นผลิตจาก Machine M03 และ Material Lot R002 ข้อมูลนี้ช่วยจำกัดพื้นที่ค้นหาได้อย่างมาก
Pareto Chart – ปัญหาไหนควรแก้ก่อน
หากโรงงานมี Defect หลายประเภท ไม่ควรพยายามแก้ทุกเรื่องพร้อมกัน
สามารถใช้ Pareto Analysis ตามแนวคิด 80/20 เพื่อจัดลำดับความสำคัญ
ตัวอย่าง สมมติของเสียเดือนหนึ่งมี
Scratch = 450 ชิ้น
Dimension = 250 ชิ้น
Color = 150 ชิ้น
Crack = 100 ชิ้น
อื่น ๆ = 50 ชิ้น
Scratch เพียงประเภทเดียวคิดเป็น 45% ของ Defect ทั้งหมด ดังนั้นการเริ่มวิเคราะห์ Scratch ก่อนอาจสร้างผลลัพธ์มากกว่าการกระจายทรัพยากรไปแก้ทุกปัญหาพร้อมกัน หลักง่าย ๆ คือ
Pareto บอกว่า “ควรแก้อะไรก่อน”
Fishbone บอกว่า “อะไรอาจเป็นสาเหตุ”
5 Why ช่วยถามว่า “ทำไมจึงเกิด”
ตัวอย่างกรณีศึกษา: Defect สูงเฉพาะกะกลางคืน
โรงงานพบว่า Defect กะกลางวันอยู่ที่ 1.5% แต่กะกลางคืนอยู่ที่ 5% หากมองเร็ว ๆ อาจสรุปว่า “พนักงานกะกลางคืนทำงานไม่ดี”
แต่เมื่อวิเคราะห์ 4M พบว่า
Man: กะกลางคืนมีพนักงานใหม่มากกว่า
Machine: เครื่อง M02 มี Minor Stop บ่อยในช่วงกลางคืน
Material: ไม่พบความแตกต่างของ Lot
Method: เมื่อเครื่องหยุด กะกลางวันมี Technician ช่วยตั้งเครื่อง แต่กะกลางคืน Operator ต้อง Reset เอง
เมื่อตรวจข้อมูลเพิ่มเติมพบว่า Defect ส่วนใหญ่เกิดหลัง Minor Stop ของเครื่อง M02 Root Cause จึงเกี่ยวข้องกับ Restart Method และ Technical Support มากกว่าการเป็น “คนกะกลางคืนทำงานไม่ดี”
แนวทางแก้คือจัดทำ Restart Standard, Training Operator และปรับ Technical Support หลังดำเนินการ Defect กะกลางคืนลดเหลือประมาณ 1.8% นี่คือประโยชน์ของการใช้ข้อมูลแทนการตัดสินจากความรู้สึก
ตัวอย่างกรณีศึกษา: สินค้ารั่ว
สมมติโรงงานบรรจุของเหลวพบลูกค้าร้องเรียนว่าสินค้ารั่ว Fishbone อาจระบุ Possible Causes ได้ว่า
Man: Operator ตั้งเครื่องผิด
Machine: Sealing Jaw สึก หรือ Temperature Sensor คลาดเคลื่อน
Material: Film Thickness ไม่สม่ำเสมอ
Method: Temperature Standard ไม่เหมาะกับ Film Lot ใหม่
เมื่อตรวจสอบข้อมูลพบว่า Complaint เริ่มหลังเปลี่ยน Supplier Film และ Film ใหม่มี Thickness อยู่ใน Spec แต่คุณสมบัติการ Seal แตกต่างจากเดิม Method เดิมจึงไม่เหมาะกับ Material ใหม่
Root Cause จึงอาจเป็น การเปลี่ยน Material โดยไม่ได้ Validation Process Parameter ใหม่ กรณีนี้แสดงให้เห็นว่า Root Cause อาจเกิดจาก ความสัมพันธ์ระหว่าง Material กับ Method ไม่ใช่ M ตัวใดตัวหนึ่งอย่างโดดเดี่ยว
Root Cause ที่ดีควรผ่านการพิสูจน์
วิธีง่าย ๆ ในการตรวจสอบ Root Cause คือถามว่า ถ้าเรากำจัดสาเหตุนี้ ปัญหาควรลดลงหรือหายไปหรือไม่? และ หากเราสร้างเงื่อนไขเดิมขึ้นมา ปัญหาสามารถเกิดซ้ำได้หรือไม่?
ตัวอย่างสงสัยว่า Temperature สูงเป็น Root Cause ของรอยไหม้ ทีมงานทดลองปรับกลับเข้ามาตรฐานและ Defect หายไป จากนั้นทดลองเพิ่ม Temperature ภายใต้การควบคุมแล้ว Defect กลับมา หลักฐานเช่นนี้มีน้ำหนักมากกว่าการพูดว่า “ช่างคิดว่าน่าจะเป็นอุณหภูมิ”
Root Cause อาจมีมากกว่าหนึ่งสาเหตุ
ปัญหาในกระบวนการจริงมักไม่ได้เกิดจากสาเหตุเดียว
ตัวอย่างสินค้าเสียอาจต้องเกิดพร้อมกัน 3 เงื่อนไข
Material มี Moisture สูง
Drying Time ต่ำ
Machine Temperature สูง
หากเกิดเพียงเงื่อนไขเดียวอาจยังไม่เกิด Defect แต่เมื่อเกิดพร้อมกันจึงสร้างปัญหา ดังนั้นอย่าพยายามบังคับให้ทุกปัญหามี Root Cause เพียงข้อเดียว ควรมองทั้ง Cause และ Interaction ระหว่าง Causes
จาก Root Cause สู่ Corrective Action
เมื่อพบ Root Cause แล้ว ควรเลือก Corrective Action ที่ลดโอกาสเกิดซ้ำจริง โดยทั่วไปมาตรการที่พึ่งพาคนน้อยกว่ามักมีความน่าเชื่อถือมากกว่า
ตัวอย่างเรียงจากมาตรการที่อ่อนกว่าไปหาแข็งแรงกว่า
เตือนให้ระวัง → Training → Visual Control → Standardization → Alarm → Poka-Yoke → Automation / Interlock
สมมติ Operator เลือก Recipe ผิด
วิธีที่ 1 ติดป้าย “โปรดตรวจ Recipe ก่อน Start”
วิธีที่ 2 อบรมพนักงาน
วิธีที่ 3 ให้ Scan Product Barcode และระบบเลือก Recipe อัตโนมัติ
วิธีที่ 3 สามารถป้องกันความผิดพลาดได้ดีกว่า เพราะลดการพึ่งพาความจำของมนุษย์
ต้องติดตามผลหลังแก้ไข Corrective Action ไม่ถือว่าสำเร็จเพียงเพราะดำเนินการเสร็จ
ต้องตรวจสอบ Effectiveness
ตัวอย่าง Defect เดิม 8% หลังแก้ Root Cause เหลือ 1% หากผลลดลงอย่างต่อเนื่องแสดงว่ามาตรการมีประสิทธิผล แต่หาก Defect ยังอยู่ที่ 7% แสดงว่า Root Cause ที่เลือกอาจไม่ถูก หรือมาตรการยังไม่เพียงพอ วงจรจึงควรเป็น Analyze → Action → Measure → Verify → Standardize
ป้องกันปัญหาไม่ให้เกิดที่กระบวนการอื่น
เมื่อแก้ปัญหาได้แล้ว ไม่ควรหยุดอยู่เฉพาะเครื่องหรือ Line ที่เกิดปัญหา
ตัวอย่าง สมมติพบว่า Sensor รุ่นหนึ่งไม่มีอยู่ใน PM Checklist ของ Machine M01 หลังแก้ไข M01 แล้วควรตรวจต่อว่า Machine M02–M10 ใช้ Sensor แบบเดียวกันหรือไม่
แนวคิดนี้เรียกว่า Horizontal Deployment หรือ Yokoten คือการนำบทเรียนจากจุดหนึ่งไปป้องกันปัญหาในพื้นที่อื่น จากการแก้ปัญหา 1 ครั้ง จึงสามารถป้องกันปัญหาได้ทั้งโรงงาน
ขั้นตอนการวิเคราะห์ปัญหาด้วย 4M + Fishbone แบบใช้งานจริง สามารถสรุปเป็น 8 ขั้นตอนได้ดังนี้
1. Define Problem – ระบุปัญหาให้ชัดเจนและวัดได้
2. Collect Data – เก็บข้อมูลและหลักฐาน
3. Stratify Problem – แยกข้อมูลตามเวลา เครื่อง Lot คน Product หรือ Shift
4. Brainstorm with 4M – ระดม Possible Causes จาก Man, Machine, Material และ Method
5. Build Fishbone – จัดกลุ่มและแสดงความสัมพันธ์ของสาเหตุ
6. Verify Causes – ใช้ Data, 5 Why, Experiment หรือ Measurement พิสูจน์
7. Implement Corrective Action – กำจัด Root Cause
8. Verify & Standardize – ตรวจผลและปรับ SOP/WI/PM/Control Plan
นี่คือการเปลี่ยนจาก Problem Solving แบบเดา ไปสู่ Evidence-Based Problem Solving
4M + Fishbone Diagram เป็นเครื่องมือพื้นฐานที่มีประสิทธิภาพมากในการวิเคราะห์ปัญหา เพราะช่วยให้ทีมไม่รีบมองสาเหตุเพียงด้านเดียว แต่พิจารณาทั้ง Man, Machine, Material และ Method อย่างไรก็ตาม Fishbone ไม่ได้สร้าง Root Cause ให้เราโดยอัตโนมัติ สิ่งที่เขียนลงบนก้างปลายังเป็นเพียง Possible Causes ซึ่งต้องได้รับการพิสูจน์ด้วยข้อมูล ข้อเท็จจริง การวัด และการทดลอง หลักคิดสำคัญของตอนนี้คือ “อย่าแก้เพียงสิ่งที่เห็น แต่จงค้นหาว่าทำไมสิ่งนั้นจึงเกิดขึ้น” และเมื่อพบ Root Cause แล้ว อย่าหยุดเพียงการซ่อม แก้ หรืออบรม แต่ควรเปลี่ยนสิ่งที่เรียนรู้ให้กลายเป็น Standard, Poka-Yoke, Control Plan หรือระบบป้องกัน เพื่อไม่ให้ปัญหาเดิมกลับมาอีก เมื่อองค์กรสามารถทำเช่นนี้ได้ การแก้ปัญหาจะไม่ใช่เพียงกิจกรรมดับไฟรายวัน แต่จะกลายเป็นกระบวนการ Continuous Improvement ที่ทำให้ระบบการผลิตแข็งแรงขึ้นทุกครั้งที่เกิดปัญหา
แต่ในโลกของการผลิตไม่ได้มีเฉพาะปัญหาที่เกิดจากสิ่งผิดปกติเท่านั้น อีกหนึ่งช่วงเวลาที่มีความเสี่ยงสูงคือ “ตอนที่เรากำลังเปลี่ยนอะไรบางอย่าง” ไม่ว่าจะเปลี่ยนคน เครื่องจักร วัตถุดิบ หรือวิธีการ เพราะทุกการเปลี่ยนแปลงสามารถสร้างความแปรปรวนใหม่เข้าสู่กระบวนการได้
#4M #FishboneDiagram #IshikawaDiagram #RootCauseAnalysis #RCA #5Why #ProblemSolving #CorrectiveAction #Pareto #QualityControl #QualityManagement #ProductionManagement #Manufacturing #PokaYoke #PDCA #Kaizen #ContinuousImprovement #SmartFactory #วิเคราะห์ปัญหา #บริหารการผลิต
.
-------------------------
สนใจเรื่องราวการจัดการธุรกิจเพิ่มเติมคลิกที่นี่
การจัดการธุรกิจ (Business Management)
ปัจจัยในกระบวนการผลิต (Production Process)
-------------------------
