Weakness, Threat และ Risk ประเด็นที่ควรแยกให้ชัด
จากประสบการณ์การทำงานที่ผ่านมา ผู้เขียนพบอยู่บ่อยครั้งว่า เมื่อองค์กรจัดทำ Risk ต่อจากการวิเคราะห์ SWOT รายการ Risk ที่ได้มักมีลักษณะอยู่สองแบบ
แบบแรก คือดูคล้ายกับ Weakness หรือ Threat เดิม เพียงแต่นำมาเขียนใหม่โดยเติมคำว่า “ความเสี่ยงจาก...” เข้าไปข้างหน้า
อีกแบบหนึ่ง คือเขียนกว้างมาก เช่น ความเสี่ยงจากการแข่งขัน ความเสี่ยงจากเศรษฐกิจ ความเสี่ยงจากบุคลากร หรือความเสี่ยงจากเทคโนโลยี ซึ่งอ่านแล้วก็เข้าใจว่าเป็นเรื่องสำคัญ แต่ยังไม่ค่อยเห็นชัดว่า อะไรคือสิ่งที่อาจเกิดขึ้น และองค์กรควรเข้าไปจัดการตรงไหน
ตัวอย่างเช่น
Weakness เขียนว่า
รายได้ของหน่วยธุรกิจพึ่งพาลูกค้ารายเดียวในสัดส่วนสูง
เมื่อมาถึง Risk กลายเป็น
ความเสี่ยงจากการพึ่งพาลูกค้ารายเดียว
หรือ Threat เขียนว่า
งบประมาณภาครัฐสำหรับโครงการประเภทที่องค์กรรับงานอยู่มีแนวโน้มลดลง
เมื่อมาถึง Risk กลายเป็น
ความเสี่ยงจากงบประมาณภาครัฐลดลง
ข้อความเหล่านี้ไม่ได้ผิดเสียทีเดียว
แต่มีปัญหาอยู่สองเรื่อง
เรื่องแรกคือ เมื่อเปลี่ยนจาก SWOT มาเป็น Risk แล้ว เราแทบไม่ได้เห็นอะไรเพิ่มขึ้นจากเดิม
เรื่องที่สองคือ Risk ที่เขียนในลักษณะนี้มักกว้างเกินไป จนอ่านแล้วรู้เพียงว่า “เป็นเรื่องน่ากังวล” แต่ยังไม่ชัดว่า เรากำลังกังวลว่าอะไรจะเกิดขึ้น และถ้าเกิดขึ้นแล้วจะทำให้เราเสียอะไร
Weakness, Threat และ Risk ไม่ได้ตอบคำถามเดียวกัน
Weakness ใช้มองข้อจำกัดจากภายในองค์กร ส่วน Threat ใช้มองปัจจัยจากภายนอกที่อาจส่งผลในทางลบต่อองค์กร
ถ้าจะสรุปสั้น ๆ
Weakness ถามว่า ภายในเรามีข้อจำกัดอะไร
Threat ถามว่า ภายนอกมีอะไรที่อาจกระทบเรา
ส่วน Risk ถามว่า
อะไรอาจเกิดขึ้น และทำให้สิ่งที่เราต้องการทำให้สำเร็จ ไม่เป็นไปตามเป้าหมาย
Weakness และ Threat ช่วยให้เราเข้าใจสภาพที่องค์กรกำลังเผชิญ แต่ Risk ต้องคิดต่อไปอีกว่า สภาพเหล่านั้นจะมีผลอย่างไรต่อ Objective ที่องค์กรกำลังพยายามทำให้สำเร็จ
แนวคิดนี้สอดคล้องกับ ISO 31000 ซึ่งผูก Risk เข้ากับผลของความไม่แน่นอนที่มีต่อวัตถุประสงค์โดยตรง
เพราะฉะนั้น ถ้ายังไม่รู้ว่า Objective คืออะไร การเขียน Risk ให้ชัดก็มักทำได้ยาก และมีโอกาสสูงที่จะจบลงด้วยข้อความกว้าง ๆ ที่นำไปบริหารต่อได้ไม่ง่าย
ลูกค้ารายเดียว จาก Weakness ไปสู่ Risk
สมมติหน่วยธุรกิจแห่งหนึ่งมีรายได้มากกว่าครึ่งหนึ่งมาจากลูกค้ารายใหญ่เพียงรายเดียว
ใน SWOT ข้อมูลนี้อาจถูกเขียนเป็น Weakness ว่า
รายได้ของหน่วยธุรกิจพึ่งพาลูกค้ารายเดียวในสัดส่วนสูง
ก็ถือว่าสมเหตุสมผล เพราะสะท้อนข้อจำกัดของรูปแบบธุรกิจในปัจจุบัน
แต่หากนำข้อความเดิมไปเขียนใน Risk Register ว่า
ความเสี่ยงจากการพึ่งพาลูกค้ารายเดียว
เราแทบไม่ได้รู้อะไรเพิ่มขึ้น และข้อความก็ยังกว้างเกินกว่าจะเห็นว่า Risk ที่แท้จริงคืออะไร
สิ่งที่ควรถามต่อคือ ถ้าเราพึ่งพาลูกค้ารายเดียว มีอะไรที่อาจเกิดขึ้นได้บ้าง และถ้าเกิดขึ้นแล้วจะกระทบเป้าหมายอะไร
เช่น
หากลูกค้ารายหลักลดงบประมาณ ชะลอโครงการ หรือเปลี่ยนนโยบายการว่าจ้าง หน่วยธุรกิจอาจไม่สามารถหางานจากลูกค้ารายอื่นมาทดแทนได้ทัน ส่งผลให้รายได้และการใช้กำลังบุคลากรต่ำกว่าเป้าหมาย
จากเดิมที่รู้เพียงว่า “พึ่งพาลูกค้ารายเดียว” ตอนนี้เราเริ่มเห็นแล้วว่า อะไรอาจเกิดขึ้น และถ้าเกิดขึ้นจะกระทบตรงไหน
Risk จึงเริ่มเฉพาะเจาะจงขึ้น และนำไปสู่การคิดเรื่องการจัดการได้จริง
Threat ก็ต้องคิดต่ออีกขั้น
สมมติ SWOT ระบุ Threat ว่า
งบประมาณภาครัฐสำหรับโครงการประเภทที่หน่วยธุรกิจรับงานอยู่มีแนวโน้มลดลง
หากยกข้อความนี้ไปเขียนเป็น
ความเสี่ยงจากงบประมาณภาครัฐลดลง
ก็ยังแทบไม่ได้คิดอะไรเพิ่มจากเดิม
คำถามที่ควรถามต่อคือ ถ้างบประมาณลดลงจริง ผลจะไปตกตรงไหน
Risk อาจเขียนเป็น
หากงบประมาณสำหรับโครงการประเภทเดิมลดลงเร็วกว่าที่องค์กรสามารถพัฒนาตลาดหรือฐานลูกค้าใหม่ได้ จำนวนงานใหม่อาจไม่เพียงพอทดแทนโครงการที่กำลังสิ้นสุด ส่งผลต่อรายได้และความสามารถในการรักษาทีมงานหลักของหน่วยธุรกิจ
Threat เดิมยังเป็นข้อมูลสำคัญ แต่สิ่งที่เพิ่มขึ้นคือความเข้าใจว่า Threat นั้นอาจกระทบเป้าหมายอย่างไร
Risk ต้องเชื่อมกับ Objective
จากประสบการณ์ของผู้เขียน ปัญหาหนึ่งที่พบอยู่บ่อยคือ การเริ่มทำ Risk ด้วยคำถามว่า
“หน่วยงานของเรามีความเสี่ยงอะไรบ้าง”
คำถามนี้ไม่ได้ผิด แต่กว้างมาก
สิ่งที่ได้กลับมาจึงมักเป็นรายการในลักษณะ
- ความเสี่ยงจากการแข่งขัน
- ความเสี่ยงจากเศรษฐกิจ
- ความเสี่ยงจากบุคลากร
- ความเสี่ยงจากเทคโนโลยี
- ความเสี่ยงจากการพึ่งพาลูกค้ารายใหญ่
อ่านแล้วดูเหมือนถูกทุกข้อ
แต่พอถามว่า
“มีอะไรที่อาจเกิดขึ้นได้บ้าง?”
หรือ
“ถ้าเกิดขึ้นแล้ว Objective ไหนจะได้รับผลกระทบ?”
กลับตอบได้ไม่ง่าย
นี่คืออาการของ Risk ที่ยัง “กว้าง” มากกว่า “แหลม”
จุดตั้งต้นที่น่าจะช่วยได้มากกว่าคือเริ่มจาก Objective ก่อน
เรากำลังพยายามทำอะไรให้สำเร็จ
แล้วจึงถามต่อว่า
มีอะไรที่อาจทำให้สิ่งนั้นไม่สำเร็จ
เพียงเปลี่ยนคำถาม Risk ที่ได้ก็มักมีขอบเขตชัดขึ้นมาก
ตัวอย่างจากงานควบคุมงานก่อสร้าง Green
สมมติหน่วยธุรกิจควบคุมงานก่อสร้างกำหนด Strategy ว่าต้องการขยายเข้าสู่งานด้าน Green Construction
Strategy ดังกล่าวอาจถูกแปลงเป็น Objective เช่น
เพิ่มสัดส่วนรายได้จากงานควบคุมงานก่อสร้างที่เกี่ยวข้องกับ Green Building และ Sustainable Infrastructure
เมื่อ Objective ชัด คำถามเรื่อง Risk ก็เปลี่ยนไป
แทนที่จะถามว่า
หน่วยธุรกิจของเรามีความเสี่ยงอะไรบ้าง
เราจะถามว่า
อะไรอาจทำให้เราไม่สามารถเพิ่มสัดส่วนงาน Green Construction ได้ตามเป้าหมาย
ประเด็นที่ต้องพิจารณาจะเริ่มเฉพาะขึ้นทันที
องค์กรอาจยังมี Reference Project ด้าน Green Construction ไม่เพียงพอ
Key Personnel อาจยังไม่มีประสบการณ์หรือ Certification ที่ TOR ต้องการ
คู่แข่งอาจมี Track Record ในตลาดนี้มากกว่า
หรือจำนวนโครงการที่เกิดขึ้นจริงอาจน้อยกว่าที่คาดการณ์ไว้ตอนวาง Strategy
Risk จึงอาจเขียนเป็น
หากองค์กรยังไม่มี Reference Project และ Key Personnel ที่มีคุณสมบัติตรงตามเงื่อนไขของ TOR สำหรับงาน Green Construction อาจไม่สามารถผ่านคุณสมบัติเบื้องต้นหรือแข่งขันด้าน Technical Proposal ได้อย่างมีประสิทธิภาพ ส่งผลให้ไม่สามารถเพิ่มสัดส่วนรายได้จากตลาดดังกล่าวได้ตามเป้าหมาย
เมื่อเทียบกับข้อความว่า
ความเสี่ยงจากการขาดประสบการณ์ด้าน Green Construction
จะเห็นว่าข้อความแรกพาเราไปไกลกว่า เพราะไม่เพียงบอกว่าข้อจำกัดคืออะไร แต่ทำให้เห็นด้วยว่าข้อจำกัดนั้นอาจทำให้ Objective พลาดตรงไหน
และที่สำคัญคือ ทำให้ Risk แคบลงจนพอจะคิดต่อเรื่อง Risk Plan ได้
จุดที่มักหายไป คือการเชื่อมกับ Objective
Weakness และ Threat ไม่ได้แยกขาดจาก Risk
ในทางตรงกันข้าม ทั้งสองอย่างเป็นข้อมูลตั้งต้นที่ดีมากสำหรับการค้นหา Risk
ปัญหาเกิดขึ้นเมื่อเราเอา Weakness หรือ Threat ไปวางใน Risk Register โดยตรง แล้วเปลี่ยนรูปประโยคเล็กน้อย หรือเขียนเป็นหัวข้อกว้าง ๆ โดยไม่ได้วิเคราะห์ต่อ
กระบวนการคิดที่น่าจะมีประโยชน์กว่าคือ
Weakness / Threat
↓
เงื่อนไขที่องค์กรกำลังเผชิญ
↓
เชื่อมกับ Objective
↓
อะไรอาจเกิดขึ้น
↓
หากเกิดแล้ว Objective จะได้รับผลอย่างไร
↓
Risk
จุดที่สำคัญที่สุดอยู่ตรงกลาง
เชื่อมกับ Objective
หากข้ามขั้นนี้ไป Weakness และ Threat ก็มีโอกาสกลายเป็น Risk ที่เพียงเปลี่ยนชื่อ หรือกลายเป็น Risk ที่กว้างจนแทบไม่รู้ว่าต้องจัดการอะไร
Risk ที่กว้างเกินไป มักบริหารยาก
เปรียบเทียบสองข้อความนี้
ความเสี่ยงจากการพึ่งพาลูกค้ารายเดียว
กับ
หากลูกค้ารายหลักลดงบประมาณหรือชะลอการว่าจ้าง หน่วยธุรกิจอาจไม่สามารถหางานจากลูกค้ารายอื่นมาทดแทนได้ทัน ส่งผลให้รายได้ต่ำกว่าเป้าหมาย
ข้อความแรกทำให้เรารู้ว่า “กังวลเรื่องอะไร”
ข้อความที่สองเริ่มทำให้รู้ว่า “ต้องจัดการตรงไหน”
จากนั้นคำถามต่อก็ตามมาเอง
สัดส่วนรายได้จากลูกค้ารายเดียวสูงเกินไปหรือยัง
Pipeline จากลูกค้ารายอื่นมีเพียงพอหรือไม่
ต้องเริ่มพัฒนาตลาดใหม่เมื่อใด
ถ้าลูกค้ารายหลักลดการว่าจ้างลงจริง มีงานอื่นรองรับหรือไม่
และควรมี Risk Plan อย่างไร
ผู้เขียนมองว่านี่เป็นเกณฑ์ง่าย ๆ ข้อหนึ่งในการดูคุณภาพของ Risk
ถ้าอ่านแล้วทำให้เกิดคำถามว่า
“เราจะจัดการเรื่องนี้อย่างไร”
Risk นั้นเริ่มมีประโยชน์
แต่ถ้าอ่านแล้วได้เพียงความรู้สึกว่า
“ใช่ เรื่องนี้น่ากังวล”
ก็อาจยังไม่แหลมคมพอ
KPI และ Risk ควรเกิดขึ้นขนานกัน
เมื่อพูดถึง Objective แล้ว มีอีกเรื่องหนึ่งที่ควรแยกให้ชัด
Risk ไม่ใช่ขั้นตอนที่ต้องทำให้เสร็จก่อน แล้วจึงไปเขียน KPI
ในทางกลับกัน KPI ก็ไม่จำเป็นต้องทำเสร็จก่อนจึงค่อยมอง Risk
เมื่อ Strategy ถูกแปลงเป็น Objective แล้ว ทั้ง KPI และ Risk สามารถพัฒนาขึ้นควบคู่กันไป
↓
Objective
| KPI | Risk |
| ↓ | ↓ |
| Target / Action | Risk Plan |
ทั้งสองด้านกำลังมอง Objective เดียวกัน แต่ถามคนละเรื่อง
KPI ถามว่า
เราจะรู้ได้อย่างไรว่าเรากำลังไปถึงเป้าหมาย
Risk ถามว่า
มีอะไรที่อาจทำให้เราไปไม่ถึงเป้าหมาย
หาก Objective คือเพิ่มสัดส่วนรายได้จากงานควบคุมงานก่อสร้างด้าน Green
KPI อาจเป็น
สัดส่วนรายได้จากงาน Green Construction ต่อรายได้รวมของหน่วยธุรกิจ
ส่วน Risk อาจเป็น
หากองค์กรไม่มี Reference Project และ Key Personnel ที่ตรงตามเกณฑ์ของ TOR อาจไม่สามารถแข่งขันในตลาดเป้าหมายได้ตามแผน
จากนั้นจึงคิดต่อว่าจะมี Risk Plan อย่างไร
KPI และ Risk จึงไม่ได้เรียงต่อกันเป็นลำดับ แต่เกิดจาก Objective เดียวกัน
ด้านหนึ่งดูว่า เราเดินไปถึงเป้าหมายหรือยัง
อีกด้านหนึ่งดูว่า มีอะไรอาจทำให้เราไปไม่ถึง
แนวคิดนี้สอดคล้องกับกรอบ Enterprise Risk Management ของ COSO ซึ่งให้ความสำคัญกับการเชื่อม Risk เข้ากับ Strategy และ Business Objectives
Risk Register ที่ดีควรช่วยให้เกิดการตัดสินใจ
ท้ายที่สุด ผู้เขียนมองว่าคุณค่าของ Risk Management ไม่ได้อยู่ที่ Risk Register มีจำนวนรายการมากหรือน้อย หรือกรอกได้ครบทุกช่อง
คำถามที่สำคัญกว่าคือ
Risk ที่เขียนขึ้น ช่วยให้เกิดการตัดสินใจอะไรหรือไม่
Risk ที่เขียนว่า
ความเสี่ยงจากการแข่งขัน
ฟังดูถูกต้อง แต่กว้างมากจนยังตอบยากว่าจะทำอะไรต่อ
ในทางกลับกัน หากเขียนว่า
หากคู่แข่งที่มี Reference Project ด้าน Green Construction มากกว่าสามารถเข้าสู่ตลาดได้เร็วกว่าที่องค์กรสร้างผลงานอ้างอิงของตนเอง อาจทำให้องค์กรเสียโอกาสสร้าง Position ในตลาดใหม่และไม่สามารถเพิ่มรายได้ตามเป้าหมาย
คำถามต่อเริ่มชัดขึ้นทันที
ควรหาพันธมิตรเพื่อเข้าสู่ตลาดเร็วขึ้นหรือไม่
ควรเลือกโครงการใดเป็นโครงการแรกสำหรับสร้าง Reference
ต้องพัฒนา Key Personnel ด้านใด
ควรลงทุนเพื่อเข้าสู่ตลาดมากเพียงใด
หรือหากเงื่อนไขตลาดเปลี่ยนไปจากสมมติฐานเดิม ควรปรับ Strategy หรือไม่
ถ้า Risk พาไปถึงคำถามเหล่านี้ได้ การบริหารความเสี่ยงก็เริ่มมีบทบาทต่อการตัดสินใจจริง
ไม่ใช่เพียงมีไว้ให้ครบในระบบ
จาก “เรากังวลอะไร” ไปสู่ “เราอาจพลาดอะไร”
Weakness และ Threat ยังมีความสำคัญต่อการวิเคราะห์เชิงกลยุทธ์
ปัญหาไม่ได้อยู่ที่การนำ Weakness และ Threat มาใช้ประกอบการค้นหา Risk
ปัญหาเกิดขึ้นเมื่อเราหยุดคิดเร็วเกินไป แล้วนำข้อความเหล่านั้นมาเปลี่ยนชื่อเป็น Risk หรือเขียน Risk ไว้กว้าง ๆ โดยไม่ได้เชื่อมกลับไปหาสิ่งที่องค์กรกำลังพยายามทำให้สำเร็จ
ก่อนจะเขียน Risk สักรายการ ผู้เขียนคิดว่าอาจลองถามเพียงสามคำถาม
เรากำลังพยายามทำอะไรให้สำเร็จ
อะไรอาจเกิดขึ้นและขวางสิ่งนั้น
ถ้าเกิดขึ้นแล้ว เราจะพลาดอะไร
สามคำถามนี้อาจไม่ได้ทำให้ Risk Register ยาวขึ้น
แต่อาจทำให้แต่ละรายการแหลมคมขึ้น และมีประโยชน์ต่อการบริหารมากขึ้น
เพราะท้ายที่สุด
Risk ที่ดีไม่ควรเพียงบอกว่า “เรากังวลเรื่องอะไร” แต่ควรทำให้เห็นว่า “เรากำลังจะพลาดอะไร เพราะอะไร”
แหล่งอ้างอิง
- International Organization for Standardization (ISO). ISO 31000:2018 — Risk management — Guidelines.
- International Organization for Standardization (ISO). The new ISO 31000 keeps risk management simple. 2018.
- Committee of Sponsoring Organizations of the Treadway Commission (COSO). Enterprise Risk Management — Integrating with Strategy and Performance.
- Chartered Institute of Personnel and Development (CIPD). SWOT analysis Factsheet.
Comments
Post a Comment