Problem Solving คือกระบวนการระบุ วิเคราะห์ และแก้ปัญหาอย่างเป็นระบบ ส่วน Decision Making คือกระบวนการเลือกระหว่าง option ที่มีโดยประเมิน trade-off อย่างรอบด้าน ทั้งสองเป็นทักษะที่สามารถพัฒนาได้ผ่าน framework และการฝึกฝน

Problem Solving และ Decision Making Framework ที่ใช้ได้จริงในที่ทำงาน

ปัญหาเดิมกลับมาซ้ำทุกไตรมาส — ทีมประชุมหาทางออก เสนอแนวทาง implement แล้ว แต่ 3 เดือนถัดมาก็เจอปัญหาเดิมอีก

ส่วนใหญ่ไม่ใช่เพราะทีมไม่เก่ง แต่เพราะแก้ที่ symptom ไม่ใช่ root cause

Problem Solving และ Decision Making เป็นทักษะที่ทำได้ดีขึ้นมากด้วย framework ที่ถูกต้อง — ไม่ใช่แค่ “ประสบการณ์” หรือ “สัญชาตญาณ”

ทำความรู้จัก Problem Solving Framework
Problem Solving Framework คือโครงสร้างที่ช่วยให้กระบวนการแก้ปัญหาเป็นระบบและทำซ้ำได้ ต่างจากการแก้ปัญหาแบบ ad hoc ที่อิงความรู้สึกหรือประสบการณ์เฉพาะตัว framework ที่ดีทำให้ทีมที่มีความเห็นต่างกันสามารถวิเคราะห์ปัญหาจากมุมเดียวกัน และไปถึงการตัดสินใจที่ดีขึ้นได้เร็วขึ้น

ทำไม “แก้ปัญหา” ส่วนใหญ่ไม่ได้แก้ที่ต้นเหตุ

กับดักที่ 1: โดดไปที่ solution ก่อนเข้าใจปัญหา
เมื่อมีปัญหา สมองมนุษย์ต้องการ act ทันที ทำให้มักเสนอ solution ก่อนใช้เวลาเข้าใจปัญหาจริงๆ

กับดักที่ 2: สับสนระหว่าง symptom กับ root cause
ยอดขายลด (symptom) → training ทีมขาย (solution) แต่ root cause จริงอาจเป็นราคาที่ไม่แข่งขัน หรือ product ที่ไม่ตอบโจทย์ตลาด

กับดักที่ 3: ตัดสินใจโดย anchoring กับ solution แรกที่เสนอ
solution แรกที่พูดขึ้นมาในห้องมักกลายเป็น reference point ที่ทุกคนเปรียบเทียบกับมัน แทนที่จะสร้าง option อื่นขึ้นมาก่อน

กับดักที่ 4: ไม่มี criteria ในการตัดสินใจ
เลือก option ที่คนมีอำนาจมากที่สุดชอบ ไม่ใช่ option ที่ดีที่สุด

Framework 1: 5 Whys — ขุดลงถึง Root Cause

ที่มา: พัฒนาโดย Sakichi Toyoda และใช้ใน Toyota Production System

แนวคิด: ถามว่า “ทำไม?” ซ้ำๆ 5 ครั้ง (หรือจนกว่าจะถึง root cause) แต่ละคำตอบกลายเป็นคำถาม “ทำไม?” ของรอบถัดไป

ตัวอย่าง:
– ปัญหา: ลูกค้าร้องเรียนเรื่อง delivery ล่าช้า
– ทำไม? เพราะสินค้าหายจาก warehouse
– ทำไม? เพราะระบบ inventory ไม่อัพเดต real-time
– ทำไม? เพราะ staff ไม่ scan barcode ทุกครั้งที่หยิบสินค้า
– ทำไม? เพราะ scanner เสียบ่อยและรอซ่อมนาน
– ทำไม? เพราะไม่มีสัญญา maintenance กับ vendor
– Root Cause: ไม่มีสัญญา maintenance

Solution ที่ถูก: ทำสัญญา maintenance กับ vendor scanner — ไม่ใช่ training staff เรื่อง barcode

เมื่อไรที่ใช้ได้ดี: ปัญหาที่มี cause-effect chain ชัดเจน, ปัญหาซ้ำๆ ที่แก้แล้วกลับมา

ข้อควรระวัง: 5 Whys อาจให้คำตอบที่ต่างกันถ้าคนถามมีมุมมองต่างกัน ควรทำในกลุ่มและดูข้อมูล ไม่ใช่แค่ความเห็น

Framework 2: Problem Tree Analysis — แผนที่ปัญหาแบบครบวงจร

แนวคิด: วาด “ต้นไม้” ของปัญหา:
– ลำต้น: ปัญหาหลักที่ต้องการแก้
– ราก: สาเหตุ (causes) ของปัญหา
– กิ่ง: ผลลัพธ์ (effects) ที่เกิดจากปัญหา

ขั้นตอน:
1. เขียนปัญหาหลักตรงกลาง
2. brainstorm ทุกสาเหตุที่เป็นไปได้ → เขียนด้านล่าง (ราก)
3. brainstorm ผลลัพธ์ทุกอย่างที่เกิดจากปัญหา → เขียนด้านบน (กิ่ง)
4. เชื่อมด้วยลูกศรเพื่อแสดง cause-effect relationship
5. เลือกว่าจะ intervene ที่จุดไหนเพื่อผลลัพธ์สูงสุด

ประโยชน์: เห็นภาพรวมของปัญหาทั้งหมด ไม่ตกหลุม “แก้อาการ”, ช่วย align ทีมว่าปัญหาจริงๆ คืออะไร, เลือก intervention point ที่มีประสิทธิภาพสูงสุด

เมื่อไรที่ใช้ได้ดี: ปัญหาซับซ้อนที่มีหลาย cause และ effect, การวางแผน strategy หรือ project ใหม่

Framework 3: PDCA — วงจรแก้ปัญหาแบบต่อเนื่อง

PDCA (Plan–Do–Check–Act) คือ framework สำหรับการแก้ปัญหาและพัฒนาอย่างต่อเนื่อง

Phase	สิ่งที่ทำ
Plan	ระบุปัญหา, วิเคราะห์สาเหตุ, ออกแบบ solution
Do	implement solution ในระดับ pilot หรือทดสอบก่อน
Check	วัดผลเทียบกับ target — solution ได้ผลไหม?
Act	ถ้าได้ผล: ทำใน full scale และ standardize; ถ้าไม่ได้: กลับไป Plan

ความแตกต่างจาก framework อื่น: PDCA เป็น cycle ไม่ใช่ one-time process — หลังจาก Act จบ เริ่ม Plan รอบใหม่เพื่อพัฒนาต่อเนื่อง

เมื่อไรที่ใช้ได้ดี: การปรับปรุง process, การแก้ปัญหาด้าน quality, โปรเจกต์ที่ต้องการ iteration

Framework 4: Decision Matrix — ตัดสินใจระหว่าง Option อย่างโปร่งใส

เมื่อมี solution หลายตัวและต้องเลือก Decision Matrix ช่วยประเมิน option อย่างเป็นระบบ

วิธีสร้าง Decision Matrix:
1. List ทุก option ในแถวแนวตั้ง
2. กำหนด criteria ที่สำคัญในคอลัมน์ (เช่น ต้นทุน, ความเร็ว, ความเสี่ยง, impact)
3. ให้น้ำหนัก (weight) แต่ละ criteria ตามความสำคัญ
4. ให้คะแนน (score 1–5) แต่ละ option ใน criteria นั้น
5. คำนวณ weighted score รวมของแต่ละ option
6. option ที่คะแนนสูงสุดคือตัวเลือกที่ดีที่สุด (แต่ยังต้องใช้ judgment ด้วย)

ตัวอย่าง — เลือก Training Provider:

	น้ำหนัก	Provider A	Provider B	Provider C
ราคา	30%	4 (1.2)	3 (0.9)	5 (1.5)
Expertise	40%	5 (2.0)	4 (1.6)	3 (1.2)
Flexibility	30%	3 (0.9)	5 (1.5)	2 (0.6)
รวม	100%	4.1	4.0	3.3

→ Provider A ชนะแม้ราคาไม่ถูกที่สุด เพราะ expertise และ flexibility รวมกันสูงกว่า

เมื่อไรที่ใช้ได้ดี: การเลือก vendor หรือ partner, การตัดสินใจลงทุน, การเลือก strategy จากหลาย option

วิธีพัฒนาทักษะ Problem Solving ในทีม

1. สร้าง Problem Solving Culture
เมื่อมีปัญหาเกิดขึ้น แทนที่จะถามว่า “ใครผิด?” ถามว่า “ระบบมีปัญหาอะไร?” และ “เราจะป้องกันไม่ให้เกิดซ้ำได้อย่างไร?”

2. ฝึก After Action Review (AAR)
หลังโปรเจกต์หรือการตัดสินใจสำคัญ ทำ session สั้นๆ 30–60 นาที ตอบ 4 คำถาม:
– เราตั้งใจทำอะไร?
– เกิดอะไรขึ้นจริงๆ?
– ทำไมถึงมีความแตกต่าง?
– เราจะทำอะไรต่างออกไปครั้งหน้า?

3. ใช้ Pre-Mortem ก่อนตัดสินใจใหญ่
ก่อน implement คำถาม: “สมมติว่าโปรเจกต์นี้ล้มเหลวสมบูรณ์แบบใน 1 ปี — เราคิดว่าจะล้มเหลวเพราะอะไรได้บ้าง?” คำตอบช่วยระบุ risk ที่ไม่ได้คิดถึงก่อน implement

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

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

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

Entity Block

คำศัพท์	ความหมาย
5 Whys	เทคนิคถาม “ทำไม?” ซ้ำๆ เพื่อขุดลงถึง root cause ของปัญหา พัฒนาโดย Toyota
Problem Tree Analysis	เครื่องมือ visualize ปัญหาในรูปแบบต้นไม้ แสดง causes (ราก) และ effects (กิ่ง)
PDCA Cycle	Plan-Do-Check-Act วงจรการแก้ปัญหาและพัฒนาอย่างต่อเนื่อง
Decision Matrix	ตารางเปรียบเทียบ option หลายตัวตาม criteria ที่มีน้ำหนัก เพื่อตัดสินใจอย่างโปร่งใส
Root Cause	สาเหตุต้นตอที่แท้จริงของปัญหา ต่างจาก symptom ที่เป็นแค่ผลลัพธ์ที่มองเห็น
Pre-Mortem	เทคนิคจินตนาการล่วงหน้าว่าโปรเจกต์จะล้มเหลวอย่างไร เพื่อระบุ risk ก่อนเริ่ม

FAQ

Q1: Framework ไหนเหมาะที่สุดสำหรับองค์กรไทย?
ขึ้นอยู่กับลักษณะปัญหาครับ สำหรับปัญหาซ้ำๆ ในงาน operation แนะนำ 5 Whys เป็น default สำหรับปัญหาซับซ้อนที่ต้องการ buy-in จากหลายฝ่าย Problem Tree ดีมาก สำหรับการเลือกระหว่าง option Decision Matrix ช่วยลด political influence ได้มาก

Q2: ทำ 5 Whys แล้ว root cause ที่ได้ “แก้ไม่ได้” จะทำอย่างไร?
เป็นเรื่องปกติครับ ไม่ใช่ทุก root cause ที่จะ actionable สิ่งที่ควรทำคือเลือก intervene ที่ระดับที่สูงที่สุดที่ยังสามารถควบคุมได้ เช่น ถ้า root cause คือ “เศรษฐกิจไม่ดี” ซึ่งควบคุมไม่ได้ ให้ focus ที่ level ก่อนหน้าที่ทำได้

Q3: Decision Matrix ทำให้ตัดสินใจได้ดีขึ้นจริงไหม?
ช่วยได้มากในการลด bias และทำให้ decision โปร่งใสขึ้นครับ แต่ Decision Matrix ไม่ได้ “ตัดสินใจแทน” — มันเป็นเครื่องมือสนับสนุน judgment ไม่ใช่แทนที่ judgment สิ่งที่สำคัญที่สุดคือ criteria และ weight ที่เลือกใช้ — ถ้าตั้งไม่ดี คะแนนก็ misleading

Q4: PDCA กับ Agile ต่างกันอย่างไร?
แนวคิดใกล้กันมากครับ PDCA เป็น foundation ที่ Agile ต่อยอดมา Agile Sprint ก็คือ PDCA cycle ที่ time-boxed (1–4 สัปดาห์) ความแตกต่างหลักคือ Agile เน้น collaboration และ customer feedback มากกว่า ส่วน PDCA เน้น measurement และ standardization

Q5: Problem Solving workshop ควรใช้เวลานานแค่ไหน?
ขึ้นอยู่กับความซับซ้อนของปัญหาครับ สำหรับปัญหาระดับทีม half-day workshop (3–4 ชั่วโมง) มักเพียงพอสำหรับใช้ 5 Whys หรือ Problem Tree และ decision กับ solution สำหรับปัญหาระดับองค์กร อาจต้องใช้ 1–2 วันและทำ pre-work รวบรวมข้อมูลก่อน