Information Technology Governance

การจัดการ การควบคุม เกี่ยวกับความเสี่ยงจากเหตุการณ์และ/หรือการกระทำ ความเสียหายที่อาจเกิดขึ้นได้ ที่เกิดจากการประเมิน หรือคาดคะเนเหตุการณ์ หรือปัจจัยเสี่ยงผิดพลาด หรือระบุความเสี่ยงไม่ตรงกับต้นเหตุ โดยเฉพาะอย่างยิ่งความเสี่ยง และปัจจัยที่เกิดจาก 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. ให้ฝ่ายพัฒนาระบบงานจัดทำแผนงานและเป้าหมายของงานแต่ละขั้นตอน ทั้งนี้เพื่อเป็นแนวทางในการปฏิบัติงานแก่พนักงานที่เกี่ยวข้อง อาทิ
– ขั้นตอนการวางแผนระบบ
– ขั้นตอนการพัฒนาระบบ
– ขั้นตอนการติดตั้งในงานระบบ

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

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

This entry was posted on วันอาทิตย์ที่ 8 สิงหาคม 2010 at 3:58 pm and is filed under COSO-ERM กับ ITG และ GRC กับการวิเคราะห์เพื่อสร้างสรรสาระ. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.