สารานุกรมการบริหารและการจัดการ
การค้นหาสาเหตุปัญหาด้วยการตั้งคำถาม "ทำไม" 5 ครั้ง
ปัญหาที่ไม่เคยคิดมาก่อนว่ามี อาจเกิดขึ้นกับบุคคล ทีมงาน หรือกระบวนการทำงานได้ทุกเมื่อ บ่อยครั้งที่สิ่งซึ่งเราคิดว่าเป็นตัวปัญหา กลับเป็นเพียงอาการภายนอกที่คลุมปัญหาที่แท้จริงไว้ภายในเปรียบเหมือนการไอซึ่งไม่ใช่ตัวปัญหา แต่เป็นเพียงอาการของไข้หรือหลอดลมอักเสบ การแก้ปัญหาตามอาการที่เกิดขึ้น อาจเป็นสิ่งที่ทำได้ง่ายและสะดวก แต่หากการแก้ไขนั้นไม่ได้แก้ที่สาเหตุ ปัญหานั้นก็อาจจะหวนกลับมาเกิดซ้ำได้อีก
5 Whys เป็นเทคนิคที่ไม่ยุ่งยากซับซ้อน สามารถนำใช้ในการหารากเหง้าของปัญหาได้อย่างรวดเร็วด้วยการสาวลึกลงไปที่สาเหตุของสาเหตุ ได้รับความนิยมมากในช่วงทศวรรษที่ 1970 เป้าหมายหลักของ 5 Whys คือการได้ทราบต้นตอหรือรากเหง้าของปัญหาโดยใช้การถามหาสาเหตุของปัญหาที่มีอยู่ (end result) ว่า “ทำไม” ซ้ำๆ กัน คำตอบที่ได้ในแต่ละคำถาม จะกลายมาเป็นตัวตั้งสำหรับการสอบหาสาเหตุว่า “ทำไม” ในครั้งต่อไป ในกรณีที่คำตอบที่ได้ มีสาเหตุของปัญหามากกว่าหนึ่งสาเหตุ ก็จะต้องตั้งคำถาม “ทำไม” กับแต่ละสาเหตุนั้นแยกกันไป แม้เทคนิคนี้จะเรียกว่า 5 Whys แต่ก็เป็นเพียงจำนวนครั้งแบบกลางๆ เราอาจถาม “ทำไม” น้อยหรือมากกว่า 5 ครั้งไปจนกว่าจะสะท้อนให้เห็นถึงกระบวนการที่ผิดพลาด หรือไม่มีกระบวนการที่ถูกต้องในการทำงานซึ่งเป็นรากเหง้า (root cause) ของปัญหา สำหรับคำตอบที่เป็นข้อแก้ตัว เช่น มีเวลาไม่พอ, ลงทุนน้อยไป, มีคนไม่พอ แม้จะเป็นสาเหตุของปัญหา แต่ก็ผูกเข้ากับตัวบุคคลหรือทรัพยากร หากไม่แก้ที่กระบวนการ ถึงจะเปลี่ยนตัวบุคคลหรือเพิ่ม / ลดทรัพยากร ปัญหาเดิมก็อาจกลับมาเกิดซ้ำอีก ความสำเร็จในการค้นหาสาเหตุของปัญหาด้วยเทคนิค 5 Whys จึงขึ้นอยู่กับความรู้และประสบการณ์ของผู้เกี่ยวข้องกับการสืบค้นปัญหาเชิงระบบเป็นสำคัญ
5 Whys เป็นเทคนิคสอบหาสาเหตุของปัญหาที่พัฒนาโดย Sakichi Toyoda ในทศวรรษที่ 1930 เพื่อนำมาใช้เป็นกระบวนการแก้ไขปัญหาการผลิตของโตโยต้า (Toyota Production System: TPS) และเป็นส่วนที่จะขาดเสียไม่ได้ของปรัชญาการผลิตแบบไม่เกิดความสูญเปล่า (lean philosophy) สถาปนิกของ TPS ในช่วงทศวรรษที่ 1950 ชื่อ Taiichi Ohno ได้กล่าวถึงแนวคิดเรื่อง 5 Whys ของ Toyoda ไว้ในหนังสือชื่อ Toyota Production System: Beyond Large Scale Production โดยอธิบายว่า 5 Whys เป็นพื้นฐานวิธีการทางวิทยาศาสตร์ของโตโยต้าด้วยการตั้งคำถาม “ทำไม” 5 ครั้ง เพื่อช่วยให้สภาพปัญหาที่ดูคลุมเครือมีความชัดเจนขึ้น เช่น เมื่อแขนกลของเครื่องจักรไม่ทำงาน
| คำถาม | คำตอบ (สาเหตุของปัญหา) |
| 1. ทำไมแขนกล (robot)ไม่ทำงาน | วงจรไฟฟ้าทำงานเกินกำลังจนฟิวส์ขาด |
| 2. ทำไมวงจรไฟฟ้าจึงทำงานเกินกำลัง | นำมันหล่อลื่นตลับลูกปืนมีไม่พอ จึงเกิดการติดล็อคในตลับ |
| 3. ทำไมนำมันหล่อลื่นตลับลูกปืนจึงมีไม่พอ | ปั้มหัวฉีด จ่ายน้ำมันไปไม่พอ |
| 4. ทำไมปั้มหัวฉีดจึงจ่ายน้ำมันไปไม่พอ | ภายในหัวปั้มมีเศษโลหะเข้าไปอุดตัน |
| 5. ทำไมภายในหัวปั้มจึงมีเศษโลหะเข้าไปอุดตัน | ภายในหัวปั้มไม่มีไส้กรองเศษโลหะ |
วิธีการดังกล่าวไม่ได้ใช้กันอยู่แต่เฉพาะภายในบริษัทโตโยต้าเท่านั้น แต่ยังเป็นที่นิยมใช้กันทั่วไปในระบบงานคุณภาพอื่นๆ ด้วย เช่น Kaizen, Lean manufacturing และ 6 Sigma เพราะเป็นเทคนิคที่ไม่จำเป็นต้องจำแนกข้อมูลออกเป็นประเภท, ทดสอบสมมุติฐาน, วิเคราะห์การถดถอย หรือใช้กรรมวิธีทางสถิติใดๆ ก็สามารถปอกเอาส่วนที่เรียกว่าอาการออกไปให้เหลือแต่ส่วนที่เป็นรากเหง้าของปัญหาได้
การนำกระบวนการ 5 Whys มาใช้ปฏิบัติ
เทคนิคหลักสองประการที่นำมาใช้ในการวิเคราะห์แบบ 5 Whys ได้แก่
o การใช้ผังก้างปลา (fishbone diagram)
o การใช้ตารางแจกแจงข้อมูล (tabular format)
Fishbone diagram บางครั้งเรียกว่า Cause and effect diagram หรือ Ishikawa diagram เป็นเทคนิคที่ช่วยสำรวจว่าปัญหานั้นมีสาเหตุอะไรที่เป็นไปได้บ้าง เมื่อได้ทราบสาเหตุต่างๆ แล้ว จึงนำ 5 Whys มาใช้เพื่อสอบหารากเหง้าของสาเหตุนั้นอีกครั้ง
ขั้นตอนในการวิเคราะห์ด้วยเทคนิค 5 Whys มีดังนี้
1. แต่งตั้งทีมงาน (Form a team)
1.1 แต่งตั้งทีมงานประกอบด้วยผู้ที่คุ้นเคยกับงานที่มีปัญหา และบุคคลจากหน่วยงานด้านคุณภาพ, วิศวกรรมกระบวนการ, พนักงานฝ่ายผลิตซึ่งทำงานในกะงานต่างๆ, และผู้ที่เกี่ยวข้องกับกระบวนการทำงานถัดไปจากขั้นตอนที่เกิดปัญหา เพื่อให้ได้ความคิดเห็นที่เกี่ยวข้องกับปัญหาอย่างครอบคลุม รวมไปถึงประเด็นที่ผู้ปฏิบัติงานในหน่วยงานที่เกิดปัญหาอาจมองข้ามไป
1.2 ควรจัดหาผู้มีความรู้และประสบการณ์ในการใช้เทคนิค 5 Whys เป็นผู้ช่วยเหลือและให้คำแนะนำที่จำเป็นเพื่อไม่ให้การพิจารณาเตลิดออกนอกประเด็นจนหาข้อสรุปไม่ได้
2. แจกแจงปัญหา (Define the problem)
2.1 เขียนตัวปัญหาลงบนกระดาษ กระดาน หรือ visualizer ที่ทีมงานมองเห็นได้ร่วมกัน การเขียนนอกจากจะช่วยแจกแจงปัญหาออกมาได้ครบถ้วนมากกว่าการอธิบายเป็นคำพูดแล้ว ยังช่วยให้ทีมงานทุกคนมองปัญหาในเรื่องเดียวกัน
2.2 ปัญหาที่ระบุนั้นต้องมีความชัดเจนเพื่อให้มีกรอบการพิจารณาที่เจาะเข้าสู่ปัญหาได้อย่างถูกต้อง ไม่เสียเวลาไปกับการอภิปรายเรื่องที่ไม่ใช่ประเด็นปัญหา
3. สอบหาสาเหตุด้วยการถาม “ทำไม” (Ask Why)
3.1 แต่งตังหัวหน้าทีมเพื่อทำหน้าที่ป้อนคำถาม และดูแลให้การอภิปรายมุ่งเน้นไปที่สาเหตุของปัญหาที่อยู่บนพื้นฐานของข้อเท็จจริง ไม่ใช่ความคิดเห็นที่มีอารมณ์เข้ามาเกี่ยวข้อง
3.2 หัวหน้าทีมควรถาม “ทำไม” ให้มากเท่าที่จำเป็น ซึ่งอาจมากหรือน้อยกว่า 5 ครั้ง จนกว่าทีมงานจะมีความเห็นร่วมกันว่านั่นคือรากเหง้าของปัญหา
3.3 หัวหน้าทีมควรสอบถามทีมงานว่าคำตอบที่ได้จากคำถาม “ทำไม” ในครั้งทีหนึ่ง เป็นสาเหตุที่ถูกต้องของปัญหาหรือไม่ หากไม่แก้ที่สาเหตุนั้นแล้ว ปัญหาน่าจะเกิดอีกใช่หรือไม่ หากคำตอบคือ ใช่ จึงใช้สาเหตุที่หนึ่งนั้นเป็นฐานในการตั้งคำถาม “ทำไม” ในครั้งที่สอง และทำเช่นเดียวกันกับคำตอบที่ได้ในแต่ละครั้งเพื่อถาม “ทำไม” ในครั้งต่อๆ ไป การถาม “ทำไม” ไปเรื่อยๆ โดยไม่สรุปในแต่ละคำถาม อาจทำให้ได้ความคิดเห็นที่ไร้สาระหรือข้อร้องเรียนมากมายซึงไม่ใช่ความมุ่งหมายของ 5 Whys ที่มุ่งจะหารากเหง้าของปัญหา
3.4 แยกความแตกต่างให้ชัดว่าอะไรคือปัญหา และอะไรคืออาการของปัญหา พิจารณาสาเหตุอย่างเป็นขั้นเป็นตอน ไล่ไปตามลำดับของเหตุและผล ไม่ด่วนสรุป
3.5 ใช้ความรู้และข้อเท็จจริงที่เกิดขึ้นเป็นพื้นฐานการพิจารณา ประเมินที่ตัวระบบ ไม่ใช่ตัวบุคคล
3.6 ไม่ใช้ความผิดพลาดของมนุษย์, ความไม่ใส่ใจของพนักงาน, การตำหนิติเตียนว่าเป็นความผิดของใคร ฯลฯ เป็นรากเหง้าของปัญหา
3.7 ต้องมั่นใจว่าสาเหตุที่ได้มานั้นคือตัวการที่ทำให้เกิดปัญหา สาเหตุหรือคำตอบที่ได้ต้องกระชับชัดเจน
3.8 ตั้งคำถาม “ทำไม” ไปจนกว่าจะสามารถกำหนดรากเหว้าของปัญหาได้ รากเหง้าของปัญหาหมายความว่าหากกำจัดสาเหตุนั้นได้ ก็จะสามารถป้องกันปัญหานั้นไม่ให้เกิดขึ้นอีกได้
4. จัดการแก้ไข (Corrective action)
4.1 ในการหามาตรการแก้ไข (corrective action) นั้น ทีมงานทุกคนควรร่วมกันพิจารณาหามาตรการที่สามารถป้องกันปัญหาไม่ให้เกิดขึ้นมาได้อีก การตั้งคำถามว่า “จะแก้ไขอย่างไร” หรือ 5 How เพื่อตอบโจทย์ของ 5 Why จะทำให้ได้มาตรการแก้ไขปัญหาที่นอกจากจะสัมพันธ์กับสาเหตุของปัญหาแล้ว ยังเป็นการแก้ไขที่รากเหง้า (root solution) อีกด้วย
4.2 กำหนดสมาชิกคนหนึ่งในทีมงานให้เป็นผู้รับผิดชอบในการนำมาตรการแก้ไขไปปฏิบัติและติดตามสังเกตกระบวนการที่ได้จัดการแก้ไขนั้นโดยกำหนดให้ชัดเจนว่าจะใช้เวลาในการแก้ไขนานเท่าไร จะติดตามประเมินผลเมื่อไร อย่างไร
4.3 จัดประชุมทีมงานเพื่อรับทราบผลการประเมินว่า ปัญหาได้รับการแก้ไขหรือไม่ การติดตามประเมินผลควรใช้การควบคุมกระบวนการทางสถิติ (Statistical Process Control: SPC) ไม่ใช่ใช้ความคิดเห็นส่วนตัวของผู้รับผิดชอบ หากปัญหาไม่ได้รับการแก้ไขหรือแก้แล้วกลับมาเกิดซ้ำอีก ให้เริ่มกระบวนการ 5 Whys และ 5 How ใหม่ หรือนำเทคนิคการวิเคราะห์สาเหตุปัญหารูปแบบอื่นมาใช้ประกอบ
4.4 หากปัญหาได้รับการแก้ไขตามที่คาดหวัง ให้บันทึกการดำเนินการทั้งหมดแล้วเผยแพร่ให้ทราบทั่วทั้งองค์กรเพื่อให้สมาชิกทุกคนได้ทราบและรู้ว่าปัญหานั้นได้รับการแก้ไขอย่างไร
บทความที่เกี่ยวข้องซึ่งขอแนะนำให้อ่านประกอบ
• 4-Step Innovation Process
• 6 Sigma Principles
• 6-Step Problem Solving Model
• 7 Types of Waste
• 8 Disciplines of Problem Solving
• A3 Lean Thinking Process
• Cause and Effect Analysis (Fishbone Chart)
• Kaizen
• Lean Manufacturing
• Lean Startup [Eric Ries]
• Problem Solving for Managers
• Root Cause Analysis
• ทักษะการตอบคำถามเฉพาะหน้า
———————————
หมายเหตุ: ผู้เขียนเปิด website สำรองข้อมูล ไว้ที่ drpiyanan.blogspot.com ผู้สนใจสามารถเปิดเข้าอ่านได้เช่นเดียวกับ web นี้ แต่จะมีความยั่งยืนกว่าเพราะสามารถรักษาสถานภาพของ web อยู่ได้โดยไม่ต้องต่ออายุ domain และ hosting เป็นรายปี