Root Cause Analysis (RCA) คือกระบวนการค้นหาสาเหตุที่แท้จริงของปัญหา ไม่ใช่แค่แก้อาการที่มองเห็น เพื่อให้การแก้ไขแก้ตรงจุดและป้องกันปัญหาเดิมไม่ให้เกิดซ้ำ

Root Cause Analysis วิธีใช้ 5 Why ค้นหาสาเหตุจริงของปัญหา ไม่แก้แค่ปลายเหตุ

“เซิร์ฟเวอร์ล่ม แก้แล้ว ปัญหาจบ”
“ลูกค้า complain ขอโทษแล้ว ปัญหาจบ”
“พนักงานทำผิดพลาด training แล้ว ปัญหาจบ”

จริงหรือ?

ถ้า 3 เดือนต่อมาปัญหาเดิมกลับมา — นั่นแปลว่าคุณไม่ได้แก้ปัญหา คุณแค่แก้อาการ

Root Cause Analysis คือกระบวนการที่ช่วยให้คุณขุดลงไปหาสาเหตุที่แท้จริง ที่อยู่ลึกกว่าสิ่งที่มองเห็นในทันที เพื่อให้การแก้ไขนั้นถาวร ไม่ใช่ชั่วคราว

ทำไมการแก้แค่ “อาการ” ถึงไม่พอ

ลองนึกถึงอาการเจ็บหัว:

แก้อาการ: กินยาแก้ปวด
แก้ root cause: พบว่าเจ็บหัวเพราะนอนน้อย → ปรับ routine การนอน

แก้อาการให้ผลเร็วกว่า แต่ปัญหาจะกลับมาเรื่อยๆ จนกว่าจะแก้ที่ต้นเหตุ

ในองค์กรก็เหมือนกัน:

ปัญหา	แก้แค่อาการ	แก้ Root Cause
ยอดขายลด	ลดราคา หรือ push sales team มากขึ้น	วิเคราะห์ว่า customer churn มาจากอะไร?
พนักงานลาออกสูง	ขึ้นเงินเดือน	ค้นหาว่า engagement ต่ำจาก culture หรือ manager?
Process ผิดพลาดบ่อย	training พนักงาน	ออกแบบ process ใหม่ที่ error-proof
Project ส่งช้าทุกครั้ง	เพิ่มคน	แก้ที่ planning และ scope management

5 Why Method: เครื่องมือ RCA ที่ง่ายและทรงพลังที่สุด

5 Why คือวิธีค้นหา root cause โดยการถาม “ทำไม?” ซ้ำๆ จนกว่าจะพบสาเหตุที่แท้จริง พัฒนาโดย Sakichi Toyoda และ Toyota Production System ใช้กันทั่วโลกตั้งแต่สายการผลิตไปจนถึง startup เทคโนโลยี

หลักการ: ปัญหาส่วนใหญ่มีชั้นของสาเหตุ 3-5 ชั้น การถาม “ทำไม?” 5 ครั้งมักพาคุณไปถึงสาเหตุที่แท้จริงในชั้นที่ 4-5

ตัวอย่าง 5 Why แบบ Step-by-Step

ปัญหา: รายงานประจำเดือนส่งผู้บริหารช้ากว่ากำหนด 3 วันทุกเดือน

Why 1: ทำไมรายงานส่งช้า?
→ เพราะทีมรวบรวมข้อมูลจากหลายแผนกไม่ทัน

Why 2: ทำไมรวบรวมข้อมูลไม่ทัน?
→ เพราะแผนกบางแผนกส่งข้อมูลมาช้า

Why 3: ทำไมแผนกส่งข้อมูลมาช้า?
→ เพราะไม่รู้ว่ามี deadline และไม่รู้ว่าต้องส่งข้อมูลอะไรบ้าง

Why 4: ทำไมถึงไม่รู้ deadline และ requirements?
→ เพราะไม่มีการแจ้งล่วงหน้าเป็นระบบ แจ้งแค่ปากเปล่าหรือ ad hoc

Why 5: ทำไมถึงไม่มีระบบแจ้งล่วงหน้า?
→ เพราะไม่มีใคร own process นี้อย่างเป็นทางการ

Root Cause ที่แท้จริง: ไม่มีเจ้าของ process ที่ชัดเจนและไม่มีระบบ communication ที่เป็น standard

การแก้ปัญหาที่ถูกจุด:
– กำหนด process owner ชัดเจน
– สร้าง automated reminder system 7 วันก่อน deadline
– ทำ data template ให้ทุกแผนกกรอกแบบเดิมทุกเดือน
– วาง SLA ว่าแต่ละแผนกต้องส่งภายในวันไหน

ถ้าแก้แค่อาการ (เช่น โทรตาม remind ทุกเดือน) ปัญหาจะเกิดซ้ำทุกครั้ง

วิธีทำ 5 Why ให้ถูกต้อง: 6 หลักการสำคัญ

1. เริ่มจากปัญหาที่ระบุชัดเจน

“ทำไมยอดขายถึงไม่ดี?” → กว้างเกินไป
“ทำไม conversion rate จาก trial เป็น paid ถึงลดลง 30% ในไตรมาส 3?” → ชัดเจนและวิเคราะห์ได้

ยิ่งปัญหาชัดเจนมาก root cause ที่ค้นพบจะยิ่งแม่นยำมาก

2. ถามทีม ไม่ใช่แค่คนคนเดียว

5 Why ที่ทำคนเดียวมักจะถูก bias ของตัวเองโดยไม่รู้ตัว ทีมที่มีหลาย perspective ช่วยให้ได้ root cause ที่ครบถ้วนกว่า

ใคร ที่ควรอยู่ใน session:
– คนที่ใกล้ชิดกับปัญหาที่สุด (frontline)
– คนที่มี domain knowledge ที่เกี่ยวข้อง
– คนที่ไม่ได้เกี่ยวข้องโดยตรง (fresh eyes)

3. ติดตามสาเหตุที่ “ทำได้จริง” เท่านั้น

บางครั้ง root cause ที่ค้นพบอาจเป็นสิ่งที่ควบคุมไม่ได้ (เช่น “เศรษฐกิจไม่ดี”) ให้ขุดต่อไปเรื่อยๆ จนพบสาเหตุที่อยู่ในอำนาจที่จะแก้ได้จริง

4. ไม่ต้องถาม “ทำไม?” ครบ 5 ครั้งเสมอ

“5 Why” คือแนวคิด ไม่ใช่กฎตายตัว บางปัญหาพบ root cause ที่ชั้นที่ 3 บางปัญหาต้องขุดถึงชั้นที่ 7 หยุดเมื่อคำตอบที่ได้นำไปสู่ action ที่จะแก้ปัญหาได้จริง

5. แยก “สาเหตุ” ออกจาก “อาการ”

อาการ: สิ่งที่เห็นได้ — เซิร์ฟเวอร์ล่ม, ลูกค้า complain, พนักงานลาออก
สาเหตุ: สิ่งที่ทำให้อาการเกิด — load สูงเกิน, quality control ไม่ดี, engagement ต่ำ
Root Cause: สาเหตุลึกสุดที่ทำให้ chain of events เกิดขึ้น

6. Document ทุก step

ทำ 5 Why analysis แล้วต้องเขียนบันทึกทุก step เพราะ:
– คนอื่นสามารถ review และ challenge logic ได้
– ใช้เป็น reference เมื่อปัญหาเดิมกลับมา
– Share องค์ความรู้ให้ทีมอื่นที่อาจเจอปัญหาคล้ายกัน

Template 5 Why Analysis

ปัญหา: [ระบุปัญหาให้ชัดเจน รวม context เช่น เมื่อไหร่ที่ไหน ขนาดของปัญหา]

Why 1: ทำไม [ปัญหา] ถึงเกิดขึ้น?
→ เพราะ [สาเหตุที่ 1]

Why 2: ทำไม [สาเหตุที่ 1] ถึงเกิดขึ้น?
→ เพราะ [สาเหตุที่ 2]

Why 3: ทำไม [สาเหตุที่ 2] ถึงเกิดขึ้น?
→ เพราะ [สาเหตุที่ 3]

Why 4: ทำไม [สาเหตุที่ 3] ถึงเกิดขึ้น?
→ เพราะ [สาเหตุที่ 4]

Why 5: ทำไม [สาเหตุที่ 4] ถึงเกิดขึ้น?
→ เพราะ [ROOT CAUSE]

Root Cause: [ระบุ root cause ที่ค้นพบ]

Corrective Action: [การแก้ไขที่จะ address root cause โดยตรง]
Owner: [ใครรับผิดชอบ]
Deadline: [เมื่อไหร่]
Verification: [จะรู้ได้อย่างไรว่าปัญหาไม่กลับมา]

เครื่องมือ RCA อื่นๆ ที่ใช้ร่วมกับ 5 Why

Fishbone Diagram (Ishikawa Diagram)

เหมาะสำหรับปัญหาที่อาจมีสาเหตุหลายสายพร้อมกัน (ต่างจาก 5 Why ที่ไล่เป็น chain เดียว)

6M Framework สำหรับวิเคราะห์:
– Man (คน): ทักษะ ความรู้ ทัศนคติ
– Machine (เครื่องจักร/ระบบ): equipment, software, infrastructure
– Method (วิธีการ): process, procedure, standard
– Material (วัตถุดิบ/ข้อมูล): quality, accuracy, availability
– Measurement (การวัด): KPI definition, data collection method
– Environment (สภาพแวดล้อม): culture, working condition, external factors

Fault Tree Analysis (FTA)

เหมาะสำหรับปัญหาที่ซับซ้อนมากๆ และต้องการดู probability ของแต่ละ branch ใช้บ่อยใน engineering, safety, และ risk management

🚀 พัฒนาทีมของคุณกับ The Blacksmith

Corporate Training เฉพาะสำหรับองค์กรของคุณ

ขอข้อมูลหลักสูตรฟรี

Common Pitfalls: ข้อผิดพลาดในการทำ RCA

Pitfall 1: โทษคน ไม่ใช่ระบบ
Root cause มักอยู่ที่ระบบ process หรือการออกแบบ ไม่ใช่ที่ตัวบุคคล การหยุดที่ “เพราะพนักงานทำผิด” โดยไม่ถามต่อว่า “ทำไมพนักงานถึงทำผิด?” คือการ miss root cause ที่แท้จริง

Pitfall 2: ทำ RCA หลังจาก crisis คลี่คลายแล้ว ไม่ใช่ระหว่างที่ยังสด
ยิ่งรอนานหลังจากเหตุการณ์ ข้อมูลและความทรงจำยิ่งหายไป ทำ RCA เร็วที่สุดเท่าที่จะทำได้

Pitfall 3: ไม่ verify ว่า corrective action ได้ผล
RCA ที่ดีต้องมี follow-up plan เพื่อ confirm ว่าปัญหาไม่กลับมาใน 30-90 วัน

Pitfall 4: ทำแล้วไม่ share
RCA ที่ค้นพบอะไรสำคัญควร share กับทีมอื่นที่อาจเจอปัญหาคล้ายกัน ประหยัดเวลาและ prevent ปัญหาเดิมในแผนกอื่น

สรุป: RCA เป็น Skill ที่องค์กรควรฝึกให้ทีมทุกระดับ

5 Why และ Root Cause Analysis ไม่ใช่เครื่องมือสำหรับ quality team หรือ engineering เท่านั้น แต่เป็น mindset ในการคิดที่ทุกคนในองค์กรควรมี

HR ที่ไม่แก้ root cause ของ turnover จะจ้างคนใหม่ไปเรื่อยๆ Manager ที่ไม่แก้ root cause ของ performance issue จะ training คนเดิมซ้ำๆ องค์กรที่ไม่แก้ root cause ของ process failure จะแก้ปัญหาเดิมทุกไตรมาส

ถามว่า “ทำไม?” ให้มากขึ้น และเริ่มแก้ปัญหาที่ต้นเหตุ — นั่นคือความแตกต่างระหว่างองค์กรที่แค่ “survive” กับองค์กรที่ continuously improve