Risk Management: The Hard Test
ท้ายหนังสือ Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency ของ Tom DeMarco ได้ให้เทคนิคใหม่ในการจัดการความเสี่ยงกับผม ทอมสอนว่าในการทำงานยุคปัจจุบัน งานมีความเสี่ยงกระจายอยู่เต็มไปหมด ซึ่งในความเสี่ยงนั้น เรามีโอกาสโชคดีและมีโอกาสโชคร้าย
การจัดการความเสี่ยงเป็นสิ่งที่เราทำแบบ Just-in-case หมายถึง กันไว้ก่อนเผื่อมันจะเกิดขึ้น เพราะถ้ารอให้มันเกิดแล้วค่อยทำแบบ Just-in-time มันมักจะไม่ทันการณ์แล้ว เช่น การทำ Security Test กันไว้ก่อนเผื่อระบบโดนเจาะ เป็นต้น
ทุก ๆ Just-in-case ล้วนมีค่าใช้จ่าย ซึ่งหมายถึงผลกำไรที่ลดลงจากการลงทุนบริหารความเสี่ยง หนังสือเล่าว่ารากของการบริหารความเสี่ยงนั้นเกิดขึ้นในโดเมน (Domain) ของธุรกิจประกัน คือถ้าเราเดาถูกก็จะได้กำไร แต่ถ้าเดาผิดก็ขาดทุน การบริหารความเสี่ยงจึงคือการปรับ Portfolio เพื่อให้เวลาเราเดาผิด เราจะขาดทุนน้อยลง โดยยอมให้กำไรลดลงหน่อยเมื่อเราเดาถูก
ในหนังสือปิดท้ายด้วย Test ยาก ๆ 9 ข้อ ที่เป็นตัวพิสูจน์ว่า งานที่เรากำลังทำอยู่มีการบริหารความเสี่ยงที่แท้จริงไหม ดังนี้ครับ
- มีรายการความเสี่ยงที่ทุกคนเห็นพ้องต้องกันไหม? มีความเสี่ยงระดับวิกฤตไหม หรือมีแค่ความเสี่ยงของผลลัพธ์ที่เรากลัว? รายการนี้ทุกคนที่ทำงานในโปรเจกต์ (Project) มองเห็นร่วมกันไหม? และในรายการมีความเสี่ยงมากพอที่จะแสดงว่ามีการวิเคราะห์ความเสี่ยงอย่างระมัดระวังแล้วหรือยัง?
- มีกลไกในการหาความเสี่ยงใหม่ ๆ ในพื้นที่ทำงานไหม? มันปลอดภัยพอที่พนักงานทุกคนจะส่งสัญญาณเตือนความเสี่ยงได้โดยไม่ต้องกลัวโดนตำหนิไหม?
- มีความเสี่ยงที่อันตรายและส่งผลกระทบรุนแรงอยู่ในรายการแล้วหรือยัง? เพราะความเสี่ยงประเภทนี้คือสิ่งที่เราต้องให้ความสนใจมากที่สุด
- แต่ละความเสี่ยงมีการคำนวณตัวเลขความน่าจะเป็น, ค่าใช้จ่าย และผลกระทบต่อแผนงาน (Schedule) ไว้ไหม?
- แต่ละความเสี่ยงมีรายละเอียดระบุไว้หรือยังว่าสัญญาณอะไรกำลังบอกว่ามันเกิดขึ้นแล้ว? และแต่ละสัญญาณเหล่านั้นถูกจับตามองอยู่จริงไหม?
- มีคนคนเดียวที่รับผิดชอบกับความเสี่ยงนั้น ๆ อยู่ไหม? เพราะถ้ามีหลายคนร่วมกันจัดการความเสี่ยง สุดท้ายจะแปลว่าไม่มีใครจัดการเลย เนื่องจากทุกคนต่างทำ "งานจริง" บนโต๊ะของตัวเองอยู่
- ในบรรดางานที่แตกย่อยออกมา มีงานไหนไหมที่ไม่ต้องทำก็ได้? ถ้าไม่มีงานประเภทนี้อยู่เลย นั่นเป็นสัญญาณเตือนว่าไม่มีการบริหารความเสี่ยงในที่ทำงาน
- ภาพรวมของงาน มีการแยกแผนงาน (Schedule) กับเป้าหมาย (Goal) ออกจากกันไหม? ถ้า Schedule กับ Goal หน้าตาเหมือนกัน แสดงว่าไม่มีการบริหารความเสี่ยง วันที่เร็วที่สุดที่งานจะเสร็จได้อาจเป็น Goal ที่ดี แต่เป็น Schedule ที่แย่มากในมุมของการบริหารความเสี่ยง
- มีโอกาสพอสมควรที่งานจะเสร็จก่อนวันที่คาดไว้ไหม? (ประมาณ 20-30% ก่อนเวลา) ถ้าไม่มี... แผนงานนั้นก็คือเป้าหมาย (Goal) ไม่ใช่การประมาณการ (Estimation)
หนังสือบอกว่า เราต้องผ่านทั้ง 9 ข้อนี้ ถึงจะเรียกว่ามีการบริหารความเสี่ยงอย่างเหมาะสม ถ้าข้อไหนไม่ผ่าน ลองคิดถึงผลกระทบที่จะตามมาเมื่อความเสี่ยงนั้นเกิดขึ้นจริง เราก็จะเข้าใจได้เองว่าทำไมแต่ละข้อถึงจำเป็น
หลังจากได้เรียนรู้เรื่องนี้ ผมเริ่มเรียนรู้ที่จะแยก Schedule กับ Goal ออกจากกัน ถ้าผมได้ยินว่างานนี้จะเสร็จวัน X ผมจะเริ่มถามหา Best Case และ Worst Case แล้วเอาไปใส่กราฟระฆังคว่ำ (Normal Distribution) เพื่อประเมินความเสี่ยง
ที่ผมเอาเรื่องนี้มาแบ่งปันเพราะ ทุกบาททุกสตางค์ที่ลงไปกับการบริหารความเสี่ยง คือผลกำไรที่หายไปขององค์กร ลงทุนเยอะไปก็จน แต่ถ้าลงทุนน้อยไป เวลาความเสี่ยงเกิดขึ้นจริงก็วุ่นวาย ยิ่งองค์กรรีด Performance ไว้ตึงเปรี้ยะแค่ไหน ความยืดหยุ่น (Slack) ที่จะใช้จัดการกับความเสี่ยงก็ยิ่งน้อยลงเท่านั้นครับ
