4M + Fishbone + 5 Why ใช้อย่างไร? จากปัญหาไปสู่ Root Cause และ Corrective Action

ปัจจัยในกระบวนการผลิต 4 ด้าน ( 4M in Production Process)
4M + Fishbone + 5 Why ใช้อย่างไร? จากปัญหาไปสู่ Root Cause และ Corrective Action
เมื่อเกิดปัญหาในโรงงาน เช่น ของเสียเพิ่ม เครื่องจักรหยุด ผลิตไม่ทัน ลูกค้าร้องเรียน หรือคุณภาพสินค้าไม่สม่ำเสมอ หลายองค์กรทราบว่าควรทำ Root Cause Analysis แต่ปัญหาที่พบคือ “มีเครื่องมือหลายตัว แล้วควรใช้ตัวไหนก่อน?”
ในความเป็นจริง 4M, Fishbone Diagram และ 5 Why ไม่จำเป็นต้องแข่งขันกัน แต่สามารถนำมาใช้ต่อเนื่องกันได้อย่างเป็นระบบ เพราะแต่ละเครื่องมือทำหน้าที่ต่างกัน
4M → ช่วยกำหนดพื้นที่ที่ควรค้นหาสาเหตุ
Fishbone → ช่วยจัดโครงสร้าง Possible Causes และความสัมพันธ์ของสาเหตุ
5 Why → ช่วยเจาะลึก Causal Chain ของสาเหตุที่มีหลักฐานสนับสนุน
Verification → ใช้ข้อมูลและการทดลองยืนยันว่าสาเหตุนั้นสัมพันธ์กับปัญหาจริง
Corrective Action → จัดการสาเหตุเพื่อป้องกันการเกิดซ้ำ
ASQ อธิบายว่า Fishbone หรือ Cause-and-Effect Diagram เป็นเครื่องมือสำหรับค้นหาและจัดหมวดหมู่ สาเหตุที่เป็นไปได้หลายประการ ของปัญหา ส่วน 5 Why เป็นกระบวนการตั้งคำถามซ้ำเพื่อเจาะผ่านอาการของปัญหาไปสู่สาเหตุที่ลึกขึ้น และสามารถใช้ร่วมกับ Cause-and-Effect Diagram ได้ ดังนั้นแนวทางของบทความตอนนี้คือ
Problem → 4M → Fishbone → Data → 5 Why → Root Cause → Corrective Action → Verification → Standardization
ก่อนใช้เครื่องมือ ต้องกำหนดปัญหาให้ชัด ความผิดพลาดที่เกิดขึ้นบ่อยที่สุดในการวิเคราะห์ปัญหาไม่ได้อยู่ที่ Fishbone หรือ 5 Why แต่อยู่ก่อนหน้านั้น คือ Problem Statement ไม่ชัดเจน
ตัวอย่าง Problem Statement ที่ไม่ดี เช่น “ของเสียเยอะ” “เครื่องมีปัญหา” “พนักงานทำงานผิด” ข้อความเหล่านี้กว้างเกินไปและยังไม่มีข้อมูลเพียงพอสำหรับการวิเคราะห์ ควรเปลี่ยนเป็นคำอธิบายที่ระบุ What, Where, When และ Magnitude เช่น “Defect ประเภท Scratch ของ Product A ที่ Line 2 เพิ่มจากค่าเฉลี่ย 1.8% เป็น 7.6% ระหว่างวันที่ 10–12 สิงหาคม โดยเกิดสูงสุดที่เครื่อง M03” ตอนนี้ทีมงานรู้แล้วว่า
What: Scratch Defect
Where: Line 2 / M03
When: 10–12 สิงหาคม
How much: 1.8% → 7.6%
การกำหนด Current State ให้แคบและเฉพาะเจาะจงก่อนเริ่มถาม Why เป็นหลักสำคัญ เพราะหากปัญหายังกว้างเกินไป การถาม Why สามารถพาการวิเคราะห์ไปได้หลายทิศทางโดยไม่มีหลักฐานรองรับ Lean Enterprise Institute ก็เน้นประเด็นนี้ในการอธิบายการใช้ 5 Why เช่นกัน
ขั้นที่ 1 ใช้ 4M เปิดพื้นที่ค้นหาสาเหตุ
หลังจากกำหนด Problem Statement แล้ว จึงเริ่มตรวจสอบปัจจัยพื้นฐานของกระบวนการด้วย
Man – คน
Machine – เครื่องจักร
Material – วัตถุดิบ
Method – วิธีการ
4M มีการใช้ในงาน Manufacturing จริง เช่น งานวิจัยเกี่ยวกับ Manual Assembly Line ซึ่งใช้ Method, Machine, Man และ Material เป็นกรอบสำหรับวิเคราะห์องค์ประกอบของกระบวนการผลิต แต่สิ่งสำคัญคือ อย่าใช้ 4M เพื่อเดาสาเหตุ ให้ใช้เพื่อถามว่า “แต่ละด้านมีอะไรผิดปกติหรือเปลี่ยนแปลงจากสภาวะปกติ?”
ตัวอย่าง: Defect เพิ่มจาก 1.8% เป็น 7.6% สมมติทีมงานตรวจสอบ 4M แล้วพบข้อมูลดังนี้
|
4M |
สิ่งที่ตรวจพบ |
|---|---|
|
Man |
มี Operator ใหม่ 2 คนเริ่มงานวันที่ 9 |
|
Machine |
M03 เปลี่ยน Cutting Tool วันที่ 9 |
|
Material |
Material Lot B เริ่มใช้วันที่ 10 |
|
Method |
WI Revision และ Parameter ไม่มีการเปลี่ยน |
ตอนนี้เรามีสิ่งที่น่าสงสัยอย่างน้อย 3 เรื่อง Operator ใหม่, Tool ใหม่, Material Lot ใหม่, แต่ยังไม่ควรเขียนว่า Root Cause = Operator ใหม่ หรือ Root Cause = Material Lot ใหม่ เพราะทั้งหมดเป็นเพียง Potential Factors / Possible Causes นี่เป็นจุดที่ต้องเปลี่ยนจาก Brainstorming ไปสู่ Data Analysis
ขั้นที่ 2 Stratify ข้อมูลก่อนสร้างเรื่องราวของสาเหตุ
สมมติโรงงานมีเครื่องจักร 4 เครื่อง ทีมงานนำข้อมูล Defect มาแยกตาม Machine
|
Machine |
Production |
Defect |
Defect Rate |
|---|---|---|---|
|
M01 |
2,500 |
45 |
1.8% |
|
M02 |
2,400 |
50 |
2.1% |
|
M03 |
2,100 |
323 |
15.4% |
|
M04 |
3,000 |
60 |
2.0% |
ข้อมูลนี้มีประโยชน์มาก
ถ้า Material Lot B เป็นสาเหตุหลัก และทุกเครื่องใช้ Material เดียวกัน เราอาจคาดว่าจะพบปัญหากระจายในหลายเครื่อง
แต่ข้อมูลกลับชี้ว่า M03 = 15.4% ขณะที่เครื่องอื่นอยู่ประมาณ 2% ดังนั้นพื้นที่ค้นหาสาเหตุควรเริ่มแคบลงไปที่ “อะไรแตกต่างที่ M03?”
นี่คือเหตุผลที่ Root Cause Analysis ไม่ควรอาศัย Brainstorming อย่างเดียว ASQ จัด Stratification เป็นหนึ่งในเครื่องมือสำหรับแยกข้อมูลจากแหล่งต่าง ๆ เพื่อเปิดเผย Pattern หรือ Relationship ที่อาจถูกซ่อนอยู่ในข้อมูลรวม
ขั้นที่ 3 สร้าง Fishbone Diagram
เมื่อรู้ Problem และ Current State ชัดขึ้นแล้ว Fishbone Diagram จะช่วยจัด Possible Causes ให้เป็นระบบ สำหรับปัญหานี้ เราสามารถเริ่มจาก 4M
Man / Operator ใหม่, Training ไม่ครบ, Setup Skill ต่างกัน, Workload สูง, ตรวจสอบชิ้นงานไม่ทัน
Machine / Cutting Tool ใหม่, Tool Alignment, Fixture หลวม, Spindle Vibration, Machine Parameter
Material / Material Lot B, Hardness, Dimension, Surface Condition, Supplier Variation
Method / Setup Procedure, Cutting Parameter, Inspection Frequency, Tool Change Procedure, First-piece Approval
เมื่อวาดออกมาเป็น Fishbone ทุกคนจะเห็นภาพว่า ปัญหาเดียวสามารถมี Possible Causes จำนวนมาก
ASQ ระบุว่า Fishbone Diagram หรือ Ishikawa Diagram ใช้ระบุสาเหตุที่เป็นไปได้จำนวนมากและจัดความคิดเหล่านั้นออกเป็นหมวดหมู่ จึงเหมาะอย่างยิ่งสำหรับการจัดโครงสร้าง Brainstorming
แต่ต้องจำไว้ว่า สิ่งที่เขียนอยู่บน Fishbone ≠ Root Cause Fishbone เป็น แผนที่ของสิ่งที่ต้องตรวจสอบ
ขั้นที่ 4 เปลี่ยน Possible Cause เป็นสิ่งที่พิสูจน์ได้
หลัง Brainstorm แล้ว ไม่ควรประชุมโหวตว่า “ทุกคนคิดว่าอะไรน่าจะเป็นสาเหตุ?” ควรถามว่า “เราจะพิสูจน์หรือหักล้างแต่ละสมมติฐานอย่างไร?”
สามารถสร้างตารางง่าย ๆ ได้ดังนี้
|
Possible Cause |
วิธีตรวจสอบ |
ผล |
|---|---|---|
|
Operator ใหม่ |
เปรียบเทียบ Defect ตาม Operator |
ไม่สัมพันธ์ |
|
Material Lot B |
เปรียบเทียบ Lot A/B บนเครื่องอื่น |
ไม่พบความแตกต่างชัดเจน |
|
Machine Parameter |
ตรวจ History |
ไม่เปลี่ยน |
|
Fixture |
ตรวจ Dimension/Position |
ปกติ |
|
Tool Alignment |
ตรวจตำแหน่งหลัง Tool Change |
พบคลาดเคลื่อน |
นี่เป็นช่วงสำคัญมาก เราเริ่มจาก Possible Causes จำนวนมาก แต่ใช้ข้อมูลค่อย ๆ ตัดสิ่งที่ไม่สัมพันธ์กับปัญหาออก จนเหลือ Tool Alignment ของ M03 เป็น Candidate Cause ที่มีหลักฐานสนับสนุน จากนั้นจึงเหมาะที่จะใช้ 5 Why
ขั้นที่ 5 ใช้ 5 Why เจาะจาก Cause ไปสู่ Root Cause
5 Why คือเทคนิคการถาม “ทำไม?” ต่อเนื่องเพื่อเจาะจากอาการหรือสาเหตุระดับต้นไปยังสาเหตุที่ลึกขึ้น ASQ ระบุว่าจำนวนครั้งไม่จำเป็นต้องเท่ากับห้าครั้งเสมอไป อาจน้อยหรือมากกว่านั้นตามความจำเป็น Lean Enterprise Institute ก็อธิบายหลักเดียวกันว่า จุดสำคัญไม่ใช่ตัวเลขห้า แต่คือการถามต่อจนสามารถผ่านอาการที่เห็นไปถึงสาเหตุที่ควรจัดการเพื่อไม่ให้ปัญหาเกิดซ้ำ (Lean Enterprise Institute) ลองใช้กับกรณี M03
Problem M03 เกิด Scratch Defect 15.4%
Why 1 ทำไมชิ้นงานจึงเกิด Scratch? เพราะ Cutting Tool สัมผัสตำแหน่งผิวชิ้นงานผิดปกติ
Why 2 ทำไม Tool จึงสัมผัสผิดตำแหน่ง? เพราะ Tool Alignment คลาดเคลื่อนหลังการเปลี่ยน Tool
Why 3 ทำไม Alignment จึงคลาดเคลื่อนหลังเปลี่ยน Tool? เพราะ Technician Setup Tool ด้วยการอ้างอิงตำแหน่งด้วยตนเอง
Why 4 ทำไมจึงต้องอ้างอิงตำแหน่งด้วยตนเอง? เพราะ Tool Change Procedure ไม่มีขั้นตอนตรวจ Alignment ด้วย Master Gauge
Why 5 ทำไม Procedure จึงไม่มีขั้นตอนนี้? เพราะมาตรฐาน Tool Change เดิมกำหนดเพียงการติดตั้งและทดลองเดินเครื่อง แต่ไม่ได้กำหนด Alignment Verification ก่อน First-piece Approval
ตอนนี้ Root Cause เริ่มเปลี่ยนจาก “Technician ตั้ง Tool ผิด” ไปเป็น “Tool Change Standard ไม่มี Alignment Verification ที่สามารถตรวจจับการติดตั้งคลาดเคลื่อนก่อนเริ่มผลิต” ความแตกต่างนี้สำคัญมาก ถ้าหยุดที่ Why แรก เราจะแก้ผิดระดับ ลองดูผลลัพธ์ของการหยุดแต่ละระดับ
Why 1: Tool ผิดตำแหน่ง → ปรับ Tool
Why 2: Alignment คลาดเคลื่อน → สอน Technician ให้ตั้งตรง
Why 3: Setup ด้วย Manual Judgment → Training เพิ่ม แต่ถ้าเจาะต่อจนพบว่า
Standard ไม่มี Verification Step Corrective Action สามารถเปลี่ยนเป็น
กำหนด Alignment Check ด้วย Master Gauge + บันทึกผล + First-piece Approval ก่อน Release Production การแก้แบบหลังลดการพึ่งพาความจำและประสบการณ์ของคน 5 Why ไม่ได้แปลว่าต้องถาม “ทำไม” ให้ครบห้าครั้ง นี่เป็นความเข้าใจผิดที่พบได้บ่อย ถ้าถาม Why ครั้งที่ 3 แล้วมีหลักฐานชัดเจนและสามารถจัดการสาเหตุได้ ก็ไม่จำเป็นต้องสร้าง Why 4–5 ขึ้นมาเพื่อให้ครบจำนวน ในทางกลับกัน บางปัญหาอาจต้องถาม 6–8 ครั้ง Lean Enterprise Institute ระบุชัดว่า จำนวนห้าไม่ใช่สาระสำคัญ เป้าหมายคือการถามต่อจนผ่านอาการและไปถึงสาเหตุที่เหมาะสมต่อการแก้ไข (Lean Enterprise Institute) ดังนั้น 5 Why = วิธีคิด ไม่ใช่ แบบฟอร์มที่ต้องกรอกห้าบรรทัด
อย่าใช้ 5 Why ก่อนรู้ว่าควรถามเรื่องอะไร
นี่เป็นอีกข้อผิดพลาดสำคัญ สมมติ Problem คือ “Defect สูง” แล้วเริ่มทันทีว่า
Why? → Operator ทำผิด
Why? → Operator ไม่เข้าใจ
Why? → Training ไม่พอ
Why? → ไม่มี Training Plan
Why? → Management ไม่ให้ความสำคัญ
สุดท้าย Root Cause กลายเป็น “Management ไม่ให้ความสำคัญ” ดูเหมือนมีเหตุผล แต่ทั้งสายอาจเกิดจาก Assumption ตั้งแต่ Why แรก ถ้าข้อมูลจริงพบว่า Defect เกิดเฉพาะ M03 ไม่ว่า Operator คนไหนทำ สาย 5 Why ทั้งหมดก็ผิดทิศทางตั้งแต่ต้น Lean Enterprise Institute เตือนถึงปัญหานี้โดยเน้นว่าก่อนเริ่ม 5 Why ต้องเข้าใจ Current State ระบุ Point of Cause และทดสอบ Potential Factors ก่อน มิฉะนั้นการถาม Why สามารถพาไปสู่ข้อสรุปที่ผิดได้ ดังนั้นลำดับที่แข็งแรงกว่า คือ Data ก่อน Why
ขั้นที่ 6 กำหนด Corrective Action
เมื่อพบ Root Cause แล้ว ขั้นต่อไปคือกำหนดมาตรการที่จัดการกับสาเหตุจริง ในกรณีตัวอย่าง Root Cause คือ Tool Change Standard ไม่มี Alignment Verification ก่อน Release Production
Corrective Action อาจประกอบด้วย
1. เพิ่ม Alignment Verification ใน Tool Change WI
2. กำหนด Master Gauge สำหรับตรวจตำแหน่ง
3. กำหนด Acceptance Criteria
4. บันทึก Alignment Result ทุกครั้งหลัง Tool Change
5. ทำ First-piece Inspection ก่อน Mass Production
6. Training Technician ตาม WI Revision ใหม่
จะเห็นว่า Training ยังมีอยู่ แต่ ไม่ใช่ Corrective Action เพียงอย่างเดียว ระบบถูกเปลี่ยนให้สามารถควบคุมความผิดพลาดได้ดีขึ้น Correction กับ Corrective Action ต่างกันอย่างไร?
สองคำนี้มักถูกใช้ปะปนกัน สมมติ Tool Alignment ผิด
Correction
ปรับ Alignment ของ M03 ให้ถูกต้อง เป็นการจัดการกับปัญหาที่เกิดขึ้นแล้ว ส่วน Corrective Action แก้ Tool Change Procedure เพิ่ม Alignment Verification และ Control ก่อน Release Production เป็นการจัดการกับสาเหตุเพื่อป้องกันการเกิดซ้ำ ดังนั้น
Correction → แก้สิ่งที่ผิดอยู่ตอนนี้
Corrective Action → แก้สาเหตุเพื่อไม่ให้ปัญหาเดิมเกิดซ้ำ
การทำ Root Cause Analysis ที่ดีจึงไม่ควรจบเพียง “ทำให้เครื่องกลับมาผลิตได้”
ขั้นที่ 7 Verification – พิสูจน์ว่าแก้แล้วได้ผลจริง
หลังดำเนิน Corrective Action แล้วต้องกลับไปดู Output ก่อนแก้ M03 Defect = 15.4%
หลังปรับ Alignment และทดลองผลิต 1,000 ชิ้น Defect = 1.7%
จากนั้นติดตามต่ออีก 4 สัปดาห์
สัปดาห์ 1 = 1.8%
สัปดาห์ 2 = 1.5%
สัปดาห์ 3 = 1.9%
สัปดาห์ 4 = 1.6%
ตอนนี้เรามีหลักฐานว่า Process กลับเข้าสู่ระดับใกล้เคียงสภาวะปกติเดิม จึงสามารถกล่าวได้อย่างมีน้ำหนักมากขึ้นว่า Corrective Action มีประสิทธิผล ไม่ใช่เพียง “แก้แล้วคิดว่าน่าจะหาย”
ขั้นที่ 8 Standardization – ทำอย่างไรไม่ให้ปัญหากลับมา
หากแก้ M03 แล้วจบ ปัญหาเดียวกันอาจเกิดกับ M01, M02 หรือ M04 ในอนาคต จึงต้องถามต่อว่า “เครื่องอื่นมี Risk เดียวกันหรือไม่?” หากใช้งาน Tool Change Process แบบเดียวกัน ควร Horizontal Deployment ไปยังเครื่องอื่น
ตัวอย่าง
Update WI ทุกเครื่อง เพิ่ม Master Gauge, Training Technician ทุก Shift
เพิ่ม Alignment Check ใน PM / Tool Change Checklist, Audit หลังใช้งาน
Update Control Plan หากเกี่ยวข้อง นี่คือการเปลี่ยนจาก Fix One Problem ไปสู่ Improve the System
ตัวอย่างที่ 2: Machine Breakdown
ลองใช้กระบวนการเดียวกันกับปัญหา Maintenance, Problem Machine M05 หยุดจาก Motor Overload 3 ครั้งในหนึ่งสัปดาห์
4M / Fishbone
Man: Operator ใช้งานผิดหรือไม่?
Machine: Motor, Bearing, Lubrication ผิดปกติหรือไม่?
Material: Material Load สูงผิดปกติหรือไม่?
Method: Operating Condition และ Maintenance Standard ถูกต้องหรือไม่?
ตรวจข้อมูลแล้วพบ Bearing มีอุณหภูมิสูงผิดปกติ
จึงเริ่ม 5 Why
Why 1: ทำไม Motor Overload? → Bearing มี Resistance สูง
Why 2: ทำไม Bearing มี Resistance สูง? → Lubrication ไม่เพียงพอ
Why 3: ทำไม Lubrication ไม่เพียงพอ? → Lubrication Point นี้ไม่ได้รับการเติมตามรอบ
Why 4: ทำไมไม่ได้เติมตามรอบ? → จุดนี้ไม่มีอยู่ใน PM Checklist
ตอนนี้ Corrective Action ไม่ควรเป็นเพียง เปลี่ยน Bearing เพราะนั่นจัดการ Component ที่เสียไปแล้ว ควรตรวจสอบและปรับปรุง PM Standard / Checklist ด้วย
ตัวอย่างคลาสสิกของ 5 Why ที่ Taiichi Ohno ใช้อธิบายปัญหาเครื่องจักรหยุดก็แสดงหลักเดียวกัน คือ การถามต่อจาก Fuse ขาด ไปสู่ Overload, Lubrication, Pump และท้ายที่สุดไปถึงการป้องกันเศษโลหะเข้าสู่ระบบ เพื่อไม่หยุดอยู่กับการเปลี่ยน Fuse ซึ่งเป็นเพียงการจัดการอาการ
ตัวอย่างที่ 3: Customer Complaint
Problem ลูกค้าพบสินค้า Leak 12 ชิ้นจาก Lot 250815
เริ่มจาก 4M
Man: Operator Sealing
Machine: Sealing Machine
Material: Packaging Film
Method: Temperature / Pressure / Time
Fishbone ช่วยแตก Possible Causes จากนั้นตรวจข้อมูลพบ Complaint เริ่มหลังเปลี่ยน Film Lot แต่ Film ผ่าน Incoming Specification ทีมทดลอง Film ใหม่กับ Parameter เดิมพบ Leak สูง ทดลองปรับ Sealing Temperature ตาม Validation พบ Leak หายไป
เมื่อถาม Why ต่อ พบว่า
Material Specification ใหม่ยังอยู่ใน Acceptance Range แต่ Process Parameter ไม่ได้รับการ Revalidation หลัง Material Change Root Cause จึงไม่ควรเขียนง่าย ๆ ว่า “Supplier ส่ง Material ไม่ดี” เพราะ Material ผ่าน Specification ปัญหาที่แท้จริงอาจอยู่ที่ Material Change Management + Process Validation นี่เป็นตัวอย่างที่ดีว่า Root Cause สามารถเชื่อมโยงมากกว่าหนึ่ง M
4M กับ Fishbone ต่างกันอย่างไร?
สองคำนี้มักถูกพูดรวมกันจนดูเหมือนเป็นสิ่งเดียวกัน แต่จริง ๆ แล้ว 4M = Cause Categories ขณะที่ Fishbone = Diagram / Analysis Structure
เราสามารถใช้ 4M เป็นก้างหลักของ Fishbone ได้ แต่ Fishbone ไม่จำเป็นต้องใช้ 4M เสมอไป
ASQ ระบุว่าหมวดหมู่ของ Fishbone สามารถปรับให้เหมาะกับปัญหา และใน Manufacturing ยังพบชุด 6M ได้แก่ Materials, Machinery, Methods, Measurement, Manpower และ Mother Nature ดังนั้น 4M ช่วยตอบว่า “จะมองด้านไหนบ้าง?” Fishbone ช่วยตอบว่า “จะจัด Possible Causes ให้เห็นความสัมพันธ์อย่างไร?”
Fishbone กับ 5 Why ต่างกันอย่างไร?
Fishbone เหมาะกับการ กวาดกว้าง เพราะช่วยให้เห็น Possible Causes หลายด้านพร้อมกัน ส่วน 5 Why เหมาะกับการ เจาะลึก เพราะเดินตาม Causal Chain ของสาเหตุหนึ่งลงไปเรื่อย ๆ จึงสามารถจำง่าย ๆ ว่า
Fishbone = Breadth
5 Why = Depth
และเมื่อนำมารวมกัน
4M → กำหนดหมวด
Fishbone → กวาด Possible Causes
Data → เลือก Candidate Cause
5 Why → เจาะ Causal Chain
เป็น Workflow ที่นำไปใช้ในการประชุมแก้ปัญหาได้ง่าย
5 Why ไม่เหมาะกับทุกปัญหา
อีกเรื่องที่ควรระวังคือ ปัญหาในโรงงานไม่ได้มี Causal Chain เส้นเดียวเสมอไป
ตัวอย่าง Defect อาจเกิดเมื่อ Material Moisture สูง พร้อมกับ Temperature ต่ำ และ Cycle Time เร็วเกินไป แต่ละปัจจัยอยู่ใน Specification เมื่อเกิดแยกกัน แต่เมื่อเกิดพร้อมกันจึงทำให้ Defect สูง กรณีแบบนี้ การพยายามบังคับให้สร้าง 5 Why เป็นเส้นเดียวอาจทำให้มองข้าม Interaction Effects ปัญหาที่ซับซ้อนอาจต้องใช้เครื่องมืออื่นเพิ่มเติม เช่น Stratification, Pareto, Scatter Diagram, Statistical Analysis, DOE, FMEA หรือ Process Experiment
ASQ เองจัด Fishbone, Pareto และ Scatter Diagram เป็นเครื่องมือ Cause Analysis ที่สามารถใช้ประกอบ Root Cause Analysis ตามลักษณะของปัญหา ดังนั้น 5 Why เป็นเครื่องมือที่มีประโยชน์ แต่ไม่ใช่คำตอบสำหรับทุกปัญหา
แบบฟอร์มง่าย ๆ สำหรับประชุม Root Cause Analysis
สามารถใช้โครงสร้างนี้ได้ทันที
1. Problem Statement
เกิดอะไรขึ้น?
ที่ไหน?
เมื่อไร?
มากน้อยเท่าไร?
Standard คืออะไร?
Actual คืออะไร?
2. 4M Analysis
Man: ______
Machine: ______
Material: ______
Method: ______
3. Possible Causes
Cause A: ______
Cause B: ______
Cause C: ______
4. Verification
|
Possible Cause |
Evidence/Test |
Result |
|---|---|---|
|
Cause A |
______ |
Confirm / Reject |
|
Cause B |
______ |
Confirm / Reject |
|
Cause C |
______ |
Confirm / Reject |
5. 5 Why
Problem → Why? → Why? → Why? → Why? → Why?
6. Root Cause
Verified Root Cause: ______
7. Corrective Action
Action: ______
Owner: ______
Due Date: ______
8. Effectiveness Verification
Before: ______
After: ______
Monitoring Period: ______
9. Standardization
WI / SOP / Control Plan / PM / Training / Checklist ที่ต้อง Update: ______
ข้อผิดพลาดที่พบบ่อยในการใช้ 4M + Fishbone + 5 Why
1. เริ่มจากหาคนผิด
“Operator ทำผิด” มักเป็นจุดจบที่เร็วเกินไป ต้องถามต่อว่าทำไมระบบจึงเปิดโอกาสให้เกิดความผิดพลาด
2. Fishbone เต็มกระดาษ แต่ไม่มีข้อมูล
จำนวน Possible Causes ไม่ใช่ตัววัดคุณภาพของ Root Cause Analysis
3. เลือก Root Cause ด้วยการโหวต
ความคิดเห็นช่วยสร้าง Hypothesis แต่หลักฐานต้องเป็นตัวช่วยยืนยัน
4. บังคับ 5 Why ให้ครบห้าข้อ
จำนวน Why ไม่ใช่เป้าหมาย
5. ทุกปัญหาจบด้วย Training
ถ้าปัญหาเกิดจาก Fixture, Material Specification หรือ Method ที่ไม่ชัด Training อย่างเดียวไม่แก้สาเหตุ
6. แก้แล้วไม่วัดผล
ถ้าไม่มี Before–After Data เราไม่รู้ว่า Corrective Action ได้ผลจริงหรือไม่
7. แก้เครื่องเดียวแล้วจบ
ต้องตรวจว่า Similar Process มีความเสี่ยงเดียวกันหรือไม่
4M + Fishbone + 5 Why ต้องใช้เป็นกระบวนการ ไม่ใช่ใช้เป็นแบบฟอร์ม
4M, Fishbone และ 5 Why เป็นเครื่องมือพื้นฐานที่ทรงประโยชน์มากเมื่อใช้อย่างถูกลำดับ
4M ช่วยให้มองปัจจัยด้าน Man + Machine + Material + Method อย่างเป็นระบบ
Fishbone Diagram ช่วยแตก Possible Causes และจัดความสัมพันธ์ของสาเหตุ ASQ จัด Fishbone เป็นหนึ่งใน Seven Basic Quality Tools และอธิบายว่าใช้ระบุสาเหตุที่เป็นไปได้จำนวนมากของปัญหา (ASQ)
5 Why ช่วยเจาะลึกจากสาเหตุที่มีหลักฐานสนับสนุนไปตาม Causal Chain โดยไม่ควรยึดติดว่าต้องถามครบห้าครั้ง (Lean Enterprise Institute)
เมื่อนำทั้งสามมาใช้ร่วมกัน Workflow ที่แนะนำคือ
1. Define Problem
↓
2. Check 4M
↓
3. Build Fishbone
↓
4. Collect & Stratify Data
↓
5. Verify Possible Causes
↓
6. Apply 5 Why to Confirmed Cause
↓
7. Identify Root Cause
↓
8. Corrective Action
↓
9. Verify Effectiveness
↓
10. Standardize & Prevent Recurrence
สิ่งสำคัญที่สุดคืออย่าเปลี่ยน “สิ่งที่เราคิดว่าน่าจะเป็นสาเหตุ” ให้กลายเป็น “Root Cause” โดยไม่มีหลักฐาน
Root Cause Analysis ที่ดีจึงไม่ใช่การประชุมเพื่อหาคำตอบที่ทุกคนเห็นด้วย แต่คือกระบวนการ ตั้งสมมติฐาน → ตรวจสอบข้อเท็จจริง → พิสูจน์ความสัมพันธ์ → แก้สาเหตุ → ตรวจผล เมื่อทำได้เช่นนี้ 4M, Fishbone และ 5 Why จะไม่ใช่เพียงเครื่องมือในตำราหรือแบบฟอร์ม ISO แต่จะกลายเป็น ภาษากลางของการแก้ปัญหาอย่างเป็นระบบในโรงงาน
#4M #4MAnalysis #Fishbone #FishboneDiagram #IshikawaDiagram #5Why #FiveWhys #RootCause #RootCauseAnalysis #CorrectiveAction #ProblemSolving #QualityControl #QualityManagement #Manufacturing #ProductionManagement #LeanManufacturing #Kaizen #ContinuousImprovement #DefectReduction #บริหารการผลิต
.
-------------------------
สนใจเรื่องราวการจัดการธุรกิจเพิ่มเติมคลิกที่นี่
การจัดการธุรกิจ (Business Management)
ปัจจัยในกระบวนการผลิต (Production Process)
-------------------------


