ยินดีต้อนรับสู่บทเรียนเรื่องความยืดหยุ่นในการดำเนินงาน (Operational Resilience)!
สวัสดีครับ! ยินดีต้อนรับเข้าสู่บทเรียนที่นำไปใช้ได้จริงและใกล้เคียงกับ "โลกการทำงานจริง" มากที่สุดบทหนึ่งในหลักสูตร FRM Part II ครับ ในอดีตธนาคารส่วนใหญ่มุ่งเน้นไปที่การ ป้องกัน ไม่ให้เกิดปัญหา แต่ในปัจจุบันทั้งหน่วยงานกำกับดูแลและผู้บริหารต่างตระหนักแล้วว่า ต่อให้เราพยายามแค่ไหนก็ตาม สิ่งต่างๆ ก็ มีโอกาสที่จะพังลงได้อยู่ดี (ลองนึกถึงเหตุการณ์การโจมตีทางไซเบอร์ ไฟฟ้าดับ หรือแม้แต่การระบาดใหญ่ดูนะครับ)
บทนี้จะว่าด้วยเรื่องของ ความยืดหยุ่นในการดำเนินงาน (Operational Resilience) ครับ แทนที่เราจะถามแค่ว่า "เราจะทำอย่างไรไม่ให้เกิดเหตุการณ์นี้?" ตอนนี้เราเปลี่ยนมาถามว่า "เมื่อเหตุการณ์นี้เกิดขึ้นแล้ว เราจะรักษาส่วนที่สำคัญที่สุดของธุรกิจให้ดำเนินต่อไปได้อย่างไร เพื่อไม่ให้กระทบต่อลูกค้าหรือระบบเศรษฐกิจ?" มาเริ่มกันเลยครับ!
1. ความยืดหยุ่นในการดำเนินงานคืออะไร?
ความยืดหยุ่นในการดำเนินงาน (Operational Resilience) คือความสามารถขององค์กรในการป้องกัน การปรับตัว การตอบสนอง การฟื้นตัว และที่สำคัญคือ การเรียนรู้ จากเหตุการณ์หยุดชะงักในการดำเนินงานครับ นี่คือการเปลี่ยนผ่านทางความคิด (Shift in mindset) จากเดิมที่เน้นแค่ "การวางแผนความต่อเนื่องทางธุรกิจ (Business Continuity Planning)" ไปสู่มุมมองแบบองค์รวมเพื่อการอยู่รอด
ความแตกต่างที่สำคัญ:
การบริหารความเสี่ยงแบบดั้งเดิมมักจะถามว่า: "โอกาสที่เซิร์ฟเวอร์จะล่มมีเท่าไหร่?"
แต่ Operational Resilience จะถามว่า: "เซิร์ฟเวอร์ล่มไปแล้ว เราจะให้บริการลูกค้าต่อไปได้อย่างไรในระหว่างที่เราแก้ไขมัน?"
เปรียบเทียบให้เห็นภาพ: รถยนต์สมัยใหม่
ลองนึกถึงระบบความปลอดภัยของรถยนต์นะครับ มาตรการ "ป้องกัน" ก็คือเบรก (ที่พยายามไม่ให้ชน) ส่วน "ความยืดหยุ่น" ก็คือถุงลมนิรภัยและโครงสร้างรถที่ช่วยซับแรงกระแทก ถึงแม้รถจะชนไปแล้ว แต่ "บริการ" (การรักษาชีวิตผู้โดยสาร) ก็ยังคงดำเนินต่อไปได้ครับ
ประเด็นสำคัญ: Operational Resilience ตั้งอยู่บนสมมติฐานว่าเหตุการณ์หยุดชะงัก จะเกิดขึ้นแน่นอน ดังนั้นจึงมุ่งเน้นไปที่การรักษาการให้บริการที่สำคัญให้ดำเนินต่อไปได้ในช่วงเวลาดังกล่าวครับ
2. บริการทางธุรกิจที่สำคัญ (Important Business Services - IBS)
ธนาคารหนึ่งแห่งทำกิจกรรมนับพันอย่าง ตั้งแต่การเคลียร์รายการเทรดมูลค่าหลายพันล้าน ไปจนถึงการพิมพ์โบรชัวร์วางไว้ที่หน้าเคาน์เตอร์ แต่บริการเหล่านั้นไม่ได้มีความสำคัญเท่ากันครับ เพื่อให้เกิดความยืดหยุ่น เราต้องระบุให้ได้ว่าอะไรคือ บริการทางธุรกิจที่สำคัญ (Important Business Services หรือ IBS)
IBS คือบริการที่องค์กรมอบให้กับผู้ใช้งานภายนอกหรือผู้มีส่วนได้ส่วนเสีย ซึ่งหากบริการนี้หยุดชะงักจะส่งผลดังนี้:
1. ก่อให้เกิดความเสียหายที่ไม่สามารถยอมรับได้ต่อ ผู้บริโภค
2. ก่อให้เกิดความเสี่ยงต่อ ความสมบูรณ์ของตลาด หรือเสถียรภาพทางการเงิน
ตัวอย่าง:
- เป็น IBS: การสามารถถอนเงินจากตู้ ATM หรือใช้บัตรเดบิตซื้อของอุปโภคบริโภคได้
- ไม่ใช่ IBS: การที่พนักงานสามารถเข้าใช้งานระบบจองวันลาพักร้อนภายในบริษัทได้
ทบทวนสั้นๆ: วิธีระบุ IBS ทำอย่างไร?
ให้โฟกัสที่ ผลลัพธ์ภายนอก ครับ อย่าเพิ่งไปดูที่กระบวนการภายใน ให้ดูว่าสิ่งที่ลูกค้าได้รับคืออะไร ถ้าลูกค้าได้รับความเสียหายรุนแรงหรือระบบเศรษฐกิจสั่นคลอนเมื่อบริการนั้นหยุดทำงาน แสดงว่านั่นคือ IBS ครับ
3. การกำหนดขีดความสามารถในการทนต่อผลกระทบ (Impact Tolerances)
เมื่อเรารู้แล้วว่าบริการไหนคือ IBS ของเรา ขั้นตอนต่อไปคือการตัดสินใจว่าเราสามารถรับ "ความเจ็บปวด" ได้มากแค่ไหนก่อนที่สถานการณ์จะกลายเป็นสิ่งที่ยอมรับไม่ได้ ซึ่งขีดจำกัดนี้เรียกว่า Impact Tolerance ครับ
Impact Tolerance คือระดับการหยุดชะงักที่ยอมรับได้สูงสุดของ IBS โดยวัดจากตัวชี้วัดที่เฉพาะเจาะจง (ส่วนใหญ่มักเป็นเวลา) สรุปง่ายๆ คือการที่องค์กรประกาศว่า: "เราสามารถยอมรับให้ระบบนี้ล่มได้ 4 ชั่วโมง แต่ถ้าเข้าชั่วโมงที่ 4 นาทีที่ 1 ความเสียหายต่อลูกค้าจะกลายเป็นสิ่งที่ไม่สามารถยอมรับได้แล้ว"
ปัจจัยสำคัญในการกำหนดค่าความทนทาน:
1. เวลา (Time): ตัวชี้วัดที่พบบ่อยที่สุด (เช่น "ต้องกู้คืนระบบให้ได้ภายใน 24 ชั่วโมง")
2. ปริมาณ (Volume): เช่น "เราสามารถยอมรับให้การเทรดล้มเหลวได้ 5% แต่ห้ามเกินกว่านั้น"
3. ความถูกต้องของข้อมูล (Data Integrity): เช่น "เราอาจยอมให้ข้อมูลที่ไม่จำเป็นบางอย่างสูญหายได้ แต่ยอดเงินในบัญชีต้องถูกต้อง 100%"
ถ้ารู้สึกว่ามันดูสับสน ไม่ต้องกังวลนะ! ให้จำไว้ว่า Impact Tolerance ต่างจาก Risk Appetite (ความเสี่ยงที่ยอมรับได้) ครับ Risk Appetite เกี่ยวกับสิ่งที่คุณ ต้องการ เสี่ยงเพื่อแสวงหากำไร ส่วน Impact Tolerance เกี่ยวกับ ขีดจำกัดสูงสุด ที่คุณจะยังประคองตัวได้ก่อนที่จะทำให้ลูกค้าผิดหวังหรือเกิดผลกระทบต่อตลาดครับ
ประเด็นสำคัญ: Impact Tolerance จะถูกกำหนดไว้ ณ จุดที่การหยุดชะงักเริ่มก่อให้เกิด ความเสียหายที่ไม่สามารถยอมรับได้ ไม่ใช่แค่ความ "ไม่สะดวก" ทั่วไป
4. การทำ Mapping: การเข้าใจความเชื่อมโยง
เพื่อที่จะปกป้องบริการใดบริการหนึ่ง คุณจำเป็นต้องรู้ว่ามันทำงานอย่างไร ซึ่งเราเรียกว่า Mapping ครับ คุณต้องระบุ "ทุกสิ่งทุกอย่าง" ที่ทำให้ IBS นั้นทำงานได้สำเร็จ
ลองใช้เทคนิคการจำว่า P.P.T.D. สำหรับการระบุทรัพยากร:
- People (คน): ใครเป็นคนทำงาน? พวกเขาทำงานอยู่ที่เดียวกันหมดเลยหรือไม่?
- Processes (กระบวนการ): ขั้นตอนการทำงานทีละสเต็ปเป็นอย่างไร?
- Technology (เทคโนโลยี): ใช้เซิร์ฟเวอร์ ซอฟต์แวร์ และเครือข่ายอะไรบ้าง?
- Data (ข้อมูล): ข้อมูลอะไรบ้างที่จำเป็นต้องใช้เพื่อให้บริการนี้สำเร็จ?
ข้อผิดพลาดที่พบบ่อย:
นักศึกษามักลืมเรื่อง บุคคลภายนอก (Third Parties) ครับ ถ้าธนาคารของคุณใช้ "Cloud Service X" ในการประมวลผลการชำระเงิน บุคคลภายนอกรายนั้นต้องถูกรวมอยู่ในแผนผังความเชื่อมโยงของคุณด้วย ถ้าเขาล่ม คุณก็ล่มด้วยเช่นกัน!
5. การทดสอบสถานการณ์: "รุนแรงแต่เป็นไปได้" (Severe but Plausible)
คุณจะรู้ได้อย่างไรว่าคุณมีความยืดหยุ่นจริงๆ? ก็ต้องทดสอบสิครับ! แต่การทดสอบไม่ใช่แค่การลองทำเรื่องง่ายๆ นะครับ เราต้องทดสอบด้วยสถานการณ์ที่ รุนแรงแต่เป็นไปได้ (Severe but Plausible)
คำว่า "รุนแรงแต่เป็นไปได้" หมายความว่าอย่างไร?
- รุนแรง (Severe): สิ่งที่สร้างความเสียหายอย่างหนัก เช่น ศูนย์ข้อมูลล่มทั้งระบบ หรือการโจมตีทางไซเบอร์ครั้งใหญ่
- เป็นไปได้ (Plausible): มันมีโอกาสเกิดขึ้นจริงๆ "ซอมบี้บุกโลก" อาจจะรุนแรง แต่ไม่ถือว่า "เป็นไปได้" ในโลกการเงิน ส่วน "การระบาดใหญ่ระดับโลก" ที่บางคนเคยคิดว่าเป็นไปไม่ได้ ตอนนี้เรารู้แล้วว่ามันเป็นสถานการณ์ที่เกิดขึ้นได้จริงๆ!
ขั้นตอนในการทดสอบ:
1. เลือกสถานการณ์: เช่น การอัปเดตซอฟต์แวร์ครั้งใหญ่ล้มเหลวและทำให้ฐานข้อมูลเสียหาย
2. ทดสอบการตอบสนอง: เราสามารถสลับไปใช้ระบบสำรองได้ไหม? เรามีวิธีทำงานแบบ Manual หรือไม่?
3. วัดผลเทียบกับเกณฑ์ความทนทาน: เราสามารถกู้คืนบริการกลับมาได้ทันเวลา 4 ชั่วโมงตามค่า Impact Tolerance หรือเปล่า?
4. แก้ไข (Remediate): ถ้าเราสอบตกในการทดสอบนี้ เราต้องลงทุนในเทคโนโลยีที่ดีขึ้นหรือเพิ่มบุคลากรเพื่อปิดช่องโหว่นั้น
รู้หรือไม่? การทดสอบสถานการณ์ไม่ใช่แค่การตรวจสอบแบบ "ผ่าน/ไม่ผ่าน" เท่านั้น แต่มันมีไว้เพื่อค้นหา จุดอ่อนที่สุด ของคุณ เพื่อที่คุณจะได้ใช้เงินงบประมาณไปกับการแก้ไขให้ถูกจุดครับ
6. การสื่อสารและการกำกับดูแล
ความยืดหยุ่นในการดำเนินงานไม่ใช่เรื่องของฝ่ายไอทีเท่านั้น แต่ต้องเริ่มจากผู้บริหารระดับสูง คณะกรรมการบริษัท (Board of Directors) คือผู้รับผิดชอบสูงสุดในการอนุมัติรายชื่อ IBS และค่า Impact Tolerances ครับ
การสื่อสารภายใน vs ภายนอก:
เมื่อเกิดเหตุการณ์หยุดชะงัก คุณต้องมีแผนสำหรับ:
- ภายใน: แจ้งให้พนักงานทราบว่าต้องทำอย่างไร และจะช่วยเหลือลูกค้าอย่างไร
- ภายนอก: มีความจริงใจต่อลูกค้า หน่วยงานกำกับดูแล และสื่อมวลชน การสื่อสารที่ชัดเจนสามารถป้องกันการ "แห่ถอนเงิน (Bank run)" หรือการสูญเสียชื่อเสียงอย่างถาวรได้
ประเด็นสำคัญ: ความยืดหยุ่นคือ วัฒนธรรมทั่วทั้งองค์กร ถ้าคณะกรรมการไม่ให้ความสำคัญ องค์กรก็จะไม่มีความพร้อมเมื่อเหตุการณ์ที่ "รุนแรงแต่เป็นไปได้" เกิดขึ้นจริงครับ
สรุปทบทวนสั้นๆ
1. ระบุ (Identify): อะไรคือ บริการทางธุรกิจที่สำคัญ (IBS) ของเรา? (เน้นที่ลูกค้าเป็นหลัก)
2. กำหนด (Set): Impact Tolerance ของเราคือเท่าไหร่? ("จุดแตกหัก" ทั้งในเชิงเวลา/ปริมาณ)
3. เชื่อมโยง (Map): เราต้องใช้ ทรัพยากร (PPTD) อะไรบ้างเพื่อให้เกิดบริการเหล่านี้?
4. ทดสอบ (Test): ทำการทดสอบสถานการณ์ที่ รุนแรงแต่เป็นไปได้ เรายังอยู่ในเกณฑ์ที่กำหนดหรือไม่?
5. ลงทุน (Invest): ถ้าสอบตก ต้องแก้ไขจุดอ่อนนั้นให้เรียบร้อย
สู้ๆ นะครับ! ความยืดหยุ่นในการดำเนินงานคือเรื่องของการเตรียมตัวและการปกป้องระบบ เมื่อคุณเข้าใจว่ามันคือการ "บริหารจัดการในช่วงที่เกิดปัญหา" แทนที่จะเป็นการ "หลีกเลี่ยงไม่ให้เกิดปัญหา" บทนี้ก็จะกลายเป็นเรื่องที่เข้าใจได้ง่ายขึ้นมากเลยครับ!