การแก้ปัญหาอย่างเป็นระบบหรือ Systematic Problem Solving เป็นศาสตร์ที่มีประโยชน์อย่างมากในการแก้ปัญหาในการทำงาน โดยเฉพาะสำหรับหัวหน้างานหรือผู้เชี่ยวชาญพิเศษที่อาจต้องเกียวข้องกับการแก้ปัญหาด้านเทคนิคต่างๆ ที่มีความซับซ้อน ซึ่งหลายๆ องค์กรให้ความสำคัญกับเรื่องนี้เนื่องจากสามารถนำมาใช้แก้ปัญหาที่ซับซ้อนและยากได้ตรงและรวดเร็ว ปัญหาที่กล่าวถึง ณ ที่นี้ส่วนใหญ่จะเป็นปัญหาด้านเทคนิค เช่น ด้านวิศวกรรม การวินิจฉัยของแพทย์ การสืบสวนสอบสวน หรือแม่แต่การตัดสินคดี ซึ่งปัญหาด้านเทคนิคเกือบทุกปัญหามีรูปแบบบางอย่างที่คล้ายๆ กัน และเครื่องมือที่สำคัญที่สุดสำหรับการแก้ปัญหาอย่างเป็นระบบคือ "คำถาม"
ในการแก้ปัญหาที่เราเห็นทั่วๆ ไปมักแก้โดยการเรียนรู้หรือประสบการณ์เก่าๆ เช่น ช่างซ่อมอุปกรณ์ต่างๆ แต่เมื่อปัญหาซับซ้อนขึ้น ปัญหาสำคัญมากๆ หรือต้องการความแม่นยำในการแก้ปัญหา หรือในสถาณการณ์ที่ต้องการคำตอบอย่างเร่งด่วน หรืออยู่ในสภาวะวิกฤติต่างๆ การแก้ปัญหาแบบปกติมักนำมาใช้ไม่ได้ผล จึงจำเป็นอย่างยิ่งที่ต้องใช้การแก้ปัญหาอย่างเป็นระบบ ซึ่งจะสามารถนำไปสู่แนวทางการแก้ปัญหาที่แม่นยำ รวดเร็วและตรงประเด็น
การใช้การแนวทางแก้ปัญหาแบบทั่วๆ ไปมาใช้แก้ปัญหาที่วิกฤต (Critical) มักไม่ได้ผล เนื่องจากแนวทางการแก้ปัญหาทั่วๆไปจะอาศัยคความเคยชินและประสบการณ์ ซึ่งอุปสรรคที่สำคัญที่สุดของการแก้ปัญหาคือ "การด่วนสรุป (Jump to conclusion)" การด่วนสรุปที่เร็วเกินไปนำไปสู่วิธีการลงมือแก้ปัญหาทั้งๆ ที่ยังไม่รู้สาเหตุทีแท้จริง หลายๆ ครั้งการด่วนสรุปยิ่งสร้างปัญหาให้เลวร้ายลงไปอีก เช่น วิศวกรแก้ปัญหาด้านเทคนิคผิด หมอสั่งยาผิด ช่างซ่อมรถเปลี่ยนอะไหล่ผิด สายสืบติดตามสืบหาผู้ต้องสงสัยผิด ศาลตัดสินคดีผิด เป็นต้น ซึ่งผลที่ตามมาที่เจอบ่อยๆ คือทำให้เสียเวลา เสียแรง เสียงบประมาณในการแก้ปัญหาที่ไม่ถูกจุด ซึ่งเกิดจากการด่วนสรุปเร็วเกินไปนั่นเอง
แนวทางการแก้ปัญหาอย่างเป็นระบบประกอบด้วยขั้นตอนดังนี้
1. การรับรู้ปัญหา (Recognize Problem)
คือการรับทราบว่าปัญหาที่เกิดขึ้นคืออะไร อะไรคือสิ่งผิดปกติ รวบรวมข้อมูลทั้งหมดของปัญหาที่เกิดขึ้นและสิ่งที่อาจเกี่ยวข้องกับปัญหาให้ครอบคลุม อาจเรียกประชุมผู้เกี่ยวข้องหลายๆ ฝ่ายเพื่อประติดประต่อว่าปัญหาที่แท้จริงคืออะไร อาจรวบรวมข้อมูลอยู่ในรูปของแฟ้มข้อมูล หรืออาจต้องเก็บข้อมูลเพิ่มเติมจากผู้เกี่ยวข้องอื่นๆ ที่เป็นไปได้ เครืองมือที่ใช้ในการรวบรวมข้อมูลคือ "คำถาม"
หลายๆ ครั้งที่แก้ปัญหาผิดทางมักเกิดจากการรวบรวมข้อมูลไม่ครับ เมื่อข้อมูุลไม่ครบทำให้เกิดการด่วนสรุปและตามด้วยการเริ่มลงมือแก้แบบผิดทาง กว่าจะรู้ว่าผิดทางก็ทำให้เสียเงิน เสียเวลา เกิดความเสียหายมากขึ้นกว่าเดิม
2. สรุปรูปแบบเฉพาะของปัญหา (Develop Problem Specification)
เขียนสเปกของปัญหาโดยหาคำตอบของ "คำถาม" ดังต่อไปนี้
- อะไรที่มีปัญหา? vs อะไรที่คล้ายๆ กันที่น่าจะมีปัญหา แต่ไม่มีปัญหา?
- เกิดปัญหาที่ไหน? vs ที่ไหนที่น่าจะเกิดปัญหาเหมือนกัน แต่ไม่มีปัญหาเกิดขึ้น?
- เกิดปัญหาขึ้นเมื่อไหร่ vs เวลากไหนที่ไม่มีปัญหาเกิดขึ้น?
- ขนาดหรือจำนวนหรือความรุนแรง ของปัญหามีเท่าไหร่? vs ขนาด จำนวน ความรุนแรง อื่นๆ ที่ไม่เกิดปัญหา?
ซึ่งสามารถสรุปรูปแบบเฉพาะของปัญหาดังตารางดังนี้
3. หาสาเหตุที่เป็นไปได้ (Search for Possible Cause)
เริ่มจาก หาความเป็นเอกลักษณ์ (Uniqueness) ของปัญหาเปรียบเทียบกับสิ่งที่ไม่เป็นปัญหา และ อะไรที่มีการเปลี่ยนแปลงก่อนหรือในช่วงที่จะเกิดปัญหาได้แก่ เวลา สถานที่ บุคคล อุปกรณ์ การเพิ่ม การลด กระบวนการณ์ ฯลฯ จากนั้นให้ลิสต์สาเหตุที่เป็นไปได้ (ผู้ต้องสงสัย) มากที่สุด ขึ้นมา 3 - 5 สาเหตุ
กระบวนการนี้จำเป็นต้องทำงานร่วมกับผู้เชี่ยวชาญพิเศษหรือผู้อยู่หน้างานซึ่งมีทักษะและประสบการณ์จะทำให้ได้สาเหตุที่เป็นไปได้ที่ใกล้เคียงขึ้น แต่มีข้อควรระวังคือผู้ที่เชี่ยวชาญพิเศษหรือผู้อยู่หน้างานมักจะด่วนสรุปสาเหตุปัญหาซึ่งทำให้หลงประเด็นได้เช่นกัน
4. เทียบสาเหตุที่เป็นไปได้กับสเปกปัญหา (Test Possible Causes)
นำลิสต์สาเหตุที่เป็นไปได้มาเทียบกับสเปกของปัญหาในข้อ 2. โดยตั้งคำถามว่าถ้าสาเหตุนั้นๆ เป็นต้นเหตุของปัญหาแล้ว สามารถตอบคำถามได้ทุกข้อหรือไม่ เช่น สาเหตุของปัญหาที่เป็นไปได้คือ "เกิดจากอุปกรณ์ A" เพราะเริ่มเอาอุปกรณ์ A มาใช้งานช่วงเวลาเดียวกันกับตอนเกิดปัญหา แล้วทำไมอุปกรณ์ B ไม่เกิดปัญหาทั้งๆ ที่เริ่มนำใช้พร้อมกับอุปกรณ์ A เป็นต้น อาจมีการตั้งสมมติฐานเมื่อไม่ทราบคำตอบเพื่อทดลองหรือทดสอบในขั้นตอนต่อไป
ซึ่งหลังจากเทียบสาเหตุที่เป็นไปได้กับสเปกปัญหา จะพบว่าสาเหตุที่เป็นไปได้บางข้อจะถูกตัดออกจากลิสต์เพราะไม่สมเหตุสมผล จะเหลือสาเหตุที่เป็นไปได้ไม่กี่ข้อ
จากนั้นให้เลือก "สาเหตุที่เป็นไปได้มากที่สุด" (Most Possible Cause) มา 1 ข้อ พร้อมกับสมมติฐานที่ต้องสืบสวน ทดสอบ หรือทดลองต่อไป
5. ทดสอบสาเหตุที่แท้จริง (Verify Real Cause)
เมื่อได้ "สาเหตุที่เป็นไปได้ที่สุด" มาแล้ว ให้วางแผนเพื่อทดสอบ ตรวจสอบ ทดลอง หรือสืบสวน ว่าเป็นต้นเหตุที่แท้จริงหรือไม่ เช่นเปลี่ยนอุปกรณ์ เพิ่มระบบมอนิเตอร์ ติดตามผล ซึ่งอาจต้องอาศัยผู้เชียวชาญพิเศษในเรื่องนั้นๆ ช่วยวางแผนเพื่อวิเคราะห์ ซึ่งกระบวนการนี้บางครั้งอาจต้องใช้เวลา แต่ประเด็นที่สำคัญคือถ้าตรวจสอบแล้วยังครุมเครือ ก็ไม่สามารถ "ด่วนสรุป" เด็ดขาด อาจทบทวนสาเหตุที่เป็นไปได้ที่รองลงมาทำการทดสอบได้เช่นกัน
ทั้ง 5 ข้อนี้เป็นกระบวนการที่ผู้เขียนใช้มาตลอดในการแก้ปัญหาด้านวิศวกรรม 10 กว่าปีซึ่งสามารถแก้ปัญหาที่ซับซ้อนได้ค่อนข้างตรงจุดและรวดเร็ว จริงๆ แล้วการแก้ปัญหาอย่างเป็นระบบยังสามารถนำมาใช้แก้ปัญหาแบบธรรมดาได้เช่นกัน แต่เนื่องจากกระบวนการที่ดูเยอะทำให้คนหันไปใช้วิธีการเดิมๆ เพราะคิดว่าน่าจะแก้ปัญหาได้เร็วกว่า และพบว่าการแก้ปัญหาอย่างเป็นระบบนี้ไม่จำกัดในงานที่ชี่ยวชาญเท่านั้น หลายๆ ครั้งพบว่าหัวหน้างานที่ใช้เทคนิคการแก้ปัญหาอย่างเป็นระบบสามารถแก้ปัญหากับงานที่แม้ไม่เชี่ยวชาญได้ ด้วยการตั้ง "คำถาม" กับผู้อยู่หน้างานและนำไปสู่สาเหตุที่แท้จริงของปัญหาในที่สุด
ปัจจุบันมีสถาบันที่เปิดสอนคอสการแก้ปัญหาอย่างเป็นระบบมากมาย และมักจะสอนควบคูู่กับคอสการตัดสินใจอย่างเป็นระบบ (Systematic Decision Making) ซึ่งอาจต้องหาสถาบันที่น่าเชื่อถือและมีประสบการณ์ในการสอน หรือผู้สอนมีทักษะการแก้ปัญหาอย่างเป็นระบบโดยตรง จึงเป็นสิ่งจำเป็นอย่างยิ่งที่องค์กรที่ต้องการพัฒนาบุคครากรให้มีประสิทธิภาพต้องส่งพนักงานไปอบรมหลักสูตรนี้ อย่างไรก็ตามสิ่งที่จำเป็นหลังจากการอบรมณ์ คือ การนำมาฝึกใช้อย่างสม่ำเสมอจนอยู่ในสายเลือดจึงจะเกิดประโยชน์อย่างแท้จริงทั้งกับผู้เรียนและองค์กร
บรรพต เคลียพวงพิทย์
