การนำไอทีมาช่วยบริหารความเสี่ยง

การนำไอทีมาช่วยบริหารความเสี่ยง

ดร.สันติพัฒน์ อรุณธารี Chief Technology Officer (CTO)

บริษัท พีทีที ไอซีที โซลูชั่นส์ จ ากัด

บทคัดย่อ

            การบริหารความเสี่ยงเป็นองค์ประกอบสำคัญของหลักการบริหารองค์กรที่ดี ซึ่งช่วยจัดการความไม่แน่นอน
ลดความรุนแรงของผลกระทบที่อาจจะเกิดขึ้นกับธุรกิจได้ และยังช่วยให้องค์กรดำเนินธุรกิจได้อย่างต่อเนื่อง  หลักของการบริหารความเสี่ยงมีกรอบแนวคิดในการจัดการความเสี่ยงที่หลายองค์กรนำไปปรับใช้และเป็นที่รู้จักอย่างแพร่หลายมี 2 แนวคิดได้แก่ กรอบแนวคิด COSO และกรอบมาตรฐาน ISO 31000 กรอบแนวคิด COSO เป็นมุมมองภาพกว้างที่ระบุถึงมิติและองค์ประกอบที่เกี่ยวข้องกับการบริหารความเสี่ยงที่ผู้บริหาร ผู้ตรวจสอบและผู้ปฏิบัติงานตรวจสอบนำไปปรับใช้อย่างกว้างขวาง แต่ผู้ปฏิบัติงานสายงานอื่นๆ อาจทำความเข้าใจยากกว่ากรอบมาตรฐาน ISO 31000 เพราะ ISO 31000 ได้ปรับปรุงกรอบแนวคิดไปสู่วิธีการบริหารความเสี่ยงเพื่อจัดการความเสี่ยงทางธุรกิจได้อย่างเป็นขั้นตอนสามารถนำไปปรับใช้กับองค์กรทั้งขนาดเล็กและขนาดใหญ่ได้ ทุกสายวิชาชีพเข้าใจได้ง่าย ดังนั้นจึงถูกนำมาใช้ในหลากหลายวิชาชีพได้มากขึ้น  เมื่อธุรกิจขยายตัวการกำกับดูแลกิจการและการให้ทุกหน่วยงานจัดการต่อความเสี่ยงที่เกิดขึ้นเป็นเรื่องที่ยาก หลายองค์กรจึงนำซอฟแวร์บริหารความเสี่ยงมาใช้แทนการปฏิบัติงานแบบ Manual ดังนั้นองค์กรจึงต้องมีการออกแบบกระบวนการบริหารความเสี่ยงการออกแบบระบบที่มีความสอดคล้องกับการทำงานปฏิบัติงานให้เกิดประโยชน์สูงสุดกับองค์กร  ในบทความฉบับนี้ผู้เขียนได้นำกระบวนการบริหารความเสี่ยงมาตรฐาน ISO 31000 มาผนวกเข้ากับ Function การทำงานของระบบที่องค์กรจะพัฒนา  เพื่อกำหนดเป็นกรอบหรือวิธีการในบริหารความเสี่ยงทั่วทั้งองค์กร  โดยได้ยกตัวอย่างตั้งแต่ขั้นตอนการริเริ่มโครงการ ขั้นตอนการออกแบบระบบ ขั้นการพัฒนาระบบ ขั้นเตรียมการก่อนขึ้นระบบใหม่และการจัดอบรมตลอดจนนำระบบไปใช้ได้จริง

1.       แนวคิดการบริหารความเสี่ยง

การบริหารความเสี่ยง หมายถึง กรอบการทำงานที่ใช้บ่งชี้ วิเคราะห์ ประเมิน จัดการและติดตามผล ตลอดจนการสื่อความเกี่ยวกับกิจกรรมของการจัดการความเสี่ยง ที่เกิดขึ้นตั้งแต่ระดับโครงการ (Project) ภายในหน่วยงาน (Section and division) ฝ่ายงาน (Department) และระดับองค์กร (Corporate) เพื่อช่วยลดความเสียหายให้เหลือน้อยที่สุด และเพิ่มโอกาสให้แก่ธุรกิจมากที่สุด ทั้งนี้ลักษณะของการบริหารความเสี่ยงที่สำคัญได้แก่

การบริหารความเสี่ยงเป็นหน้าที่และความรับผิดชอบของคณะกรรมการบริหาร ผู้บริหาร และบุคลากรทุกคนจะต้องมีส่วนร่วมในการกำหนดกลยุทธ์และการดำเนินงาน เมื่อการบริหารความเสี่ยงเกิดจากความร่วมมือกันของคนในองค์กรจากหลากหลายหน่วยงาน เมื่อการบริหารความเสี่ยงเกิดจากความร่วมมือกันของคนในองค์กรจากหลากหลายหน่วยงานจึงจำเป็น ต้องมีกรอบในการดำเนินงานร่วมกันทั้งองค์กร ซึ่งปัจจุบันมีกรอบหรือมาตรฐานสากลที่ได้รับการยอมรับและนำมาใช้ 2 แนวคิดได้แก่ 2.1) กรอบในการบริหารความเสี่ยงตามแนวคิด COSO ERM 2.2)       กรอบในการบริหารความเสี่ยงตามมาตรฐาน ISO 31000

1.1.    กรอบในการบริหารความเสี่ยงตามแนวคิด COSO ERM

กระบวนการบริหารความเสี่ยงที่พัฒนาจาก COSO มาจากหลักการควบคุมภายในตามกรอบแนวคิดการบริหารความเสี่ยงทั่วทั้งองค์กร โดยคณะทำงานผู้เชี่ยวชาญทางด้านการบริหารความเสี่ยงที่รู้จักในนาม COSO (The Committee of Sponsoring Organization of Treachery Commission: COSO) ซึ่งหลักของ COSO-ERM มีส่วนประกอบสำคัญ 3 มิติ ได้แก่

1) Risk Objective คือการระบุถึงวัตถุประสงค์ของการดำเนินการที่กำหนดไว้และระบุว่าทำไมองค์กรหรือหน่วยงานต้องบริหารความเสี่ยง

2) Organization Level คือการระบุหน่วยงานที่มีหน้าที่รับผิดชอบในการบริหารความเสี่ยง

                      3) Interrelated components ซึ่งจะระบุไว้ถึงองค์ประกอบของการบริหารความเสี่ยง 8 หัวข้อเป็นสำคัญ ที่องค์กรสามารถนำไปปรับใช้ดังต่อไปนี้

2.2   กรอบในการบริหารความเสี่ยงตามมาตรฐาน ISO 31000

มาตรฐานการบริหารความเสี่ยง ISO 31000 ถูกพัฒนามาจากแนวทางการบริหารความเสี่ยงตามมาตรฐาน AS/NZS 4360 เป็นมาตรฐานการบริหารความเสี่ยงระดับสากล (International Organization of standard: ISO)  เรียกว่า Risk management guidelines on principles and implement of risk management จุดเด่นของมาตรฐาน ISO 31000 มุ่งเน้นการวางแนวปฏิบัติ ให้กับองค์กร โดยองค์กรธุรกิจทั้งขนาดเล็กและใหญ่สามารถนำกระบวนการประเมินความเสี่ยงตาม ISO 31000 ไปปรับใช้เป็นแนวปฏิบัติขององค์กรได้ตาม 5 ขั้นตอนและ 2กิจกรรมสำคัญที่ช่วยให้การบริหารความเสี่ยงมีการดำเนินการอย่างต่อเนื่อง มาตรฐาน ISO 31000:2009 กรอบในการบริหารความเสี่ยงตามมาตรฐาน ISO 31000 มีความสัมพันธ์กันดังนี้

ส่วนที่ 1    หลักการและแนวปฏิบัติ (Principles and Guideline) เป็นส่วนที่อธิบายถึงสภาพแวดล้อมและสิ่งที่ต้องคำนึงถึงตามรายละเอียดที่อธิบายตามภาพ Figure2 (1)  ซึ่งควรจะต้องทำก่อน แล้วจะนำไปสู่ model ของการออกแบบกรอบในการบริหารความเสี่ยงให้กับองค์กร

ส่วนที่ 2    กรอบแนวทางปฏิบัติ (Framework) คือรูปแบบที่กำหนดร่วมกันในการบริหารจัดการความเสี่ยงขององค์กร ซึ่งอาจกำหนดเป็นแผนงานตลอดทั้งปีในการกำกับและดูแลความเสี่ยง โดยรูปแบบดังกล่าวก็คือกรอบตาม Figure 2 ข้อ 2 ที่เชื่อมโยงไปถึงการพัฒนาเป็นกระบวนการและขั้นตอนในการปฏิบัติงานประเมินความเสี่ยงต่อไป

                  ส่วนที่ 3   กระบวนการ (Process) คือขั้นตอนในการบริหารความเสี่ยงกำหนดไว้ 5 ขั้นตอน 2 กิจกรรมต่อเนื่อง ตามภาพ figure2 (3) ซึ่งก่อนจะทำกระบวนการดังกล่าวได้องค์กรจะต้องกำหนดกรอบในการบริหารงานร่วมกันกับทีมงานและผู้บริหารขององค์กรในส่วนที่ 2 เสียก่อน

กระบวนการบริหารเสี่ยงตาม มาตรฐาน ISO 31000: 2009 ที่สำคัญประกอบด้วยขั้นตอนดังต่อไปนี้

1.       การกำหนดสภาพแวดล้อม/วัตถุประสงค์ (Establish the context)

2.       การระบุความเสี่ยง (Risk identification)

3.       การวิเคราะห์ความเสี่ยง (Risk Analysis)

4.       การประเมินความเสี่ยง (Risk Evaluation)

5.       การจัดการความเสี่ยง (Risk Treatment)

Additional activities

6.       การจัดประสานงานติดต่อสื่อสารและการให้คำปรึกษา (Communication and consultant)

การติดตามและตรวจสอบ (Monitoring and review)

หลักการบริหารความเสี่ยงที่องค์กรนำไปปรับใช้และได้รับการยอมรับคือ COSO ERM และ ISO 31000 ซึ่งกรอบการดำเนินงานทั้ง 2 วิธีมีแนวปฏิบัติที่สอดคล้องกันคือการมุ่งเน้นกระบวนการที่จะต้องมีการปรับปรุอย่างต่อเนื่อง ซึ่งจะทำให้ผู้มีส่วนได้เสียขององค์กรมั่นใจได้ว่าองค์กรมีการบริหารจัดการที่ดีและมีประสิทธิภาพจากกระบวนการควบคุมและติดตามผลที่ได้กำหนดไว้ แต่ผู้อ่านสามารถสังเกตจากภาพ Figure 1 และ 2 ดังกล่าวข้างต้นจะเห็นถึงความแตกต่างระหว่าง 2 แนวคิด สามารถสรุปได้ดังนี้

จากตารางเปรียบเทียบด้านบนจะเห็นได้ว่า COSO ERM เป็นองค์ประกอบที่ต้องมองภาพขนาดใหญ่เป็นมิติที่เชื่อมโยงกันทุกส่วนและควรมีการดำเนินงานด้านความเสี่ยงให้ครอบคลุมทุกด้านตามวัตถุประสงค์ที่กำหนด เช่น การประเมินความเสี่ยงด้านกลยุทธ์ ความเสี่ยงด้านปฏิบัติการ ความเสี่ยงตามระเบียบข้อบังคับ ซึ่ง COSO ERM มุ่งเน้นให้องค์กรทั้งขนาดเล็กและขนาดใหญ่ควรจะบริหารความเสี่ยงทุกด้าน  แต่บ ISO 31000 เป็นมาตรฐานที่องค์กรสามารถนำไปปรับใช้ได้ทั้งองค์กรขนาดเล็กและขนาดใหญ่ เพราะ ISO 31000 ไม่ได้มุ่งเน้นว่าจะต้องทำการประเมินความเสี่ยงในด้านใดบ้าง แต่ระบุว่าจะต้องมีการออกแบบ Risk Management Model ร่วมกันและทำการประเมินความเสี่ยงตามกระบวนการและขั้นตอนที่มีระบบระเบียบไว้อย่างชัดเจน จนทำให้องค์กรที่ปฏิบัติตามมาตรฐาน ISO 31000 สามารถปฏิบัติตามจนผ่านเกณฑ์การการประเมินตามมาตรฐานสากลได้ เป็นเครื่องประกันผลการปฏิบัติงานให้กับองค์กรได้เป็นอย่างดี ทำให้คู่ค้าและลูกค้ามั่นใจได้ว่าหากดำเนินธุรกิจกับองค์กรของเราโอกาสที่จะประสบความสำเร็จก็จะสูงตามไปด้วย   ดังนั้นปัจจุบันองค์กรธุรกิจหรือบริษัทผู้พัฒนาซอฟแวร์ด้านบริหารความเสี่ยงจึงเริ่มพัฒนากระบวนการบริหารความเสี่ยงและออกแบบระบบโดยอ้างอิงการประเมินความเสี่ยงตาม ISO 31000 มากยิ่งขึ้น

การเตรียมความพร้อมก่อนการพัฒนาระบบ

ปัจจุบันการบริหารความเสี่ยงขององค์กรส่วนมากยังใช้วิธีการ เช่น การใช้  2) Product eGRC version 5.2 และ 3)  IBM OpenPages GRC version 6.1 เป็นต้น Source: Gartner (October 2012) ระบบงานเหล่านี้มีจุดเด่นจุดด้อยแตกต่างกันไปขึ้นอยู่กับวัตถุประสงค์ของการนำไปใช้  ซึ่งต้องผ่านกระบวนการคัดเลือกผลิตภัณฑ์ขององค์นั้นๆ จะเป็นอย่างไร ทั้งนี้ต้องพิจารณาความเป็นไปได้และประโยชน์ที่จะได้รับสูงสุดตามวัตถุประสงค์ของการนำไปใช้จริงๆ  และสิ่งคาดหวังว่าจะได้รับ ซึ่งต้องมั่นใจได้ว่าเหมาะกับองค์กรเราจริงๆ จึงจะตัดสินใจนำระบบดังกล่าวมาออกแบบใช้นำกระบวนการบริหารความเสี่ยงของเรา

 1.       ข้อความพิจารณาในการออกแบบระบบให้สอดคล้องกับกระบวนการบริหารความเสี่ยง

องค์กรที่นำระบบมาใช้ จำเป็นต้องดำเนินงานดำเนินแผนงาน ร่วมกับระบบที่กำลังพัฒนานา ต้องออกแบบให้รองรับกระบวนการทำงานอยู่ในปัจจุบัน โดยระบบระบบและกระบวนการเดิมต้องถูก

1.1.     พิจารณาระดับการจัดการภายในองค์กรเพื่อวางกรอบบริหารความเสี่ยง

ตัวอย่างการออกแบบโครงสร้างการบริหารความเสี่ยงที่จะต้องถูกออกแบบไว้ในระบบงาน

จากภาพแสดงระดับภายในองค์กรเพื่อใช้กำหนดรูปแบบการบริหารความเสี่ยง จะช่วยให้การออกรายงานสามารถรวบรวมชุดของระดับความสำคัญของ แบ่งแยกตาม 

          จากภาพการออกแบบโครงสร้าง Organization structure ของการทำ Risk management ขององค์กรธุรกิจ จะเห็นได้ว่ามีการออกแบบตั้งแต่การจัดทำกระบวนการบริหารความเสี่ยงตั้งแต่ระดับโครงการ (Project) ที่สามารถพิจารณาถึงความเสี่ยงของแต่ละโครงการได้ สามารถ consolidate ขึ้นไปในระดับ Business Unit ได้ ซึ่งทั้งสองระดับรวมเรียกว่า Operational risk ตลอดจนระบบสามารถ consolidate ขึ้นไปจนถึง Corporate risk  โดยออกรายงานที่เรียกว่า Corporate risk profile จากตัวอย่างที่ได้กล่าวมาเป็นเพียงการยกตัวอย่างโครงสร้างความเสี่ยงขององค์กรที่ใดที่หนึ่งเท่านั้น ขึ้นอยู่กับองค์กรของท่านว่าจะมองความเสี่ยงและจำลำดับความเสี่ยงขึ้นไปกี่ระดับและจะมีมุมมองของรายงานอย่างไร (ก็จะถูกกำหนดตามโครงสร้างนั้นๆ) 

1.1.     พิจารณาผลกระทบของความเสี่ยงว่าจะกระทบในระดับ Corporate ระดับ Business strategic หรือระดับ Project นั่นหมายความว่าจะส่งผลต่อมุมมองของรายงานที่จะถูกใช้ในแต่ละระดับด้วย

1.2.     การออกแบบระบบจะต้องสามารถ Group  Impact หรือ driver ได้และยังต้องแจกแจงรายละเอียดที่แท้จริงของ impact / driver ได้มากกว่า 1 สาเหตุที่ต้องละเอียดเพราะเมื่อความเสี่ยงเกิดขึ้น driver or impact จะต้องสะท้อนให้ผู้รับผิดชอบรับทราบได้อย่างตรงประเด็น

1.3.     พิจารณาความหมายและนิยามที่ต้องเข้าใจในทิศทางเดียวกันทั้งธุรกิจและผู้พัฒนาระบบ

1.4.     พิจารณาเกี่ยวกับระบบจะต้องเป็นมาตรฐานสากล Project จะต้องมีทั้ง Technical Consultant และ Business consultant ที่มีความเชี่ยวชาญใน Risk Management เพื่อกำหนด to be Process for Risk Management (จะต้องถูกระบุอยู่ใน business blueprint) ที่เชื่อมโยงกับระบบได้

1.5.     ซอฟแวร์ในการบริหารความเสี่ยงจะต้องถูกออกแบบให้รองรับกระบวนการวัดและประเมินผลกระบวนการด้านความเสี่ยงขององค์กรด้วย ในขั้นตอนของการ Identify risk หากองค์กรที่ให้ความสำคัญของการติดตามผลระบบที่นำมาใช้จะต้องนำแนวคิด Key Risk Indicators – KRIs มาปรับใช้ โดยซอฟแวร์จะต้องมีกระบวนการทำงานดังนี้

§  สามารถกำหนดหน้าที่ของสปอนเซอร์หรือผู้สนับสนุนการพัฒนา Key Risk Indicators – KRIs ที่จะต้องถูกกำหนดมาจากฝ่ายบริหารได้

§  สร้างกลไกการสื่อสาร การซักซ้อมความเข้าใจ การมอบหมายกระจายหน้าที่ความรับผิดชอบในการจัดทำข้อมูลสถานะความเสี่ยงตาม Key Risk Indicators – KRIs ที่กำหนดไว้โดยเฉพาะจุดที่กำหนดเป็น Risk Appetite ด้วยตัวระบบได้

§  วางรูปแบบการรายงานทั้งในกรณีของสถานการณ์ปกติ และสถานการณ์ที่พบการเคลื่อนที่ของความเสี่ยงที่สอดคล้องและเป็นไปในทิศทางเดียวกันทั้งองค์กร

§  นำข้อมูลที่ถูกจัดเก็บในระบบมาพัฒนาและปรับปรุงประสิทธิผลของ Key Risk Indicators  KRIs ในการพยากรณ์สถานะความเสี่ยงที่อาจจะเกิดขึ้นไม่ว่าจะระดับไหนขององค์กรได้

§  เปรียบเทียบสถานะความเสี่ยงที่เป็นเกณฑ์ภายในกับเกณฑ์ภายนอกกิจการ เพื่อเป็นแนวทางในการพัฒนาปละปรับปรุง Key Risk Indicators – KRIs ต่อไป

1.6.     กระบวนการทำงานของ Risk Management Process จะต้องถูกกำหนดขึ้นมาใหม่เพราะการทำงานจะต้องถูกแบ่งแยกระหว่าง manual และ Automate โดยจะต้องถูกระบุไว้ใน phase การจัดทำ Business blueprint หรือข้อตกลงการ design ระบบ

1.7.     การกำหนด User ในระบบ เช่น Risk owner , Risk response เป็นต้น ซึ่งชื่อ Role เหล่านี้อาจไม่ตรงกับทีมงานที่ปฏิบัติงานในปัจจุบันก็ได้ จึงต้องมีการปรับจูนและถ่ายทอดให้เข้าใจ

1.8.     การใช้ระบบ Risk Management จำเป็นต้องมีผู้รับผิดชอบ 1 คนเป็น system admin ของระบบ Risk management ขึ้นมาใหม่ เนื่องจากการบริหารความเสี่ยงต้องมีการปรับปรุงกระบวนการอย่างต่อเนื่องรวมถึง framework ทีนำมาใช้งานด้วย ดังนั้นการปรับแก้ไขระบบจึงต้องใช้ผู้มีความรู้ด้าน RM ถึงจะสามารถออกแบบโครงสร้างองค์กรของ RM ได้ถูกต้อง

1.9.     การจัด Train the Trainer อย่างจริงจังเพื่อสอน Risk Management team ให้เข้าใจระบบและถ่ายทอดให้ Risk owner หรือ Risk coordinator ของแต่ละหน่วยงานได้

สรุป

เนื่องด้วยซอฟแวร์ที่ช่วยบริหารความเสี่ยงมีค่าใช้จ่ายในการพัฒนาที่ค่อนข้างสูง เพราะเกี่ยวเนื่องกับทุกหน่วยงานขององค์กร โดยเฉพาะการพัฒนาระบบที่ต้องการวางรากฐานขององค์กรด้วยระบบงาน  GRC  ดังนั้นการตัดสินใจนำระบบงานดังกล่าวมาใช้ต้องเตรียมความพร้อมให้กับองค์กรและเตรียมทีมงานที่เกี่ยวข้องเพื่อช่วยกันออกแบบกระบวนการและประยุกต์ใช้ซอฟแวร์  โดยกำหนดวัตถุประสงค์ของการนำมาใช้ให้ชัดเจนตั้งแต่ริเริ่มโครงการ ซึ่งวัตถุประสงค์ในการดำเนินโครงการดังกล่าวจะต้องคำนึงองค์ประกอบของระบบงานที่ช่วยสนับสนุนกระบวนการบริหารความเสี่ยงดังต่อไปนี้

1.       ระบบจะต้องช่วยจัดเก็บข้อมูลที่เกี่ยวข้องกับความเสี่ยง ตั้งแต่กำหนดความเสี่ยง ผู้รับผิดชอบ วัตถุประสงค์ของหน่วยงานหรือขอบเขตของความเสี่ยงที่เกี่ยวข้อง ตัวอย่างเช่น การกำหนด Project objective , Risk event ความสัมพันธ์ของความเสี่ยงว่ามีปัจจัยขับเคลื่อนอะไร (driver) และผลกระทบคาดว่าจะเกิดขึ้นอย่างไร

2.       ระบบจะต้องช่วยนำข้อมูลจากข้อ 1 มาวิเคราะห์และคาดคะเนว่าความเสี่ยงที่จะเกิดขึ้นอยู่ในระดับใด เมื่อเกิดขึ้นแล้วค่าของผลกระทบที่จะเกิดขึ้นจะส่งผลเป็นตัวเงินหรือแสดงให้เห็นความสัมพันธ์ของผลกระทบว่าจะก่อให้เกิดผลเสียหายกับธุรกิจด้านใดบ้างตามวัตถุประสงค์ของธุรกิจได้

3.       ระบบจะช่วยแสดงเตือนเมื่อเกิดผลกระทบจากปัจจัยเสี่ยงต่างๆ ได้  ระบบต้องช่วยเตือนเมื่อถึงระยะเวลาตามแผนงานที่กำหนดไว้ว่าจะต้องมีการรายงานผลและจัดทำการประเมินความเสี่ยง

4.       ระบบจะต้องช่วย consolidate Risk จากทุกหน่วยงานขององค์กร เพื่อช่วยในการจัดทำ Risk Profile และช่วยให้ผู้บริหารเห็นภาพรวมของความเสี่ยงทั้งองค์กรได้อย่างแท้จริง

5.       ระบบจะต้องช่วยวางรูปแบบการรายงานทั้งในกรณีของสถานการณ์ปกติ และสถานการณ์ที่พบการเคลื่อนที่ของความเสี่ยงที่สอดคล้องและเป็นไปในทิศทางเดียวกันทั้งองค์กร

6.       ระบบจะต้องสามารถปรับใช้ในเรื่อง Key Risk Indicators (KRIs) ขององค์กรได้ ซึ่งแนวคิดที่สำคัญในการกำหนด KRIs องค์กรจะต้องมีการกำหนดหน้าที่ของผู้รับผิดชอบที่จะต้องถูกกำหนดมาตั้งแต่ผู้บริหารระดับสูง แล้วมอบหมายกระจายหน้าที่ความรับผิดชอบมายังผู้ปฏิบัติงานในระดับล่างได้ ดังนั้นซอฟแวร์และกระบวนการจะต้องสอดคล้องกัน เพื่อจัดทำฐานข้อมูลที่มาใช้อ้างอิงหรือเทียบเคียงให้สามารถกำหนดเป็น scenario ทำการประเมินว่าสถานการณ์ที่อาจจะเกิดขึ้นน่าจะมีรายละเอียดของความเสียหายอย่างไรบ้าง และสถานการณ์ที่ถือว่าเลวร้ายที่สุด หรือ Worst case นั้นมีรายละเอียดของความเสียหายอย่างไร เพื่อใช้ในการพิจารณากำหนด Key Risk Indicators – KRIs และ Trigger point ให้กับระบบได้  

ส่วนอ้างอิง

-          การบริหารความเสี่ยงตามมาตรฐาน ISO 31000: 2009, http://www.juliantalbot.com/Downloads.htm,

-          การบริหารความเสี่ยงตาม COSO ERM https://www.coso.org

-          Risk IT’s Domain model source: ISACA’s Risk IT framework ที่มา: (The Risk iT FRamewoRk excerpt)  http://www.isaca.org/knowledge-center/research/documents/RiskIT-FW, page 15, 2552

กรอบการบริหารความเสี่ยงตาม ISO และ COSO ERM อาจารย์ จิรพร  สุเมธีประสิทธิ์http://chirapon.wordpress.com

การพัฒนากลยุทธ์ทางธุรกิจไปสู่กลยุทธ์ทางด้านไอทีด้วยโคบิต 5

การพัฒนากลยุทธ์ทางธุรกิจไปสู่กลยุทธ์ทางด้านไอทีด้วยโคบิต 5

ดร.สันติพัฒน์ อรุณธารี Chief Technology Officer (CTO)

บริษัท พีทีที ไอซีที โซลูชั่นส์ จำกัด

บทคัดย่อ

การดำเนินธุรกิจเชิงบูรณาการเพื่อให้เติบโตอย่างยั่งยืนและสร้างความพึงพอใจให้กับผู้มีส่วนได้เสียอย่างสมดุล ผู้บริหารจะต้องเริ่มตั้งแต่การนำวิสัยทัศน์ พันธกิจตลอดจนหลักการบริหารจัดการด้านธรรมาภิบาลที่ดีมาใช้เป็นกรอบในการดำเนินงานทางธุรกิจ  แต่ปัจจุบันนอกจากการดำเนินธุรกิจอย่างบูรณาการอาจไม่เพียงพอ  เพราะระบบไอทีกลายเป็นส่วนประกอบสำคัญของการดำเนินธุรกิจที่จะช่วยสร้างความได้เปรียบทางการแข่งขันให้กับองค์กร  ดังนั้นนอกเหนือจากหลักการพัฒนากลยุทธ์ทางธุรกิจที่ดีแล้ว  องค์กรยังจำเป็นที่ต้องมีเครื่องมือที่จะช่วยให้ผู้บริหารระดับ C-Level ขององค์กรสามารถข้าใจและนำไปบริหารจัดการไอทีขององค์กรให้กับองค์กรได้อย่างบูรณาการและสัมพันธ์กันอย่างหลีกเลี่ยงไม่ได้  ซึ่งปัจจุบันมาตรฐานหรือกรอบในการปฏิบัติงานที่มุ่งเน้นบริหารงานงานสารสนเทศขององค์กรมีหลายประเภท เช่น กรอบแนวคิด COSO ที่ช่วยบริหารจัดการความเสี่ยงด้านไอที  แนวทางการบริหารงานด้าน IT Service ตามกรอบ  ITIL  หรือ มาตรฐานสากลด้านความปลอดภัยของข้อมูล ISO 27001 เป็นต้น  จากมาตรฐานหรือแนวปฏิบัติที่ได้กล่าวมาแล้ว ผู้บริหารระดับสูงขององค์กรสามารถเลือกใช้รูปแบบที่เหมาะสมสำหรับองค์กรธุรกิจนั้นๆ ได้ แต่องค์กรจะมั่นใจได้อย่างไรว่าการเลือกใช้มาตรฐานหรือหลักในการบริหารงานนั้นๆ จะสามารถบริหารจัดการระบบไอทีและกระบวนการทางด้านไอทีขององค์กรได้สอดคล้องกับเป้าหมายทางด้านธุรกิจ 

ดังนั้นในบทความฉบับนี้จึงได้กล่าวกรอบวิธีปฏิบัติที่สามารถนำไปวางแผนงานทางด้านไอทีให้สอดคล้องกับแผนกลยุทธ์ขององค์กร ได้อย่างเป็นรูปธรรม พร้อมทั้งยกตัวอย่างและแนวทางการวัดผลการปฏิบัติงานไว้อีกด้วย  กรอบวิธีปฏิบัติที่ดีนี้คือกรอบโคบิต 5 โดยปัจจุบันโคบิตได้ถูกปรับปรุงให้ทันสมัยสามารถนำไปปรับใช้ในทุกส่วนงานขององค์กรที่เกี่ยวข้องกับกระบวนการทางด้านไอ ซึ่งไม่เพียงแต่ผู้ตรวจสอบงานสารสนเทศเท่านั้นที่จะนำไปประยุกต์ใช้ได้  กรอบวิธีปฏิบัติโคบิต 5 ยังมีวัตถุประสงค์หลักในการประมวลกรอบและหลักการทางด้านไอที ที่มีอยู่มากมายให้เป็นคู่มือแบบสำเร็จรูปให้ผู้บริหารขององค์กรนำไปใช้บริหารงานทางด้านไอทีได้อย่างเข้าใจและยังเห็นภาพที่เชื่อมโยงระหว่างทิศทางของธุรกิจกับ Road map ของแผนกลยุทธ์ทางด้านไอทีอีกด้วย

กรอบวิธีปฏิบัติ COBIT 5

โลกแห่งการแข่งขันทำให้องค์กรหลายแห่งต้องขับเคลื่อนธุรกิจด้วยการนำระบบไอทีมาเป็นเครื่องมือสร้างความได้เปรียบทางการแข่งขัน และเรามักพบเห็นองค์กรส่วนใหญ่กำหนดงบประมาณทางด้านไอทีไว้มากกว่างบประมาณด้านอื่นๆ อาจเพราะทรัพยากรทางด้านไอที อันได้แก่ Hardware Software หรือแม้แต่ Peopleware ถือเป็นต้นทุนที่มีมูลค่ามหาศาลมากกว่าต้นทุนอื่นๆ ในองค์กร นอกจากนี้การพัฒนาระบบไอทีตามแผนการลงทุนที่ได้กำหนดไว้ ก็ไม่ได้ช่วยสร้างคุณค่าให้กับธุรกิจหรือผู้มีส่วนได้เสียขององค์กรเลย    ดังนั้นองค์กรธุรกิจจำเป็นต้องมีเครื่องมือที่ช่วยให้ปฏิบัติงานได้อย่างมีประสิทธิภาพ  โดยหลักในการบริหารจัดการไอทีที่ได้รับการยอมรับเพราะสร้างคุณค่าให้กับธุรกิจ คือ “กรอบปฏิบัติ COBIT”  ซึ่งเป็นเครื่องมือที่ช่วยในการตรวจสอบของผู้ตรวจสอบภายในให้สามารถทำงานได้อย่างมีประสิทธิภาพ ทั้งยังประกอบไปด้วยกลไกที่ช่วยในการพัฒนากลยุทธ์ทางด้านไอทีให้กับองค์กรธุรกิจในปัจจุบันได้เป็นอย่างดี  ทำให้มั่นใจได้ว่าการวางแผนกลยุทธ์ทางด้านไอทีขององค์กรตามกรอบปฏิบัติของ COBIT 5 จะสามารถตอบสนองความต้องการของธุรกิจด้วยภาพที่สามารถเชื่อมโยงไอทีและธุรกิจเข้าหากันได้อย่างลงตัว

สมาคมผู้ตรวจสอบและควบคุมระบบสารสนเทศ (ISACA International) หรือเรียกกันทั่วไปว่า “ISACA” ได้พัฒนากรอบวิธีปฏิบัติ COBIT (COBIT Framework) มาตั้งแต่ปี 1996 จากเวอร์ชั่น 1- 2- 3 - 4/4.1 และในปัจจุบัน COBITได้พัฒนาให้อยู่ในเวอร์ชั่น 5 ซึ่งได้เริ่มประกาศให้ใช้อย่างเป็นทางการในปี 2012 นี้ โดยมีความแตกต่างจาก COBIT 4 และ 4.1 อย่างมาก  เพราะ ISACA ต้องการปรับปรุงกรอบวิธีปฏิบัติดังกล่าวให้เป็นเครื่องมือที่ครอบคลุมหลักการบริหารงานทั้งทางด้านธุรกิจและไอที  ทั้งนี้วิธีการจัดการและดำเนินงานของ COBIT 5 จะช่วยเปลี่ยนกลยุทธ์ทางธุรกิจไปสู่กลยุทธทางด้านไอที รวมถึงเปลี่ยนกลยุทธ์เหล่านั้นไปสู่วิธีปฏิบัติที่แท้จริงได้ ตามวัตถุประสงค์ทางธุรกิจที่ได้กำหนดไว้

การแปลงกลยุทธ์ทางธุรกิจไปสู่แผนกลยุทธ์ด้านไอที

ดังนั้นการที่จะนำ COBIT 5 มาช่วยพัฒนากลยุทธ์ทางด้านธุรกิจไปสู่กลยุทธ์และกระบวนทางปฏิบัติทางด้านไอทีอย่างสอดคล้องกัน จะต้องทำความเข้าใจในเรื่องดังต่อไปนี้

1.       การแปลง Stakeholder Need ให้กลายไปเป็น Enterprise Goal

2.       ความแตกต่างระหว่างหน้าที่ของการกำกับดูแล (Governance) และหน้าที่ของการจัดการ (Management)  

3.       ศึกษาวิธีการแปลงกลยุทธ์ไปสู่วิธีปฏิบัติ 

1.    การแปลง Stakeholder Need ให้กลายไปเป็น Enterprise Goal ตามกฎ 1B 2R

คือการแปลงความต้องการของผู้มีส่วนได้เสียให้กลายเป็น Enterprise Goal หรือที่รู้จักกันว่า Business Goal  แล้วจึงกำหนดเป็น IT Goal และกลายเป็นกระบวนการปฏิบัติทางด้านไอที  ซึ่งสามารถอธิบายกระบวนการแปลง Stakeholder need ได้ตาม Frame work ของภาพของฝั่ง A

ตามภาพที่ 1 กรอบในการแปลง stakeholder need ข้างต้นแสดงให้เห็นว่าผู้มีส่วนได้เสียจะต้องพิจารณาจาก กฎ  “1B + 2R” มีรายละเอียดดังต่อไปนี้

1 B มาจากคำว่า                                                           - Benefit Realization

และ 2R มาจากคำว่า                                                    - Risk Optimization

        และ                                                                         - Resource Optimization                จากกฎ 1B 2R สามารถอธิบายขั้นตอนการกำหนด stakeholder need ว่ามีมุมมองที่เกี่ยวข้องที่ตามวัตถุประสงค์ 3 ด้าน ได้แก่

o   การบรรลุผลประโยชน์ที่องค์กรกำหนดไว้ (Benefit Realization)

o   การบริหารจัดการความเสี่ยงอย่างเหมาะสม (Risk Optimization)

o   การบริหารจัดการทรัพยากรได้อย่างเหมาะสม (Resource Optimization) 

2.     ความแตกต่างระหว่างหน้าที่ของการกำกับดูแล (Governance) และหน้าที่ของการจัดการ (Management)

COBIT 5 ได้ให้นิยามชัดเจนว่าอะไรคืองานของ Governance และอะไรคืองานของ Management และทำการแบ่งแยกหน้าที่ของงานออกจากกันอย่างชัดเจน เพื่อสามารถเข้าใจได้ง่ายขึ้นกว่าเวอร์ชั่นเดิม ทั้งนี้ได้แบ่งงานเป็น 2 ด้านหลักๆ ดังนี้

2.1    Governance ของ COBIT 5 คือ  EDM ประกอบไปด้วย

                                                               i.      การประเมิน (Evaluate)

                                                              ii.      การกำกับ (Direct)

                                                            iii.      การตรวจสอบ (Monitor)

2.1    อง Management ของ COBIT ที่เคยแบ่งเป็น 4 domains ใน COBIT 5 ได้ถูกแปลงมาเป็น 4 หัวข้อหลักซึ่งใกล้เคียงกับตัวเดิม เพื่อบอกว่ากระบวนการอะไรบ้างในไอทีที่องค์กรจะต้องทำในระดับของ Management

Domain Align, Plan and Organize (APO)

Built, Acquire & Implement Built (BAI)

Run หรือ Deliver, Service & support (DSS)

Monitor, Evaluate & Assess (MEA)

หนึ่งในความแตกต่างที่มีความใกล้เคียง COBIT 4 คือการขยายความจาก 4 Domains หลักไปสู่ การทำ APO ไปจนถึง MEA ซึ่งเป็นการขยายความรูปวงกลม แปลงเปลี่ยนไปยังภาพด้านขวามือ

ตามภาพที่ 2 พัฒนาการของ COBIT 4 ไป COBIT 5 มีความแตกต่างในเรื่องการแบ่งแยกงานของ “การกำกับดูแล” และ “การบริหารจัดการ” เพื่อให้ผู้นำไปใช้สามารถชี้เฉพาะถึง เรื่องที่เกี่ยวข้องและแบ่งขอบเขตกระบวนการทางด้านไอทีได้อย่างถูกต้อง นำไปใช้และเข้าใจได้ง่ายอีกด้วย

1.       ศึกษาวิธีการแปลงกลยุทธ์ไปสู่วิธีปฏิบัติ 

การแปลงกลยุทธ์ไปสู่วิธีปฏิบัติตามกรอบ COBIT 5 มีขั้นตอนการดำเนินงานระบุไว้ในคู่มือของ COBIT ชื่อว่า “COBIT 5 Framework” A business framework for the Governance and management of enterprise IT                                        

(http://www.isaca.org/COBIT/Pages/Product-Family.aspx) ซึ่งกรอบในการ implement ประกอบด้วยขั้นตอนดังต่อไปนี้

3.1 แปลง Stakeholder need ไปสู่ Enterprise goal

3.2 กำหนด Enterprise goal ตาม 4 มุมมอง (Perspective) ของ Balanced Scorecard (BSC)

3.3 แปลง Enterprise goal ไปสู่ IT Related goal

3.4 แปลง IT Related goal ไปสู่ IT Process

ขั้นตอนที่ 3.1 แปลงความต้องการของผู้มีส่วนได้เสีย (Stakeholder need) ไปสู่เป้าหมายของทั้งองค์กร (Enterprise goal) 

พิจารณาตั้งแต่ Stakeholder need คือใครบ้าง มีความคาดหวังอะไรบ้างกับองค์กร เพื่อใช้เป็นหลักในการกำกับดูแลองค์กร Governance ที่ควรจะมองให้ครอบคลุมทุกกลุ่มของ Stakeholder เช่น ผู้ถือหุ้น ผู้บริหาร พนักงานขององค์กรทุกระดับ ลูกค้า คู่ค้า ประชาชน และสังคม เป็นต้น  COBIT 5 ได้จัดเตรียมประเด็นคำถามไว้เป็นแนวทางในการ Implement ไว้ในคู่มือ COBIT 5 Framework หน้าที่ 55-56  figure 24 หัวข้อ “Mapping COBIT 5 Enterprise Goals to Governance and management questions” มีทั้งหมด 22 คำถาม ซึ่งหนึ่งในคำถามที่ COBIT แนะนำไว้คือ “How do I get value from the use of IT?” และ “Are end users satisfied with the quality of the IT service?” ซึ่งจากคำถามดังกล่าวมี Enterprise Goal ที่จะสามารถตอบคำถามดังกล่าวได้ 7 ข้อดังต่อไปนี้

Enteprise goal                                     ข้อ 1  Stakholder value of business investments

ข้อ 2  Porfolio of competitive products

                                                                ข้อ 6  Customer-orinted service culture

                                                                ข้อ 7  Business service continuty and avaliaablity

ข้อ 13 Managed business change programes

ข้อ 16 Skilled and motivated people

ข้อ 17 Product and busienss innovation culture

                  การนำ Enterprise goal มาใช้ ท่านสามารถเลือกได้ว่าจะใช้ Enterprise goal ข้อใดก็ได้ ไม่จำเป็นต้องนำไปใช้ทั้งหมด แต่ควรเลือกใช้ให้เหมาะกับองค์กรของท่าน 

นำ Enterprise goal ที่เลือกตามข้อ 3.1 มา Mapping ว่าตรงกับวัตถุประสงค์ใดของ Balanced Scorecard 4 ด้านในมุมมองไหนบ้าง ซึ่งขึ้นอยู่กับว่าองค์กรจะให้ความสำคัญกับเรื่องใดเป็นหลัก ทั้งนี้ต้องระบุเป้าหมายทางด้านไอที (Enterprise Goal or Business Goal) ตาม Balanced Scorecard (BSC) 4 มุมมอง ดังตัวอย่างในหน้า 19 Figure 5  COBIT Enterprise Goals ตารางที่ 1 ซึ่งครอบคลุมวัตถุประสงค์ของการกำกับดูแลภายใต้ 3 องค์ประกอบดังนี้

จากตารางที่ 1 ด้านบน จะเห็นได้ว่ากรอบวิธีปฏิบัติ COBIT ประกอบไปด้วยวิธีการ Mapping Enterprise goal ไว้กับ BSC ได้อย่างสมบูรณ์ ซึ่งจะทำให้สามารถนำมาใช้ในองค์กรได้ง่ายและเข้าใจภาพได้ดียิ่งขึ้น ตลอดจนเห็นภาพความเชื่อมโยงว่าครอบคลุม Governance ในเรื่องใดบ้าง และจัดลำดับความสำคัญไว้อย่างครบถ้วน P คือ Primary หมายถึง การให้ความสำคัญเป็นอันดับแรกๆ ส่วน S คือ Secondary หมายถึง การให้ความสำคัญในเรื่องดังกล่าวเป็นอันดับถัดไป

ขั้นตอนที่ 3.3

กำหนดเป้าหมายทางด้านไอทีที่วางไว้ (IT-related goals) โดยสนับสนุน Enterprise goal ข้อที่ 1 เรื่อง Stakeholder value of business investments ซึ่งอยู่ในหน้า 50 Figure 22 จากคู่มือ COBIT 5 Framework ประกอบไปด้วยตัวอย่างการ Mapping  ดังต่อไปนี้

                ข้อ 1 Stakeholder value of business investments ประกอบด้วย IT related goal ที่ฝ่าย IT จะต้องดำเนินการให้บรรลุเป้าหมาย โดยกระบวนการด้านไอทีที่ต้องดำเนินการเป็นอันดับแรกๆ จะถูกกำหนดด้วยสัญลักษณ์ “P” และกระบวนการที่จะต้องดำเนินการลำดับถัดไปจะถูกกำหนดด้วย “S” ซึ่งสามารถ Mapping ได้ดังต่อไปนี้

ขั้นตอนที่ 3.4  แปลง IT Related goal ไปสู่ IT Process

หลังจากนั้นเป็นกระบวนการทางด้านไอที ตามคู่มือหน้า 52-53 เรื่อง COBIT 5 Framework ซึ่งแบ่งออกเป็น 2 ส่วนงานหลัก ได้แก่ งานทางด้าน Governance และ งานทางด้าน Management  ทั้งนี้การกำหนดกระบวนการที่เกี่ยวข้องจะปรากฎในหน้า 52 – 53 figure 23 สรุปเป็นตัวอย่างได้ว่าการกำหนด Enterprise goal หัวข้อเรื่อง IT relagted, Alignment of IT and Business strategy  โดยขอบเขตของ Governance ที่สำคัญคือ Framework setting and maintenance และเรื่อง Benefits delivery ซึ่งต้องตามด้วยกระบวนการที่สำคัญอะไรบ้าง และขอบเขตกระบวนการย่อยที่เกี่ยวข้องประกอบด้วยอะไรบ้าง ดังนี้ 

ตัวอย่างการแปลงกลยุทธ์ไปสู่วิธีปฏิบัติตามกรอบในการนำ COBIT 5

ภาพที่ 4 แสดงการแปลงกลยุทธ์ไปสู่วิธีปฏิบัติตามกรอบในการนำ COBIT 5

           วิธีการแปลงกลยุทธ์ทางธุรกิจไปสู่กลยุทธ์และกระบวนการไอทีที่เกี่ยวข้องตาม COBIT 5 ดังกล่าวข้างต้น เป็นเพียงตัวอย่างของการนำ COBIT ไปปรับใช้สำหรับองค์กรของท่าน ที่จะช่วยสร้างคุณค่าให้กับผู้มีส่วนได้เสียขององค์กร อันได้แก่  ผู้ถือหุ้น พนักงานขององค์กร ผู้บริหารขององค์กร หน่วยงานกำกับดูแล ลูกค้า คู่ค้าและประชาชน ก่อให้เกิดประโยชน์ครอบคลุมทั้งผู้ส่วนได้เสียทั้งภายในและภายนอกอย่างเหมาะสม

              จากตัวอย่างการแปลงกลยุทธ์ไปสู่วิธีปฏิบัติ  ทุกท่านจะสามารถเข้าใจได้ง่ายขึ้นไม่ว่าท่านจะเป็นผู้ตรวจสอบภายใน หรือแม้แต่ผู้ปฏิบัติงานด้านไอที ก็สามารถนำ COBIT 5 ไปประยุกต์ใช้ให้เหมาะสมกับองค์กรได้เช่นเดียวกัน นอกจากนี้ท่านยังสามารถนำวิธีการพัฒนากลยุทธ์ไปสู่การปฏิบัติจริงตามที่ได้สรุปมาแล้วไปปรับใช้ได้ โดยดาวน์โหลดคู่มือการใช้งาน COBIT 5 Framework A Business Framework for the governance and management of Enterprise IT ได้ที่
http://www.isaca.org/COBIT/Pages/Product-Family.aspx

ที่มา COBIT 5 Framework ; http://isaca.org