แก้ปัญหาอย่างมีประสิทธิภาพ: กระบวนการ 8 ขั้นตอน แบบโตโยต้า

โตโยต้าไม่รีบแก้ปัญหาที่อาการ แต่ขยายวงจร PDCA เป็น 8 ขั้น และใช้ 5 ขั้นแรกวางแผน: เห็นปัญหาให้ชัด หาสาเหตุรากให้เจอ ก่อนลงมือแก้

8 ขั้นแก้ปัญหาแบบโตโยต้า

1. 1
   ขั้นที่ 1: ระบุปัญหาให้ชัดPlanClarify the problem

   ปัญหาคือ ช่องว่าง ระหว่างภาพที่ควรเป็นกับสภาพจริง

2. 2
   ขั้นที่ 2: แตกปัญหาให้ย่อยPlanBreak down the problem

   แยกปัญหาให้เล็กลง ไปดูหน้างานว่าเกิดที่จุดไหน

3. 3
   ขั้นที่ 3: ตั้งเป้าหมายPlanSet a target

   จะลดหรือเพิ่มเท่าไร ภายในเมื่อไร วัดเป็นตัวเลข

4. 4
   ขั้นที่ 4: หาสาเหตุรากPlanAnalyze the root cause

   หาต้นตอที่ทำให้ปัญหาเกิด ไม่หยุดแค่อาการ

   • ถาม “ทำไม” ซ้ำ ๆ จากข้อเท็จจริงหน้างาน
   • หยุดเมื่อเจอจุดที่แก้แล้วปัญหาไม่กลับมา
5. 5
   ขั้นที่ 5: คิดมาตรการแก้PlanDevelop countermeasures

   คิดหลายทาง เลือกทางที่แก้ที่ราก แล้ววางแผนว่าใครทำอะไร เสร็จเมื่อไร

6. 6
   ขั้นที่ 6: ลงมือตามมาตรการDoSee countermeasures through

   ทำให้เร็ว ทำเป็นทีม และแจ้งความคืบหน้าเป็นระยะ

7. 7
   ขั้นที่ 7: ติดตามผลและกระบวนการCheckMonitor results and processes

   ดูทั้งตัวเลขผลลัพธ์ และดูว่าทำตามวิธีที่ตกลงไหม

8. 8
   ขั้นที่ 8: ทำให้เป็นมาตรฐานActStandardize successful processes

   ล็อกวิธีที่ได้ผลไว้ ส่งต่อให้ทีมอื่น แล้วเริ่มรอบใหม่

โตโยต้าเรียกวิธีนี้ว่า Toyota Business Practices (TBP) · สีน้ำเงินคือวางแผน 5 ขั้น สีเขียวคือลงมือ 3 ขั้น

ขุดให้ถึงราก

ถ้าแก้แค่อาการ ปัญหาจะกลับมาอีก ขั้น 4 จึงสำคัญมาก โตโยต้ายึดหลัก Genchi Genbutsu คือไปดูของจริงที่หน้างานจริง แล้วใช้ 5 Whys ถาม “ทำไม” กับคำตอบก่อนหน้าทีละชั้น สำหรับทีมซอฟต์แวร์ หน้างานจริงคือเรื่องแจ้งปัญหา (ticket) บันทึกการขึ้นระบบ และหน้าจอของผู้ใช้ ลองดูตัวอย่างจากทีมระบบเงินเดือนของบริษัทเรา ที่ทีมซัพพอร์ตนัดบริษัทลูกค้าไว้ว่าจะแก้บั๊กให้ภายใน 2 วัน

ถาม “ทำไม” ทีละชั้น จากอาการถึงราก

อาการ

30% ของบั๊กที่นัดไว้ ถึงมือผู้ใช้ช้า

ทำไมถึงช้า

โค้ดเสร็จทัน แต่ขึ้นระบบจริงช้า 1–2 วัน

ทำไมขึ้นช้า

DevOps ต้องรอคำขอขึ้นระบบที่อนุมัติแล้ว

ทำไมอนุมัติช้า

คำขอค้างรอ CTO อนุมัติ

ทำไมค้างรอ

CTO อนุมัติรวบวันละครั้งตอนเย็น

ทำไมอนุมัติรวบ

กฎให้ CTO อนุมัติทุกงาน แม้แก้บรรทัดเดียว คำขอจึงล้นมือ

1. 1
   อาการ

   30% ของบั๊กที่นัดไว้ ถึงมือผู้ใช้ช้า

2. 2
   ทำไมถึงช้า

   โค้ดเสร็จทัน แต่ขึ้นระบบจริงช้า 1–2 วัน

3. 3
   ทำไมขึ้นช้า

   DevOps ต้องรอคำขอขึ้นระบบที่อนุมัติแล้ว

4. 4
   ทำไมอนุมัติช้า

   คำขอค้างรอ CTO อนุมัติ

5. 5
   ทำไมค้างรอ

   CTO อนุมัติรวบวันละครั้งตอนเย็น

6. 6
   ทำไมอนุมัติรวบ

   กฎให้ CTO อนุมัติทุกงาน แม้แก้บรรทัดเดียว คำขอจึงล้นมือ

สาเหตุราก: เกณฑ์อนุมัติไม่แยกตามความเสี่ยงของงาน

รากที่เจอคือ กฎ ไม่ใช่ตัว CTO ถ้าหยุดแค่ “CTO อนุมัติช้า” ทางแก้จะเหลือแค่ตำหนิคน แล้วปัญหาก็กลับมา

เลข 5 เป็นแค่ตัวเลขจำง่าย บางเรื่องถาม 3 ครั้งก็ถึงราก บางเรื่องต้องถามเกิน 5 ครั้ง ในขั้น 2 ใช้ 5W2H ช่วยบรรยายปัญหาให้ครบ และในขั้น 4 ใช้ 5M1E ไล่หาสาเหตุให้ครบทุกด้าน

ตัวอย่าง: แก้บั๊กไม่ทันนัด

เรื่องเดียวกันเมื่อเดินครบ 8 ขั้น

• ขั้น 1–3: บั๊ก 30% ที่ทีมซัพพอร์ตนัดบริษัทลูกค้าไว้ ถึงมือผู้ใช้ช้ากว่านัด ทีมเปิด ticket ไล่ดูทีละช่วง พบว่านักพัฒนาแก้โค้ดเสร็จตามเวลา แต่รอขึ้นระบบจริงนาน จึงตั้งเป้าลดบั๊กที่แก้ไม่ทันนัดเหลือ 10% ภายใน 2 เดือน
• ขั้น 4–5: เจอรากแล้วจึงแก้ที่กฎ ไม่ใช่เร่ง CTO: งานเล็กที่ไม่แตะสูตรคำนวณเงิน ให้ Tech Lead อนุมัติขึ้นระบบได้ทันที งานที่แตะสูตรคำนวณเงิน ให้ CTO อนุมัติในระบบภายใน 2 ชั่วโมง
• ขั้น 6–7: ใช้จริง 6 สัปดาห์ (3 สปรินต์) บั๊กที่แก้ไม่ทันนัดเหลือ 8% และตรวจว่างานที่แตะสูตรได้รับอนุมัติภายใน 2 ชั่วโมงจริง
• ขั้น 8: เขียนเป็นแนวทางการขึ้นระบบ ส่งต่อให้ทีมที่ดูแลระบบนัดหมายของลูกค้าเครือโรงพยาบาลเอกชนภายใต้สัญญาดูแลระบบ (MA) แล้วหยิบปัญหาถัดไปมาเริ่มรอบใหม่

ข้อควรระวัง

• อย่ากระโดดจากขั้น 1 ไปขั้น 5 คิดทางแก้ก่อนรู้ราก มักได้มาตรการที่แก้แค่อาการ
• อย่าเดาจากโต๊ะ แดชบอร์ดบอกว่ามีปัญหา แต่ ticket จริงบอกว่าปัญหาเกิดตรงไหน
• หาช่องโหว่ ไม่ใช่หาคนผิด ถามว่าขั้นตอนไหนเปิดช่องให้พลาด ถ้ากลัวถูกโทษ คนจะเงียบ
• ขั้น 7 ดูวิธีทำด้วย ถ้าตัวเลขดีขึ้นแต่ไม่ได้ทำตามวิธีที่ตกลง อาจเป็นแค่โชค และผลมักอยู่ได้ไม่นาน

จำให้ขึ้นใจ

วางแผน 5 ขั้น ลงมือ 3 ขั้น
ถาม “ทำไม” จนถึงราก
แก้ได้แล้วล็อกเป็นมาตรฐาน

อ่านต่อ: วงจร PDCA · การวิเคราะห์ 5W2H · 10 วิธีคิดเชิงลึก