Archive for สิงหาคม, 2010

การทดสอบข้อมูลโดยวิธี Test Data (ต่อ)

ครั้งที่แล้วผมได้เล่าสู่กันฟัง ถึงเรื่องของการทดสอบข้อมูลและกระบวนการทำงานในระบบคอมพิวเตอร์ โดยวิธี Test Data (TDM) ว่า เหตุใดหรือมีความจำเป็นใดที่ต้องใช้วิธี Test Data ในการตรวจสอบ และวิธีการดังกล่าวจะนำมาใช้ในกระบวนการตรวจสอบได้อย่างไร ซึ่งวันนี้ผมจะมาเล่าในรายละเอียดของ TDM ต่อ แต่เนื่องจากรายละเอียดนั้นค่อนข้างเยอะ ผมจึงขอนำเสนอเป็นตอน ๆ พร้อมยกตัวอย่างประกอบ เพื่อให้เข้าใจได้ง่ายยิ่งขึ้นครับ

Test Data คือ อะไร

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

Test Data Method

การสร้างข้อมูลตัวอย่างทดสอบ (Audit Test Data)
การใช้ตัวอย่างข้อมูลเพื่อประเมินคุณภาพของโปรแกรม เป็นเทคนิคเบื้องต้นในการเก็บรวบรวมหลักฐานอย่างหนึ่ง โดยตั้งอยู่บนพื้นฐานที่ว่า ผู้ตรวจสอบจะให้ความเชื่อถือต่อโปรแกรมที่ใช้งาน หากผลการทดสอบเป็นที่น่าพอใจ

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

ขั้นตอนการจัดทำ Test Data และตัวอย่าง

1. ขั้นตอนการจัดทำ Test Data

1.1. กำหนดวัตถุประสงค์หรือเป้าหมายของากรทดสอบในแต่ละเรื่องของกิจกรรม ที่พิจารณาว่าอาจก่อให้เกิดความเสี่ยง
1.2. กำหนดจำนวนรอบเวลาบัญชีหรือข้อมูล (Cycle) ที่จะใช้ในการทดสอบ ให้สอดคล้องกับเป้าหมายของการทดสอบที่กำหนดไว้
1.3. สร้างเงื่อนไขหรือประเภทของรายการที่จะทดสอบให้สัมพันธ์กับเป้าหมาย ให้สามารถคาดคะเนผลลัพธ์ที่จะออกมาได้
1.4. จัดเตรียมข้อมูลที่จะทดสอบตามเงื่อนไขที่ได้สร้างไว้ และจำแนกตามรอบเวลา (Cycle) ที่ได้กำหนดไว้
1.5. คำนวณผลลัพธ์ที่คาดว่าจะได้รับด้วย Manual (ขั้นตอนนี้จะเป็นการฝึกฝน และเพิ่มพูนความเข้าใจของผู้ตรวจสอบ ต่อระบบงานที่ตรวจสอบได้โดยละเอียด)
1.6. ประมวลผลข้อมูลทดสอบที่ได้เตรียมไว้ ตามกระบวนการที่กำหนดไว้ในการประมวลงานตามปกติ
1.7. ตรวจสอบผลลัพธ์ที่ได้จากการประมวลผลด้วยคอมพิวเตอร์ โดยนำไปเปรียบเทียบกับผลลัพธ์ที่คาดว่าจะได้รับตามที่คำนวณได้ด้วย Manual
1.8. สรุปผลการทดสอบและระบุจุดอ่อนที่พบ ซึ่งผู้ตรวจสอบจะต้องระบุสาเหตุของจุดอ่อนแต่ละประเด็น และให้คำแนะนำในการปรับปรุงแก้ไข

โปรดติดตามขั้นตอนต่อไปในครั้งหน้านะครับ

 

ระเบียบคณะกรรมการตรวจเงินแผ่นดิน ว่าด้วยการปฏิบัติหน้าที่ของผู้ตรวจสอบภายใน พ.ศ. 2546 กับ Regulators และ Operators ทางด้าน IT Audit และทั่วไป

คุยกับผู้เขียนในตอนที่แล้ว ผมได้เล่าถึงแนวนโยบายและแนวปฏิบัติในการรักษาความมั่นคงปลอดภัยด้านสารสนเทศของหน่วยงานของรัฐ ซึ่งได้ประกาศในราชกิจจานุเบกษาแล้ว เมื่อวันที่ 23 มิถุนายน 2553 เล่มที่ 127 ตอนพิเศษ 78 ง หน้า 131 – 138 ไปแล้วนั้น ก็เพื่อให้ท่านผู้อ่านทราบว่า หน่วยงานกำกับภาครัฐที่ดูแลรับผิดชอบเกี่ยวกับ ความน่าเชื่อถือได้ของข้อมูล และรายงานทางการเงิน และรายงานที่มิใช่การเงิน ที่ข้อมูลและสารสนเทศถูกประมวลผลด้วยระบบคอมพิวเตอร์ หรือระบบเทคโนโลยีสารสนเทศนั้น ความน่าเชื่อถือได้ของข้อมูล เป็นเรื่องจำเป็นอย่างยิ่งยวดที่ผู้มีผลประโยชน์ร่วมทุกฝ่าย ทั้งในและระหว่างประเทศ ให้ความสนใจในระดับสูงมาก

หากข้อมูลและสารสนเทศไม่น่าเชื่อถือ ความไว้วางใจของ Stakeholders ก็จะไม่มีหรือมีน้อยมาก ทำให้มีปัญหาในเรื่องเกี่ยวกับศักยภาพการแข่งขัน และการสร้าง Value Creation และ Business Objective ขององค์กรต่าง ๆ รวมทั้งความไว้วางใจต่อระดับชาติ ที่จะมีผลกระทบต่อการค้า การเงิน และการลงทุนตามมาด้วยอีกมาก

การบริหารความเสี่ยงทางด้าน Risk IT และ IT Risk ที่มีผลกระทบต่อ Business Process และ Business Objective ในมุมมองต่าง ๆ ตามหลักการของ Balanced Scorecard และตามวัตถุประสงค์ของการควบคุมหลักของ COSO – ERM คือ Strategic Risk – S, Operational Risk – O, Reporting/Finanacial Risk – F, Compliance Risk – C นั้น จำเป็นจะต้องมีการประเมิน และควบคุมความเสี่ยง รวมทั้งการตรวจสอบตามฐานความเสี่ยง และการจัดการโดยผู้บริหาร ทางด้าน IT Control และ IT Audit อย่างหลีกเลี่ยงไม่ได้ ตามที่ปรากฎในมาตรฐานของประเทศต่าง ๆ ทั่วโลก

ผมจึงนำระเบียบคณะกรรมการตรวจเงินแผนดิน ว่าด้วยการปฏิบัติหน้าที่ของผู้ตรวจสอบภายใน พ.ศ. 2546 ที่มีผลบังคับใช้แล้วตั้งแต่ วันที่ 24 มีนาคม 2546 ตามประกาศในราชกิจจานุเบกษา ฉบับกฤษฎีกา เล่ม 120 ตอนที่ 25 ก ซึ่งได้กล่าวถึงแนวทางปฏิบัติหน้าที่ของผู้ตรวจสอบภายใน ขอบเขตการตรวจสอบภายใน โดยเฉพาะอย่างยิ่งแนวทางปฏิบัติที่ 6 หน้า 10 ที่ได้กล่าวในเรื่อง IT Audit ว่า

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

ในกรณีระเบียบว่าด้วยการตรวจสอบภายในตาม (1) และ (2) มิได้กำหนดให้ปฏิบัติงานตามมาตรฐานการตรวจสอบใด ให้ปฏิบัติตามมาตรฐานการปฏิบัติงานวิชาชีพการตรวจสอบภายในที่เผยแพร่โดยสมาคมผู้ตรวจสอบภายในแห่งประเทศไทย หรือ Standards for the Professional Practice of Internal Auditing ที่กำหนดโดย The Institute of Internal Auditors (IIA) ฉบับล่าสุด

ท่านผู้อ่านสามารถคลิ๊กดูรายละเอียดของระเบียบคณะกรรมการตรวจเงินแผ่นดินฯ ได้ที่นี่เลยครับ รวมเล่ม ระเบียบตรวจเงินแผ่นดิน

สำหรับผมเอง มีความเห็นส่วนตัวเพิ่มเติมจากแนวทางปฏิบัติต่าง ๆ ที่ปรากฎในระเบียบของ คตง. ว่า ถ้ามาตรฐานการตรวจสอบทางด้าน IT ยังไม่ปรากฎชัดเจนตามที่ระเบียบของ คตง. ได้กล่าวไว้ตามวรรคต้น ก็น่าจะใช้ Best Practice หรือ IT Audit Guideline ของ สมาคมผู้ตรวจสอบภายในแห่งประเทศไทย (IIAT – สตท.) หรือ IIA – The Institute of Internal Auditors (IIA) สากล นำมาใช้ได้สำหรับการตรวจสอบ IT Audit ซึ่งในปัจจุบันก็มีเผยแพร่ให้ท่านผู้อ่านได้ติดตามจากเว็บไซต์ที่เกี่ยวข้องได้อยู่แล้วครับ

ส่วนรายละเอียดเกี่ยวกับแนวการปฏิบัติและการตรวจสอบทางด้าน IT Audit ซึ่งเป็นเรื่องที่เกี่ยวข้องกับการควบคุมความเสี่ยง และการบริหารความเสี่ยงทางด้าน Risk IT และ IT Risk นั้น ก็เช่นเดียวกันครับที่ท่านสามารถจะติดตามได้จากเว็บไซต์ที่เกี่ยวข้อง ซึ่งผมจะนำมาเล่าสู่กันฟังในโอกาสต่อ ๆ ไปครับ

 

การทดสอบข้อมูลและกระบวนการทำงานในระบบคอมพิวเตอร์ โดยวิธี Test Data (TDM)

วันนี้ผมจะพาท่านผู้อ่านที่สนใจทั้งทางด้าน IT Audit และทางด้าน Manual Audit เพื่อจะก้าวไปสู่การควบคุมภายใน และการตรวจสอบภายในตามฐานความเสี่ยงขององค์กร ที่ประมวลผลโดยคอมพิวเตอร์ว่า ข้อมูลทางด้าน Input – Process – Output ถูกต้อง และน่าเชื่อถือได้หรือไม่นั้น เป็นกระบวนการสำคัญยิ่งของการตรวจสอบภายใน ซึ่งมีหน้าที่หลัก 2 ประการใหญ่ ๆ ก็คือ การให้ความมั่นใจอย่างสมเหตุสมผลว่า ข้อมูลและรายงานถูกต้องน่าเชื่อถือได้และสมบูรณ์ในเวลาที่ต้องการ ไม่ว่าจะเป็นเป้าหมายในการตรวจสอบ Around The Computer หรือ Through The Computer ซึ่งเทคนิคหลังเป็นการตรวจสอบความน่าเชือถือได้ของโปรแกรมที่ใช้ในการประมวลงาน

เทคนิคการทดสอบข้อมูลและกระบวนการทำงานโดยใช้ TDM นี้ ไม่จำเป็นต้องเสียค่าใช้จ่ายในการซื้อโปรแกรม หรืออุปกรณ์ใด ๆ แต่ต้องอาศัยความรู้ความเข้าใจระบบงานและกระบวนการทำงานทางด้านคอมพิวเตอร์ที่เกี่ยวข้อง โดยเฉพาะอย่างยิ่ง ความเข้าใจในการสร้างข้อมูลทดสอบตาม Logic หรือ ตรรกะ ที่เกี่ยวข้องและเชื่อมโยงกับเป้าประสงค์ในการทดสอบกระบวนการควบคุมและกระบวนการประมวลงาน ในมุมมองต่าง ๆ ที่ผู้ตรวจสอบต้องการ โดยเฉพาะอย่างยิ่ง การเปรียบเทียบข้อมูลและผลลัพธ์ที่คาดไว้ก่อนการทดสอบ TDM และข้อมูลผลลัพธ์ที่ผ่านการทดสอบ TDM เพื่อแปลให้ได้ความหมายว่า Process และ/หรือ Output ถูกต้องตามที่ควรจะเป็นหรือไม่

ทั้งนี้ กระบวนการทดสอบดังกล่าว อาจทำความเข้าใจได้ดังจะได้อธิบายตามลำดับดังนี้

Test Data Method

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

เครื่องมือและเทคนิคที่ใช้ในการตรวจสอบมี 2 กลุ่มใหญ่ ๆ คือ
1. เทคนิคการตรวจสอบคอมพิวเตอร์ที่ใช้ตรวจสอบภายหลังจากการประมวลผล
2. เทคนิคการตรวจสอบคอมพิวเตอร์ที่ใช้ตรวจสอบขณะที่ทำการประมวลผล

ซึ่งในแต่ละกลุ่มก็มีวิธีการตรวจสอบข้อมูลและโปรแกรม รวมทั้งระบบการทำงานถูกต้องเชื่อถือได้หรือไม่

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

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

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

การนำ Test Data มาใช้ในการตรวจสอบ
1. ขั้นตอนการตรวจสอบงานด้านคอมพิวเตอร์

การนำ Test Data มาใช้ในการตรวจสอบ

จากผังแสดงขั้นตอนงานตรวจสอบงานด้านคอมพิวเตอร์ข้างต้น จะเห็นว่าเมื่อผู้ตรวจสอบเข้าทำการตรวจสอบจะต้องศึกษาและประเมินประสิทธิภาพการควบคุมภายในเสียก่อน ทั้งนี้ เพื่อใช้กำหนดขอบเขต วิธีการตรวจสอบ และ ระยะเวลาที่จะใช้ หากผู้ตรวจสอบมีความพึงพอใจและเชื่อมั่นในระบบการควบคุมภายใจของกิจการ ก็จะทำการทดสอบว่ามีการปฏิบัติตามระบบการควบคุมที่วางไว้หรือไม่ เรียกว่า ทำ Compliance Test ซึ่งประกอบด้วยการสอบทาน General Controls และ Application Controls หากพบว่าระบบที่วางไว้ดีแต่ยังไม่พอใจในการปฏิบัติตามระบบ ก็ต้องพิจารณาว่ามีการควบคุมอย่างอื่นมาชดเชยหรือไม่ (เช่น การควบคุมทางด้านผู้ใช้) หากไม่มีก็จะต้องจัดทำ Substantive Test ที่ครอบคลุมถึง 100% เพื่อให้ได้มาซึ่งหลักฐานในการยืนยันความถูกต้องของยอดคงเหลือทางบัญชี เช่นเดียวกับในกรณีที่ประเมินประสิทธิภาพการควบคุมภายใน แล้วผู้ตรวจสอบไม่มีความเชื่อถือในระบบก็ต้องจัดทำ Substantive Test 100% เช่นกัน

ในการจัดทำ Compliance Test และ Substantive Test ผู้ตรวจสอบสามารถเลือกใช้วิธีการตรวจสอบที่มีอยู่อย่างมากมายได้ตามความเหมาะสม “Test Data” เป็นเทคนิคอย่างหนึ่งที่สามารถเลือกใช้ในการทำ Compliance Test ภายหลังจากทำการศึกษาและประเมินประสิทธิภาพการควบคุมภายในแล้วมีความเชื่อถือในระบบพอสมควรก็จะใช้ Test Data เพื่อทดสอบการปฏิบัติตามระบบการควบคุมภายในที่กำหนดไว้ แต่เทคนิคนี้ค่อนข้างจะเน้นการทดสอบการควบคุมภายในของ Program หรือ Application Software คือ การควบคุมด้านข้อมูลนำเข้า (Input) การประมวลผล (Processing) และข้อมูลผลลัพธ์ (Output)

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

วิธีการตรวจสอบความถูกต้องของโปรแกรมวิธีหนึ่ง คือ “การตรวจสอบจาก Source Program Listing” ผู้ตรวจสอบจะต้องไล่ดูทีละ Statement ตามลำดับ เพื่อค้นหาข้อผิดพลาดและจุดอ่อนของโปรแกรม ซึ่งกระทำได้ยากในทางปฏิบัติ ด้วยเหตุผลดังต่อไปนี้

1) การตรวจสอบโปรแกรมต้องใช้ความรู้ความชำนาญในด้านโปรแกรมมากกว่าการเขียนโปรแกรมเองตั้งแต่ต้น และการติดตามรายละเอียดในโปรแกรมที่บรรจุคำสั่งนับพัน ทั้งยังขั้นตอนการประมวลผลที่สลับซับซ้อนย่อมเป็นงานที่ยากลำบากยิ่ง ถึงแม้ผู้ตรวจสอบและผู้ช่วยจะเป็นผู้เชี่ยวชาญในด้านโปรแกรมก็ตาม นอกจากนี้ยังต้องใช้เวลาและค่าใช้จ่ายสูงด้วย

2) ผู้ตรวจสอบอาจมองข้ามจุดอ่อนเสียเอง การพัฒนาโปรแกรมให้ใช้งานได้จะต้องใช้เวลานานและทำการทดสอบนับครั้งไม่ถ้วน การตรวจสอบในช่วงเวลาสั้น ๆ จึงไม่อาจมองแง่มุมต่าง ๆ ที่แฝงอยู่ได้อย่างถี่ถ้วน

3) โปรแกรมที่ใช้มักมีการเปลี่ยนแปลงแก้ไขอยู่ตลอดเวลา ถ้าผู้ตรวจสอบวางแผนการตรวจสอบแบบกระจายเป็นระยะตลอดปีบัญชี การที่จะติดตามรายการเปลี่ยนแปลงซึ่งมีจำนวนมาก ทุกรายการย่อมเป็นไปได้ยากในทางปฏิบัติ

ด้วยเหตุผลดังกล่าว การตรวจสอบความถูกต้องของโปรแกรม จึงนิยมใช้วิธีการตรวจสอบทางอ้อม คือ การใช้ เทคนิค Test Data มากกว่า การตรวจสอบจาก Source Program Listing

 

GRC & Career Path กับ ITG เพื่อการก้าวสู่การบริหารแบบ GRC เพื่อขับเคลื่อน Integrity-Driven Performance

สวัสดีครับท่านผู้อ่าน ผมไม่ได้คุยกับท่านผู้อ่านในหัวข้อนี้มานานพอสมควร วันนี้ผมจะนำเรื่อง GRC และ ITG เพื่อการขับเคลื่อน GRC และการสร้างคุณค่าเพิ่มในมุมมองต่าง ๆ ที่เกี่ยวข้อง ในรูปแบบของ Power point และ PDF File ที่จะให้ความเห็นในหลายมุมมองของการสร้างคุณค่าเพิ่ม ทั้งจากในมุมมองของ IT Governance เอง และในมุมมองของ IT Governance ที่ก้าวสู่ GRC อีกบางมุมมองที่ท่านอาจจะต้องใช้จิตนาการเชื่อมโยงทั้งสองเรื่องเข้าด้วยกัน ดังนี้ครับ

ท่านผู้อ่านสามารถคลิ๊กอ่านได้จาก เว็บไซต์ของกระทรวง ICT ได้ทั้งสองเรื่อง …

http://www.ictcareer.net/SeminarProfile.aspx

ครั้งนี้ท่านผู้อ่านสามารถจะติดตามเรื่องราวเกี่ยวกับ GRC ในลักษณะที่บรรยายด้วยแผนภาพที่เป็น Power Point ซึ่งผมจะอธิบายแบบขยายความแบบเพิ่มเติมในโอกาสต่อไป และคำบรรยายของ ITG ที่สามารถสื่อให้เข้าใจได้อย่างง่าย ๆ ว่า ITG เป็นส่วนหนึ่งของ CG ที่แยกกันไม่ได้ และจะเกี่ยวข้องกับการบริหารความเสี่ยง และมีองค์ประกอบที่เกี่ยวข้องกับการบริหารความเสี่ยง ทั้งด้านทั่วไปและทางด้าน IT Risk ที่มีผลต่อ Business Risk โดยเชื่อมโยงกับการควบคุมภายใน และตรวจสอบภายในตามฐานความเสี่ยง ในลักษณะของ IT Audit และ Manual Audit โดยเฉพาะอย่างยิ่ง IT Audit ซึ่งผู้ตรวจสอบภายในจำเป็นจะต้องเข้าใจ การประเมินความเสี่ยงที่มีผลกระทบทางด้าน IT Risk และ Risk IT รวมทั้งการประเมินความเพียงพอของการควบคุมภายในทางด้าน IT ที่มีผลกระทบต่อ Business Risk ในทุกมุมมองของ COSO – ERM ซึ่งผมจะได้อธิบายในครั้งต่อไปนะครับ

 

คำแนะนำและหลักการในการยกระดับการบริหารความเสี่ยงของหน่วยงาน/องค์กร (ต่อ)

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

กรณีที่ 2 การยกระดับการบริหารความเสี่ยงที่ดีในระดับที่สามารถปลูกฝังให้การบริหารความเสี่ยงเป็นส่วนหนึ่งของวัฒนธรรมที่นำไปสู่การสร้างสรรค์มูลค่าให้แก่องค์กร

1. กระบวนการบริหารความเสี่ยง เป็นกิจกรรมประจำวันของทุกหน่วยงาน และเป็นส่วนที่สำคัญของการพิจารณาผลตอบแทน และ/หรือความดีความชอบ

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

องค์กรจะต้องเน้นความสำคัญของกระบวนการบริหารความเสี่ยง โดยถือเป็นส่วนสำคัญของการพิจารณาผลตอบแทนหรือความดีความชอบ โดยในแต่ละสายงานที่เกี่ยวข้องกับความเสี่ยงระดับองค์กร จะมีการถ่ายทอดตัวชี้วัดด้านการบริหารความเสี่ยงลงสู่ระดับสายงานดังกล่าว การเชื่อมโยงผลตอบแทนกับระดับความเสี่ยงที่สามารถลดลงได้ในแต่ละปัจจัยเสี่ยงของแต่ละสายงานนั้น ควรกำหนดให้ชัดเจน และการประเมินผลด้านการบริหารความเสี่ยงที่ถือเป็นส่วนหนึ่งของตัวชี้วัดของสายงานนั้น ๆ โดยเฉพาะผลงานด้านการบริหารความเสี่ยงกับแรงจูงใจพิเศษ

1.2 มีการกำหนดเป้าหมายร่วมกันในแต่ละหน่วยงาน เพื่อนำไปสู่การบริหารความเสี่ยงขององค์กรโดยรวม และมีการติดตามประเมินผลงานอย่างต่อเนื่อง ซึ่งการยกระดับการบริหารความเสี่ยงองค์กรจะต้องมีหลักฐานชัดเจนในการกำหนดเป้าหมายร่วมกันในแต่ละหน่วยงาน เพื่อนำไปสู่การบริหารความเสี่ยงขององค์กรโดยรวม โดยมีการถ่ายทอด (Deploy) เป้าหมายของตัวชี้วัดองค์กรลงสู่สายงานต่าง ๆ รวมถึงมีการถ่ายทอด Risk Appetite ระดับองค์กรลงสู่สายงานต่าง ๆ ด้วยเช่นกัน

2. การบริหารเทคโนโลยีสารสนเทศเพื่อการจัดการที่ดี

2.1 คณะกรรมการจัดให้มีกระบวนการสร้างความมั่นใจถึงความสมดุล ระหว่างผลตอบแทนจากการลงทุนและการจัดการด้าน IT กับความเสี่ยงที่อาจเกิดขึ้น องค์กรควรแสดงให้เห็นถึงการที่คณะกรรมการมีกระบวนการสร้างความมั่นใจถึงความสมดุลระหว่างผลตอบแทนจากการลงทุน และการจัดการด้าน IT กับความเสี่ยงที่จะเกิดขึ้น มีการศึกษาผลตอบแทนด้านการลงทุนด้าน IT ในมุมของผลประโยชน์ ทั้งที่เป็นตัวเงินและมิใช่ตัวเงิน รวมถึงการพิจารณาในเชิงของการระบุความเสี่ยง การประเมินความรุนแรง และการบริหารความเสี่ยง

2.2. Board มีการสร้างเกณฑ์วัดคุณภาพงานและผลสำเร็จของกลยุทธ์ หรือนโยบายและการจัดการด้าน IT ตามที่กำหนดไว้ ฝ่ายบริหารมีการประเมินศักยภาพของ IT และการจัดการอย่างสม่ำเสมอ ทั้งทางด้านการเงินและมิใช่การเงิน ผ่านคณะกรรมการด้าน IT โดยในแผนแม่บท IT ต้องมีการกำหนด KPIs และ Outcome ของแผนงาน/โครงการไว้ชัดเจน และมีการประเมินอย่างต่อเนื่อง

2.3. การดำเนินงานตามแผน ISO 27001 ดีกว่าเป้าหมายที่กำหนดไว้ในแผนประจำปีบัญชี องค์กรมีการจัดทำแผนความมั่นคงปลอดภัยระบบเทคโนโลยีสารสนเทศและการสื่อสาร (ICT Security Plan) ตามแนวทางของมาตรฐาน ISO 21001 โดยมีการดำเนินงานตามแผนงาน/โครงการ ได้ดีกว่าเป้าหมายที่กำหนดไว้

3. มีการบริหารความเสี่ยงและมีการสนับสนุนการบริหารความเสี่ยง เพื่อสร้างสรรค์มูลค่าให้กับองค์กร (Value Creation) ซึ่งมูลค่า (Value) ขององค์กรอาจพิจารณาได้จาก Value ที่องค์กรระบุไว้ รวมถึงการที่องค์กรมีการบริหารความเสี่ยงของการสูญเสีย “โอกาสของธุรกิจ” การที่องค์กรสามารถพลิกผันเหตุการณ์/วิกฤติให้เป็นโอกาสทางธุรกิจ หรือการที่องค์กรมีการบริหารความเสี่ยง เพื่อสร้างความมั่นใจถึงการเป็นองค์กรแห่งการเรียนรู้ (Learning Organization) เพื่อการสร้างสรรค์/นวัตกรรม (Innovation)

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

 

ความเสี่ยงจากเหตุการณ์ และความเสียหายที่จะเกิดขึ้นจากการจัดการ ด้าน IT บางมุมมอง

การจัดการ การควบคุม เกี่ยวกับความเสี่ยงจากเหตุการณ์และ/หรือการกระทำ ความเสียหายที่อาจเกิดขึ้นได้ ที่เกิดจากการประเมิน หรือคาดคะเนเหตุการณ์ หรือปัจจัยเสี่ยงผิดพลาด หรือระบุความเสี่ยงไม่ตรงกับต้นเหตุ โดยเฉพาะอย่างยิ่งความเสี่ยง และปัจจัยที่เกิดจาก Operatinal Risk [P+P+T] ที่เกี่ยวข้องกับ P-People, P-Process, T-Technology ที่เกือบทุกองค์กรมีจุดอ่อน หรือปัญหาด้านนี้สูงสุด แม้กระทั่งในต่างประเทศก็มีปัญหานี้มากเช่นกันนั้น

ความเข้าใจในกระบวนการบริหารความเสี่ยงจึงสำคัญมาก โดยเฉพาะเรื่องการกำหนด Risk appetite และ Risk Tolerlance ทั้งด้าน Non-IT และ IT โดยเฉพาะอย่างยิ่ง Risk IT และ IT Risk ที่มีผลกระทบต่อ Operational Risk ที่องค์กรของรัฐยังมีปัญหาด้านนี้เนื่องจาก COSO-ERM ไม่ได้กล่าวถึงมากนัก และกฎเกณฑ์การประเมินผล ก็ยังไม่มีแนวทางนี้อย่างชัดเจน และเพียงพอกับการใช้เทคโนโลยีสารสนเทศที่เพิ่มขึ้นในทุกระดับของการจัดการ

วันนี้ ผมจึงนำเรื่องนี้ที่เกี่ยวข้องกับ IT Risk ที่ยังไม่เกี่ยวข้องกับเทคนิค มายกตัวอย่างให้ท่านผู้อ่านและผู้ปฎิบัติงาน ได้เห็นภาพบางมุมมอง ที่อาจปิดจุดอ่อนที่เกี่ยวข้องกับการบริหารความเสี่ยงบางประการ เพื่อสร้างความเข้าใจให้มากยิ่งขึ้น ดังนี้ครับ

ความเสี่ยงจากเหตุการณ์ และ/หรือการกระทำ
1. การวิเคราะห์และประเมินผลได้และเสียที่เกิดจากการเปลี่ยนแปลงภายนอก ทั้งทางด้านเทคโนโลยี นวัตกรรมต่าง ๆ ของบุคลากร การควบคุม การตรวจสอบ การบริหารความเสี่ยงที่ไม่เหมาะสม และไม่อาจตอบสนองความต้องการ หรือกลยุทธ์และเป้าหมายที่เปลี่ยนแปลงไปได้ทันเวลา++

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

3. ผู้วิเคราะห์ระบบงานไม่เข้าใจระบบงาน และความต้องการของผู้ใช้ข้อมูลดีพอ รวมทั้งการใช้เทคนิคทางการประมวลผลข้อมูลที่ไม่เหมาะสม ซึ่งจะส่งผลให้คู่มือการปฏิบัติงาน และโปรแกรมงานขาดสาระที่สำคัญไป หรือเกินความเป็นจริง++

4. การออกแบบระบบงานผิดพลาด ทั้ง ๆ ที่มีรายละเอียดความต้องการของผู้ใช้ข้อมูล และด้านเทคนิคครบถ้วน สาเหตุประการหนึ่งเนื่องมาจาก การใช้วิจารณญาณที่ต่างกันของผู้ออกแบบระบบงานแต่ละคน++

5. พนักงานที่มีส่วนในการออกแบบระบบงานไม่มีความสามารถ หรือในกรณีที่ซื้อโปรแกรมสำเร็จรูปมาใช้งาน ก็ได้มีการแก้ไขและดัดแปลงโปรแกรมหลักให้สอดคล้องกับการปฏิบัติงานแบบเดิม ๆ ที่ผู้ใช้เคยชิน โดยไม่คำนึงผลกระทบที่จะตามมา++

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

7. ขาดการสื่อสารและการทำความเข้าใจระหว่างฝ่ายพัฒนาระบบงาน ฝ่ายผู้ใช้ และฝ่ายผู้บริหารระดับสูงที่ดีเพียงพอ++

8. ไม่ได้วางหลักเกณฑ์ไว้ว่า เมื่อใดจึงควรจะหยุดการพัฒนาระบบนั้นได้แล้ว เช่น หากมีการใช้งบประมาณเกิน 10% จะต้องหยุดหรือมีกฎหมายใหม่ ๆ เกิดขึ้น เนื่องจากจะมีผลทำให้ได้รับผลประโยชน์ไม่คุ้มกับค่าใช้จ่ายที่เสียไป++

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

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

11. แนวความคิดและความเข้าใจของพนักงานผู้มีส่วนร่วมในการพัฒนาระบบงานแต่ละคน แตกต่างกัน ทำให้ผลลัพธ์ที่ได้ไม่บรรลุเป้าหมายโดยรวมขององค์กร++

12. ไม่เข้าใจในภาพรวมถึงผลกระทบของการเปลี่ยนแปลง รวมทั้งการไม่เชื่อมโยงความสัมพันธ์ของผลกระทบต่าง ๆ จากการเปลี่ยนแปลงไว้ด้วยกันทั่วทั้งองค์กร++

ตัวอย่างบางประการที่กล่าวข้างต้นเป็นสิ่งที่อาจป้องกันได้ ทั้งโดยการกำกับงานของ Regulators และ ในการปฎิบัติงานของผู้บริหารของแต่ละองค์กร ความเสียหายที่อาจเกิดขึ้นได้

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

2. นอกจากจะสูญเสียค่าใช้จ่ายและไม่ก่อให้เกิดประโยชน์ทางด้านการแข่งขันแล้ว ยังทำให้ฝ่ายบริหารขององค์กรตัดสินใจผิดพลาดด้วย เนื่องจากระบบที่ไม่เอื้ออำนวยให้มี “สารสนเทศ” ที่เหมาะสม เพื่อการบริหารและการจัดการที่ดี ++

3. การบันทึกข้อมูลทางบัญชีผิดพลาดจากตรรกะ (Logic) หรือใช้ระบบบัญชีไม่เป็นที่ยอมรับกันโดยทั่วไป ทำให้ผู้บริหารตัดสินใจผิดพลาด หรือเสียค่าใช้จ่ายเกินความจำเป็น โดยเฉพาะการยกระดับ (Upgrade) ระบบงานหลักในภายหลัง โดยบริษัทผู้พัฒนาโปรแกรมไม่อาจดำเนินการได้ตามมาตรฐานที่ควรจะเป็น หากมีการแก้ไขและดัดแปลงโปรแกรมหลัก ๆ ++

4. สำหรับความเสียหายที่เกิดจากการแก้ไขและ/หรือดัดแปลงนั้น ก็อาจเกิด “จุดอ่อน” ตามมาได้มากมาย และเกินกว่าที่ผู้บริหารและผู้ใช้จะคาดคะเนได้++

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

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

7. เกิดปัญหาซ้ำซาก ทำให้องค์กรตกอยู่ในวังวนของปัญหาต่าง ๆ ตามที่ได้กล่าวมาแล้วข้างต้น++

8. การไม่เข้าใจผลกระทบของเทคโนโลยีสารสนเทศในภาพโดยรวม อาจก่อให้เกิดความเสียหายต่าง ๆ ได้ในลักษณะลูกโซ่ของปัญหา++

ตามที่ได้สรุปมาในข้อต้น ๆ ได้ทั้งหมด จนถึงขั้นวิกฎติก็เป็นไปได้++ การจัดการ/การควบคุมบางประการ

1. กำหนดประเภทของกิจกรรม และเป้าหมายหลักในการพัฒนาระบบงานให้เป็นมาตรฐาน ทันกับเหตุการณ์ในลักษณะเชิงรุก ที่ผู้เกี่ยวข้องควรเข้าใจกระบวนการบริหารความเสี่ยง การควบคุม และการตรวจสอบ ทางด้าน IT และ Non-IT รวมทั้งการบูรณาการอย่างเหมาะสม++

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

3. ผู้บริหารระดับสูงอาจมอบหมายให้ผู้ตรวจสอบภายในขององค์กร เป็นผู้ทำหน้าที่ทบทวนและประเมินผลขั้นตอนของการพัฒนาระบบงานทุกระบบ โดยเฉพาะความเหมาะสมของการควบคุมภายในของระบบงาน การตรวจสอบและการแก้ไขอัตโนมัติโดยระบบ (Automated Solutions) อย่างเหมาะสมและทันเวลา ++

4. กำหนดประเภทของกิจกรรม และเป้าหมายหลัก ในการพัฒนาระบบงานให้เป็นมาตรฐาน จากผู้ที่มีความรู้ความเข้าใจในระบบงาน ++

5. การจ้างบุคคลที่ได้รับการอบรมและฝึกฝนทางด้านวิเคราะห์ระบบงานโดยเฉพาะ หรือส่งพนักงานเข้ารับการอบรม และฝึกฝนด้านเทคนิคเพิ่มเติมอยู่เสมอ

6. ให้จัดทำเอกสารประกอบการวิเคราะห์ทุกขั้นตอน ดังนี้
– รายงานการศึกษาวิเคราะห์ระบบงาน
– รายงานความต้องการของผู้ใช้ที่มีต่อระบบงาน
– รายงานเกี่ยวกับเทคนิคต่าง ๆ ที่จะใช้ในระบบงาน

7. ให้ผู้ใช้ข้อมูลเป็นผู้ทดสอบความถูกต้องของระบบงานที่เรียกว่า การรับรองระบบงาน (Acceptance Test) หรือมอบหมายให้ผู้ตรวจสอบภายในทำหน้าที่ทดสอบระบบ++

8. ให้ผู้ออกแบบระบบงานจัดทำเอกสารประกอบการใช้งานระบบโดยละเอียด

9. การว่าจ้างบุคคลที่มีความสามารถเฉพาะ หรือส่งพนักงานขององค์กรไปเข้ารับการอบรม และฝึกฝนทางด้านเทคนิคเพิ่มเติมอยู่เสมอ ++

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

11. การกำหนดให้ฝ่ายพัฒนาระบบงาน/หัวหน้าโครงการพัฒนาระบบงาน (Project Leader) จัดทำแผนในการพัฒนาระบบงานและตารางการปฏิบัติงานแต่ละโครงการ (Project Planning) พร้อมทั้งมอบหมายงานให้พนักงานที่อยู่ในความรับผิดชอบ ทำการประเมินผลงานตามที่ปรากฎในแผน และจัดรายงานความก้าวหน้าของโครงการ เพื่อเสนอต่อฝ่ายผู้ใช้และฝ่ายบริหารระดับสูงเป็นระยะ ๆ ++

12. มอบหมายให้ผู้ควบคุมงานทบทวนผลลัพธ์ที่ได้จากงานทุกขั้นตอน++

13. มอบหมายให้ผู้ตรวจสอบภายใน หรือผู้ออกแบบระบบงานทบทวนระบบงานนั้นอีกครั้ง หลักจากที่ได้นำระบบไปใช้กับงานจริงแล้วประมาณ 3 – 6 เดือน เพื่อค้นหาข้อผิดพลาดที่ยังมีอยู่ ++แต่ก็มีประเด็นที่พึงพิจารณาและควรระวังหลายประการ เช่น มาตรฐานและศักยภาพของผู้ตรวจสอบ และความอิสระ++

14. ให้ฝ่ายพัฒนาระบบงานจัดทำเอกสารประกอบการปฏิบัติงานทุกขั้นตอนให้เรียบร้อย โดยละเอียด เพื่อส่งให้ฝ่ายผู้ใช้ข้อมูลและฝ่ายบริหารระดับสูงทบทวนได้ทุกขณะเมื่อมี ปัญหาเกิดขึ้น ++

15. ให้ฝ่ายพัฒนาระบบงานจัดทำแผนงานและเป้าหมายของงานแต่ละขั้นตอน ทั้งนี้เพื่อเป็นแนวทางในการปฏิบัติงานแก่พนักงานที่เกี่ยวข้อง อาทิ
– ขั้นตอนการวางแผนระบบ
– ขั้นตอนการพัฒนาระบบ
– ขั้นตอนการติดตั้งในงานระบบ

ความเห็นและข้อแนะนำดังกล่าว น่าจะมีปัญหาในทางปฎิบัติ หรือมาตรฐานการปฎิบัติงาน++
ท่านลองพิจารณาดูนะครับว่าข้อใดที่เหมาะสม ข้อใดที่น่าจะไม่เหมาะสมเพราะขัดกับหลักการและมาตรฐานการปฎิบัติงาน และ

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

 

คำแนะนำและหลักการในการยกระดับการบริหารความเสี่ยงของหน่วยงาน/องค์กร (ต่อ)

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

5. การบริหารเทคโนโลยีสารสนเทศเพื่อการจัดการที่ดี

5.1. ก) องค์กรมีการประเมินผลฝ่ายบริหารในการจัดการกับความเสี่ยง และปัญหาที่อาจเกิดขึ้นทางด้าน IT โดยมีระบบการจัดการดำเนินธุรกิจอย่างต่อเนื่อง (Business Continuity Management : BCM) ของงานหลัก ๆ ทุกด้าน และควรมีการวิเคราะห์ผลกระทบต่อธุรกิจ (Business Impact Analysis : BIA) เพื่อให้ความมั่นใจอย่างสมเหตุสมผลว่า ธุรกิจจะไม่มีปัญหาในสถานการณ์ฉุกเฉินต่าง ๆ อย่างเป็นรูปธรรม เป็นต้น โดย BCM มีวัตถุประสงค์เพื่อให้ธุรกิจสามารถดำเนินการได้อย่างต่อเนื่องด้วยการจัดการที่ดี (ด้าน IT, IT Related และ Non – IT จากสถานการณ์ต่าง ๆ ที่อาจเกิดขึ้นได้ )

ทั้งนี้องค์กรควรมีการดำเนินงานด้าน IT ตามแผนแม่บทเทคโนโลยีสารสนเทศและการสื่อสาร รวมทั้งการพัฒนากระบวนการประเมินความเสี่ยง ด้านความมั่นคงปลอดภัยระบบเทคโนโลยีสารสนเทศและการสื่อสาร ตามมาตรฐานความมั่นคงปลอดภัย ISO/IEC 27001 ที่ดำเนินงานตามระบบจัดการดำเนินธุรกิจอย่างต่อเนื่องของงานหลักทุก ๆ ด้าน และมีการวิเคราะห์ผลกระทบต่อบริษัท การดำเนินกิจกรรมเพื่อลดความเสี่ยง รวมถึงการติดตามประเมินผล

ข) องค์กรมีการกำหนดกรอบการดำเนินงานการบริหารความต่อเนื่องทางธุรกิจ ตามแผนงานการบริหารความต่อเนื่องทางธุรกิจ (Business Continuity Management : BCM) และดำเนินการวิเคราะห์ – ประเมินผลกระทบต่อการหยุดชะงักการดำเนินงานที่สำคัญ ซึ่งประกอบด้วย การประเมินความเสี่ยง (Risk Assessment) การวิเคราะห์ผลกระทบทางธุรกิจ ( Business Impact Analysis: BIA ) และการวิเคราะห์และระบุงานที่สำคัญ (Critical Business Function) โดยวิเคราะห์ผลกระทบทางธุรกิจ ( Business Impact Analysis: BIA ) ซึ่งพิจารณาจากระบบหลัก ที่มีผลกระทบโดยตรงในระยะเวลาสั้นต่อการดำเนินงาน โดยเน้นเรื่อง Time Critical (Maximum Tolerable Period of Disruption : MTPD) เป็นหลัก และให้ความสำคัญต่อผลกระทบทางการเงินและผลกระทบต่อการดำเนินงานขององค์กร

5.2. 1) Board มีการจัดการที่ดีถึงกลยุทธ์ทางด้าน IT คือ ได้มีการจัดทำแผนแม่บทเทคโนโลยีสารสนเทศ และดำเนินงานตามแผน โดยเป็นแผนเชิงกลยุทธ์ ซึ่งได้พิจารณาถึงการเปลี่ยนแปลงสภาวะแวดล้อมด้านเทคโนโลยีสารสนเทศ และการสื่อสารที่มีผลกระทบต่อการดำเนินธุรกิจ ทั้งในปัจจุบันและอนาคต โดยคณะกรรมการฯ มีบทบาทสำคัญ เพราะเป็นผู้ควบคุมดูแลตัดสินใจเรื่องนโยบาย รวมถึงแต่งตั้งฝ่ายจัดการ เพื่อจัดการงานประจำ ดังนั้น คณะกรรมการฯ จึงสามารถบริหารจัดการและติดตามประเมินผลการดำเนินงานโครงการด้าน IT ที่อยู่ในแผนแม่บทเทคโนโลยีสารสนเทศและการสื่อสาร ด้วยการติดตามและรายงานผลการดำเนินงานโครงการตามแผนธุรกิจ ซึ่งมีโครงการคลอบคลุมการดำเนินงานทั้งหมด รวมทั้งโครงการที่อยู่ในแผนแม่บทเทคโนโลยีสารสนเทศและการสื่อสารเป็นไปอย่างเป็นระบบและสอดคล้องกัน

2) คณะกรรมการองค์กรแต่งตั้ง คณะอนุกรรมการกำหนดกลยุทธ์ด้านเทคโนโลยีสารสนเทศ (IT Strategy Committee) เพื่อกลั่นกรองงานด้าน IT โดยมี CIO มีอำนาจหน้าที่ เช่น ให้คำปรึกษาแนะนำ และนำเสนอข้อมูลเชิงลึกด้านเทคโนโลยีสารสนเทศ (IT) แก่คณะกรรมการองค์กร ในเรื่องการพัฒนาเชิงลึกของ IT ความสอดคล้องของ IT กับทิศทางการดำเนินกิจการขององค์กร การมีทรัพยากรด้าน IT ที่พอเพียงและเหมาะสม รวมทั้งทักษะที่จำเป็น และ IT Infrastructure ประโยชน์ที่ได้รับจากการลงทุนด้าน IT ความเสี่ยงที่เกี่ยวข้องกับ IT และความเสี่ยงที่เกิดจากการไม่ปฏิบัติตามนโยบายด้าน IT

5.3. ฝ่ายบริหารมีการประเมินศักยภาพของ IT และการจัดการความมั่นคงปลอดภัย และกฎเกณฑ์ด้าน IT อย่างสม่ำเสมอ ทั้งทางด้านการเงินและมิใช่การเงิน เช่น อัตราการเพิ่มของผลตอบแทนที่ได้จากการลงทุน ทางด้าน IT และระยะเวลาของการเปลี่ยนแปลง กระบวนการและระบบการทำงาน เป็นต้น โดยฝ่ายบริหารจะต้องมีการประเมินศักยภาพ และความคุ้มค่าของการใช้ IT และการจัดการอย่างสม่ำเสมอ ทั้งทางด้านการเงินและมิใช่การเงิน เพื่อการตัดสินใจของคณะกรรมการและผู้บริหารระดับสูง ในเชิงวิเคราะห์เปรียบเทียบกับวัตถุประสงค์และเป้าหมาย อันได้แก่ การนำเทคโนโลยีสารสนเทศและการสื่อสารที่เหมาะสมมาใช้งาน เพื่อพัฒนาระบบงานด้านต่าง ๆ ให้มีประสิทธิภาพ มีคุณภาพที่สอดคล้อง และรองรับต่อความต้องการของลูกค้า และทันต่อการเปลี่ยนแปลง โดยการนำ IT มาช่วยสนับสนุน หรือพัฒนาให้การปฏิบัติงานประจำมีความสะดวก รวดเร็ว ลดระยะเวลาในการทำงาน หรือลดความซ้ำซ้อนในการดำเนินงาน ซึ่งเป็นการใช้งานระบบ IT ทั้งทางด้าน Admin และงานด้านสนับสนุนภารกิจหลัก

5.4. การดำเนินงานตามแผน ISO 27001 เป็นไปตามเป้าหมายที่กำหนดไว้ในแผนประจำปี คือองค์กรได้มีการจัดทำแผนการรักษาความมั่นคงปลอดภัยของระบบเทคโนโลยีสารสนเทศและการสื่อสาร ตามแนวทางของมาตรฐาน ISO 17799 โดยมีการดำเนินการตามแผนงาน/โครงการ ซึ่งประกอบด้วยแผนงาน/โครงการสำหรับระบบงานหลักและระบบงานรอง

6. ผลการบริหารความเสี่ยงที่เกิดขึ้นจริงดีกว่าแผนฯ ในปัจจัยเสี่ยงที่มีความรุนแรงสูง (อยู่ในดุลยพินิจของคณะอนุกรรมการ) และดีขึ้นจากอดีตที่ผ่านมา โดยผลการบริหารความเสี่ยงในทุกปัจจัยเสี่ยงขององค์กร มีระดับความรุนแรงลดลงทุกปัจจัยเสี่ยง ซึ่งในทุกปัจจัยเสี่ยงขององค์กรมีการระบุอย่างชัดเจน ถึงระดับความรุนแรงของความเสี่ยงทั้งก่อนและหลังการบริหารฯ โดยที่ระดับความรุนแรงก่อนและหลังบริหารความเสี่ยงแล้วนั้น องค์กรสามารถบริหารฯ ได้มีระดับความรุนแรงหลังบริหารความเสี่ยงลดลงจากก่อนบริหารความเสี่ยง รวมถึงองค์กรได้มีการดำเนินการตามแผนครบทุกกิจกรรม และมีผลการดำเนินงานดีกว่าเป้าหมายที่กำหนดไว้