iok2u.com แหล่งรวมข้อมูลข่าวสารเรื่องราวน่าสนใจเพื่อการศึกษาแลกเปลี่ยนและเรียนรู้

ยืนหยัด เข้มแข็ง และกล้าหาญ (Stay Strong & Be Brave)
ขอเป็นกำลังใจให้คนดีทุกคนในการต่อสู้ความอยุติธรรม ในยุคสังคมที่คดโกงยึดถึงประโยชน์ส่วนตนและพวกฟ้องมากกว่าผลประโยชน์ส่วนรวม จนหลายคนคิดว่าพวกด้านได้อายอดมักได้ดี แต่หากยึดคำในหลวงสอนไว้ในเรื่องการทำความดีเราจะมีความสุขครับ
Pay It Forward เป้าหมายเล็ก ๆ ในการส่งมอบความดีต่อ ๆ ไป
เว็ปไซต์นี้เกิดจากแรงบันดาลใจในภาพยนต์เรื่อง Pay It Forward ที่เล่าถึงการมีเป้าหมายเล็ก ๆ กำหนดไว้ให้ส่งมอบความดีต่อไปอีก 3 คน หากใครคิดว่ามันมีประโยชน์ก็สามารถนำไปเผยแพร่ต่อได้เลยโดยไม่ต้องตอบแทนกลับมา อยากให้ส่งต่อเพื่อถ่ายทอดต่อไป
มิสเตอร์เรน (Mr. Rain) และมิสเตอร์เชน (Mr. Chain)
Mr. Rain และ Mr. Chain สองพี่น้องในโลกออฟไลน์และออนไลน์ที่จะมาร่วมมือกันสร้างสื่อสารสนเทศ เพื่อเผยแพร่ให้ความรู้ในเรื่องราวต่างๆ มากมายสร้างสังคมในการเรียนรู้ หากใครคิดว่ามันมีประโยชน์ก็สามารถนำไปเผยแพร่ต่อได้เลยโดยไม่ต้องตอบแทนกลับมา

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 #บริหารการผลิต

.

-------------------------

ที่มาข้อมูล

-

ภาพและรวบรวมข้อมูล

www.iok2u.com

-------------------------

สนใจเรื่องราวการจัดการธุรกิจเพิ่มเติมคลิกที่นี่

การจัดการธุรกิจ (Business Management)

ปัจจัยในกระบวนการผลิต (Production Process)

-------------------------

 

ขอต้อนรับเข้าสู่เว็บไซต์
www.iok2u.com
แหล่งข้อมูลสารสนเทศเพื่อคุณ

เว็บไซต์ www.iok2u.com นี้เกิดมาจาก แรงบันดาลใจในภาพยนต์เรื่อง Pay It Forward โดยมีเป้าหมายเล็ก ๆ ที่กำหนดไว้ว่า ทุกครั้งที่เข้าเรียนสัมมนาหรืออบรมในแต่ละครั้ง จะนำความรู้มาจัดทำเป็นบทความอย่างน้อย 3 เรื่อง เพื่อมาลงในเว็บนี้
ความตั้งใจที่จะถ่ายทอดความรู้ที่ได้รับมาทำการถ่ายทอดต่อไป และหวังว่าจะมีคนมาอ่านแล้วเห็นว่ามีประโยชน์นำเอาไปใช้ได้ หากใครคิดว่ามันมีประโยชน์ก็สามารถนำไปเผยแพร่ต่อได้เลย โดยอาจไม่ต้องอ้างอิงที่มาหรือมาตอบแทนผู้จัด แต่ขอให้ส่งต่อหากคิดว่ามันดีหรือมีประโยชน์ เพื่อถ่ายทอดความรู้และสิ่งดี ๆ ต่อไปข้างหน้าต่อไป Pay It Forward