Posts Tagged "การตรวจสอบโดยทั่วไป"

การตรวจสอบองค์กรที่ใช้คอมพิวเตอร์ (IT / Manual Audit) กับความเข้าใจในภาพโดยรวม

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

วันนี้ ผมจะได้อธิบายต่อไป โดยใช้แผนภาพประกอบเป็นส่วนใหญ่ เพื่อพิจารณาขอบเขตการตรวจสอบ เมื่อเทียบกับภาพโดยรวมของการตรวจสอบ ทางด้าน IT / Manual Audit ต่อไปนี้ครับ

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

 

หลักฐานการตรวจสอบองค์กรโดยใช้คอมพิวเตอร์

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

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

ท่านผู้ตรวจสอบด้าน IT และ Non – IT ลองพิจารณาดูซิครับว่า หากท่านหรือผู้ร่วมงานของท่าน ไม่เข้าใจผลกระทบของรูปแบบของหลักฐานที่เปลี่ยนแปลงไป จากกระบวนการที่ใช้คอมพิวเตอร์ ที่มีคุณลักษณะและกระบวนการทำงานที่แตกต่างกัน และด้วยเทคนิคที่ก้าวหน้าไปอย่างรวดเร็วในปัจจุบัน และมีผลต่อรูปแบบของกระบวนการทำงาน ผลกระทบต่อความเสี่ยงในมุมมองต่าง ๆ ทั้งด้าน IT Risk และ Risk IT ที่มีผลต่อ Business Process และ Business Objective ท่านและทีมงานของท่านจะมีวิธีการวางแผนการตรวจสอบอย่างไร จึงจะได้ผลดี และมีคุณภาพที่น่าเชื่อถือได้

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

เรื่องนี้ ผมเคยให้คำแนะนำวิธีการตั้งคำถามในรูปแบบต่าง ๆ ทั้งในลักษณะที่ผู้บังคับบัญชาอาจตั้งคำถามสอบถามผู้ใต้บังคับบัญชา หรือผู้ตรวจสอบต้องการตั้งคำถามกับผู้รับการตรวจสอบในแง่มุมต่าง ๆ ซึ่งมีความหลากหลาย และมีความซับซ้อนเป็นอย่างมาก ที่มีผลกระทบทางด้าน People Risk + Process Risk + Technology Risk (PPT)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

10. คู่มือปฏิบัติงาน
ในระบบที่ทำด้วยมือ มักมีคู่มือปฏิบัติงานที่แสดงรายละเอียดแต่ละขั้นตอนของการประมวลรายการ เพื่อเป็นแนวทางสำหรับผู้ปฏิบัติงาน แต่ในระบบงานคอมพิวเตอร์คู่มือเหล่านี้อาจอยู่ในรูปของ Computer Program Listing, Data Dictionary Listing และเอกสารที่ผู้ขาย Software มอบให้แก่องค์กร

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

12. การแบ่งแยกหน้าที่
ในระบบที่ทำด้วยมือ การแบ่งแยกหน้าที่ มักกระทำโดยการแบ่งแยกงาน ในระหว่างบุคคลต่าง ๆ เพื่อเกิดการควบคุมซึ่งกันและกัน ซึ่งก็มักเพียงพอและไม่ใคร่มีปัญหา แต่ในระบบงานคอมพิวเตอร์การแบ่งแยกงานในระหว่างบุคคลต่าง ๆ นั้นยังไม่เพียงพอ จำเป็นต้องมีการแบ่งแยกงานระหว่างขั้นตอนการประมวลผลโดยอัตโนมัติในแต่ละขั้นด้วย

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

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

 

การวางแผนการตรวจสอบ ทางด้าน IT Audit – General Control และ Application Control ในองค์กรที่ใช้คอมพิวเตอร์

ผมเคยพูดถึง ขั้นตอนการวางแผนการตรวจสอบในองค์กรที่ใช้คอมพิวเตอร์ ในภาพกว้าง ตามมุมมองต่าง ๆ มาแล้ว วันนี้ ก่อนที่จะลงรายละเอียดในเรื่อง การตรวจสอบทางด้าน IT และ Non – IT Audit ผมใคร่จะขอกล่าวถึง ขั้นตอนและการวางแผนงานการตรวจสอบทางด้าน General Control และ Application Control ซึ่งเป็นการตรวจสอบงานทางด้านคอมพิวเตอร์ หรือ IT

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

จากแผนภาพที่แสดงขั้นตอนความเกี่ยวพันในการวางแผนการตรวจสอบ ดังจะกล่าวต่อไปนี้นั้น ขอให้ผู้ตรวจสอบ และคณะกรรมการตรวจสอบ รวมทั้งผู้บริหารที่เกี่ยวข้องได้ประเมินถึงความเสี่ยง และศักยภาพในการดำเนินงานของสายงานตรวจสอบ ที่จะมีผลกระทบต่อกลยุทธ์การดำเนินงาน ประสิทธิภาพ ประสิทธิผลในการดำเนินงาน ความถูกต้องของรายงานทางการเงิน และรายงานต่าง ๆ และการปฏิบัติตามกฎหมาย กฎเกณฑ์ ตามหลักการของ COSO – ERM ในส่วนที่เกี่ยวข้องกับความเสี่ยงและการควบคุมทางด้าน S – O – F – C ต่อไป

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

ขั้นตอนการวางแผนการตรวจสอบตามแผนภาพนี้ จะทยอยเล่าสู่กันฟังอย่างต่อเนื่องกันไปนะครับ

 

ความเข้าใจในกระบวนการตรวจสอบ กับการวางแผนการตรวจสอบ ทั้งทางด้าน IT Audit และ Manual / Non – IT Audit (ต่อ)

วันนี้ ท่านผู้ที่ติดตามในเรื่องการตรวจสอบ จะได้พบกับคำใหม่คำหนึ่ง ซึ่งผมพึ่งนำมาใช้ในการเขียนเกี่ยวกับการตรวจสอบ ก็คือ Manual Audit ซึ่งหมายถึง Non – IT Audit ด้วยนั้น ก็เพราะ ตั้งใจที่จะให้ท่านผู้อ่านได้ทราบว่า ในหลาย ๆ กรณีที่ผู้ตรวจสอบใช้เทคนิคการตรวจสอบด้าน IT ในลักษณะ Around the Computer คือการตรวจสอบ Input กับ Output โดยไม่มีการวางแผน และดำเนินการตรวจสอบ Process ซึ่งเกี่ยวข้องกับการตรวจสอบความถูกต้องของ Program การปฏิบัติงาน รวมทั้ง Application ต่าง ๆ นั้น จะมีผลอย่างไรต่อการวางแผนการตรวจสอบ และความต้องการของผู้มีผลประโยชน์ร่วม (Stakeholders)

ในกรณีที่กล่าวในวรรคต้น ผู้ตรวจสอบบางท่าน อาจสรุปตามความเข้าใจของตนเองว่า นี่เป็นการตรวจสอบทางด้าน IT หรือ IT Audit แล้ว เพราะเทคนิคการตรวจสอบทางด้าน IT มี 2 รูปแบบหลัก ๆ ก็คือ ใช้เทคนิค Around the Computer และเทคนิคตรวจสอบที่เรียกว่า Through the Computer ซึ่งเป็นการตรวจสอบ Input กับ Process โดยเฉพาะอย่างยิ่ง การเน้น Logic หรือความสมเหตุสมผลของโปรแกรมที่เกี่ยวข้องในการปฏิบัติงานว่า มีการปฏิบัติการและมีการควบคุมจุดอ่อนที่เป็นความเสี่ยง ในกิจกรรมที่เกี่ยวข้อง ที่มีผลต่อ Business Process ที่ส่งต่อไปยัง Business Objective ในรายงานต่าง ๆ ที่ผู้บริหารและผู้ที่เกี่ยวข้องต้องใช้อย่างไรบ้าง

ผมเคยกล่าวย้ำอยู่บ่อย ๆ ว่า หากข้อมูลหรือสารสนเทศ ที่ปรากฎในรายงานต่าง ๆ ไม่ถูกต้อง ไม่น่าเชื่อถือได้ ไม่ Update ซึ่งเกิดจากองค์ประกอบหลัก ๆ 3 ประการ หรือ 7 ประการ ขึ้นกับว่า ผู้ตรวจสอบจะใช้มาตรฐาน ISO 27001 ที่พูดถึง CIA – Confidentiality, Integrity, Availabity หรือใช้องค์ประกอบที่ดีของสารสนเทศ ตามกรอบของ CobiT ซึ่งมี 7 องค์ประกอบด้วยกัน นอกเหนือไปจาก CIA ก็คือ Effectivess, Efficiency, Reliability, Compliance ที่ผมได้กล่าวอยู่หลายครั้งแล้วนะครับ

การตรวจสอบใด ๆ ที่ไม่มีการตรวจสอบความน่าเชื่อถือได้ของกระบวนการปฏิบัติงาน และการควบคุมที่เกี่ยวข้อง ที่เกี่ยวข้องกับ Application จะสรุปว่า เป็นการตรวจสอบทางด้าน IT แล้ว ไม่น่าจะเหมาะสมนัก ถึงแม้จะมีการตรวจสอบทางด้าน General Control มาแล้วก็ตาม รายละเอียดผมจะขออธิบายและกล่าวถึงทั้ง 2 เรื่องในโอกาสต่อไป

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

Audit Committee and Auditors Understanding in Holistic Framework of Audit Risk Perspective and Concerned

ความเสี่ยงในการตรวจสอบหลัก ๆ ที่เกี่ยวข้องกับการวางแผนการตรวจสอบ ก็คือ

– Poor Security ที่เกี่ยวข้องกับหลักการ CIA 3 ข้อหลัก และ/หรือหลักการตาม CobiT 7 ข้อหลัก,

– Poor Management ผู้บริหารและผู้ที่เกี่ยวข้องไม่เข้าใจกระบวนการบริหาร ตามหลักการของ GRC ที่เกี่ยวข้องกับ Integrity – Driven Performance และการควบคุมความเสี่ยงที่ขาดการประสานและบูรณการ ของการควบคุมในแต่ละ Activities ที่ส่งผลไปยังความสมบูรณ์ในการควบคุมในแต่ละ Business Process และมีผลต่อเนื่องไปยัง การโอน แก้ไข การปรับปรุงข้อมูล การข้ามขั้นตอนการควบคุม (Override) ของผู้บริหาร ซึ่งทำให้พิจารณาได้ว่า ไม่มีการควบคุมอยู่เลย ซึ่งเป็นอันตรายอย่างยิ่ง และมีตัวอย่างมากมายในประเทศไทย รวมทั้งที่เกิดขึ้นในสถาบันการเงินบางแห่ง เมื่อไม่นานมานี้ ทำให้การวิเคราะห์ และความถูกต้องของรายงาน รวมทั้งการตัดสินใจ ที่มาจากรายงานถูกบิดเบือนไปและไม่ถูกต้อง ซึ่งมีผลสำคัญอย่างยิ่งยวดต่อการวางแผนการตรวจสอบ ทั้งทางด้าน IT และ Non – IT / Manual Audit เพราะผู้ตรวจสอบส่วนใหญ่ ก็เข้าไม่ถึงจุดอ่อนที่อยู่สูงเกินความสามารถของผู้ตรวจสอบ ซึ่งอาจจะอยู่ในระดับที่ต่ำกว่า C-Level เป็นส่วนใหญ่

เป็นที่แน่นอนว่า จาก Poor Security และตามมาด้วย Poor Management
ที่กล่าวข้างต้น จะทำให้การวางแผนการตรวจสอบที่ต้องผ่านคณะกรรมการตรวจสอบ จะมีจุดอ่อนอย่างมีนัยสำคัญ และส่งผลอย่างมีนัยสำคัญยิ่งต่อ Audit Risk นั่นคือ ผู้ตรวจสอบไม่ได้วางแผนการตรวจสอบ ให้สัมพันธ์กับความเสี่ยง ในเรื่อง Poor Security และ Poor Management ตามหลักการ IT Governance และตามหลักการของ GRC

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

คำถามสำคัญต่อคณะกรรมการตรวจสอบ และผู้ตรวจสอบ ก็คือ คณะกรรมการตรวจสอบจะทราบได้อย่างไรว่า การวางแผนการตรวจสอบเพื่อประเมินศักยภาพของการควบคุม ทั้งทางด้าน IT และ Non – IT นั้น น่าเชื่อถือได้ และต้องการศักยภาพของผู้ตรวจสอบในมุมมองใด จึงจะสามารถลดความเสี่ยงทางด้าน Audit Risk ในมุมมองของ CG + ITG + GRC ที่เหมาะสมได้

– Fraud การวางแผนการตรวจสอบ และการปฏิบัติงานตรวจสอบการทุจริต ในอดีตเป็นเป้าหมายหลักของผู้ตรวจสอบภายใน และต่อมา มาตรฐานการตรวจสอบภายในก็ได้เปลี่ยนแปลงว่า ผู้ตรวจสอบภายในจะตรวจสอบศักยภาพและความสามารถในการจัดการ ทางด้านต่าง ๆ ตามหลักการของห BSC และต่อมาในปัจจุบันก็คือ ผู้ตรวจสอบภายใน ทำหน้าที่ให้คำปรึกษากับผู้บริหารสายงานต่าง ๆ ซึ่งเมื่อพิจารณาตาม wording ของมาตรฐานที่กำหนดไว้ ก็ดูดี และทำให้ผู้ได้รับการตรวจสอบ มีความพึงพอใจในเป้าประสงค์ที่เปลี่ยนแปลง ในการเพิ่มคุณค่าให้กับองค์กร แทนการจับผิดในลักษณะเดิมเป็นอย่างมาก

อย่างไรก็ดี มาตรฐานการตรวจสอบผู้รับรองงบการเงิน ของบริษัทยักษ์ใหญ่ ในระดับโลก ซึ่งปัจจุบันเป็นที่รู้จักกันดีว่ามี 4 บริษัท นั้น จะต้องมีการปฏิบัติงานเพื่อสอบทาน ความน่าเชื่อถือได้ ของการควบคุมภายใน ที่มีผลต่อการทุจริตในมุมมองต่าง ๆ ที่มีนัยสำคัญ โดยเฉพาะอย่างยิ่ง มีผลกระทบต่อรายงานทางการเงิน ที่ปรากฎขึ้นแล้ว หรือ อาจปรากฎขึ้นในอนาคต จากกระบวนการทำงานที่มีจุดอ่อน โดยเฉพาะอย่างยิ่ง จากระบบการดำเนินงานขององค์กร ซึ่งเรียกกันทั่ว ๆ ไปว่า Operational Risk ที่จะส่งผลกระทบอย่างสำคัญยิ่งต่อ Financial Risk เป็นต้น

Audit Committee and Understanding / Long Term Sustainable Sucess of the Enterprise in Credit Risk Management

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

ท่านทราบไหมครับว่า องค์กรของท่านเอง อาจจะมีความเสี่ยงจาก Audit Risk ในขณะเดียวกันก็มีความเสี่ยงที่สำคัญยิ่ง ต่อการบริหารความเสี่ยงทั่วทั้งองค์กร ที่คณะกรรมการและผู้บริหารควรจะได้เข้าใจผลกระทบต่อ IT Risk ที่มีต่อ Business Risk อย่างมีนัยสำคัญ ตามที่กล่าวข้างต้น

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

 

ผลสอบการทุจริต กรณียักยอกเงิน 500 ล้านบาท ของ ธอส.

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

ต่อจากนี้ไปเป็นรายงานผลสอบสวนของคณะกรรมการตรวจสอบข้อเท็จจริงชุดที่มี น.ส. โสภาวดี เลิศมนัสชัย เป็นประธานการตรวจสอบ ซึ่งได้ชี้ให้เห็นถึงจุดที่ผิดพลาดอย่างละเอียด รวมถึงการป้องกันปัญหาของธนาคารภายหลังที่เกิดเรื่อง

ประเด็นคำถามที่จะช่วยในการตรวจสอบ

ข้อเท็จจริงเกี่ยวกับผู้ทุจริตและการทุจริต
ประวัติผู้ทุจริต นายสมเกียรติ ปัญญาวรคุณเดช ตำแหน่งพนักงานธุรกิจสาขาอาวุโส เกรด 7 สาขาเซ็นหลุยส์ 3 อายุ 33 ปี ปฏิบัติงานเจ้าหน้าที่การเงินที่สาขาเซ็นหลุยส์เพียงสาขาเดียวเป็นเวลา 9 ปี ตั้งแต่วันที่ 1 ก.ย. 2542 ถึงปัจจุบัน จำนวนเงินที่ทุจริต 499,272,777.95 บาท โดยมีระยะเวลาที่ทำการทุจริต ตั้งแต่วันที่ 8 พ.ย. 2550 – 20 เม.ย. 2552

วิธีการทุจริตมี 2 แบบ ง่าย ๆ ไม่มีอะไรซับซ้อน
1. การปลอมสลิปถอนเงินจากบัญชีลูกค้า โดยการปลอมสลิปถอนเงินจากบัญชีเงินฝากประจำลูกค้าราย นางเล่งบ่าย รงคพรรณ จำนวน 2 บัญชี รวม 6 รายการ จำนวนเงินรวม 36.50 ล้านบาท ซึ่งเป็นการทำทุจริตระหว่างวันที่ 8 พ.ย. 2550 ถึงวันที่ 23 ม.ค. 2551

2. การสร้างรายการค่าใช้จ่ายประเภทบัญชีดอกเบี้ยจ่ายเงินฝากประจำของสำนักพระราม 9 และสาขาเซ็นหลุยส์ 3 จำนวน 419 รายการ จำนวนเงินรวม 499.27 ล้านบาท ทั้ง ๆ ที่ นายสมเกียติ ไม่มีเงินฝากประจำที่สาขาทั้ง 2 แห่งแต่อย่างใด และในขณะเดียวกัน นายสมเกียรติ ก็สร้างรายการฝากเงินเข้าบัญชีของตนเอง หรือผู้ที่เกี่ยวข้องในจำนวนเดียวกับดอกเบี้ยเงินฝากประจำที่สร้างขึ้นดังกล่าวข้างต้น ซึ่งเป็นการทำการทุจริตในช่วงหลัง Go Live โดยเริ่มตั้งแต่วันที่ 20 ก.พ. 2551 ถึง 20 เม.ย. 2552

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

2. นายสมเกียติทำการทุจริต โดยเข้าไปสร้างรายการดอกเบี้ยจ่ายในระบบบัญชี GL ของธนาคารได้จำนวน 499.27 ล้านบาท โดยมีปัจจัยมาจาก 2 ประการ คือ

ประการแรก ระบบงานโดยเฉพาะหน้าจอ (MENU) ที่ใช้ในการปรับปรุงดอกเบี้ยจ่ายและการทำรายการข้ามสาขาเปิดให้พนักงานทุกระดับ (Work Class) สามารถทำรายการได้ในบัญชี GL ของธนาคาร โดยไม่มีการอนุมัติผ่านรายการ (Verify) ซึ่งเป็นปัจจัยที่ช่วยให้ นายสมเกียรติ สามารถเข้าไปทำรายการดอกเบี้ยจ่ายในระบบงานบัญชี GL ของธนาคารได้

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

วิธีการตรวจสอบระบบงาน

จากปัจจัย 2 ประการข้างต้น คณะกรรมการสามารถสรุปได้ คือ
1. ระบบงานโดยเฉพาะหน้าจอที่ใช้ในการปรับปรุงดอกเบี้ยจ่าย และการทำรายการข้ามสาขา หรือ MENU HXFER เปิดให้พนักงานทุกระดับสามารถทำรายการได้ในบัญชี GL ของธนาคาร โดยไม่มีการ Verify มีสาเหตุมาจาก

1.1. ธนาคารไม่ได้กำหนดสิทธิในการเข้าถึง MENU HXFER ทั้งที่เมนูดังกล่าวสามารถเชื่อมโยงกับงานบัญชี GL ของธนาคาร เนื่องจาก Architecture ของ CBS ระบบเก่าและใหม่แตกต่างกันอย่างมีสาระสำคัญ คือ ในระบบใหม่ได้รวมระบบ GL เข้าไว้ในระบบ ในขณะที่ระบบเดิมแยกระบบ GL ออกต่างหาก ซึ่งผู้ที่เกี่ยวข้องรับทราบประเด็นความแตกต่างดังกล่าว หากแต่ไม่ได้ตระหนักถึงความเสี่ยง หรือโอกาสที่จะก่อให้เกิดความเสียหาย หากไม่มีระบบการควบคุมที่เหมาะสม

1.2. ภายหลังจากการ Go Live แล้ว ธนาคารประสบปัญหาในการให้บริการ โดยเฉพาะธุรกรรมเงินฝาก ซึ่งระบบคิดดอกเบี้ยเงินฝากประจำที่จ่ายให้ผู้ฝากผิด จึงได้นำ MENU HXFER มาใช้ในการปรับปรุงรายการดอกเบี้ยจ่าย

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

2. สำนักงานพระราม 9 และสาขาเซ็นหลุยส์ 3 ซึ่งเป็นเจ้าของบัญชีดอกเบี้ยจ่าย ไม่ได้ตรวจสอบงดทดลองประจำวัน มีสาเหตุจาก

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

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

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

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

 

แผนกลยุทธ์การตรวจสอบและกรอบการตรวจสอบภายในขององค์กรโดยทั่วไป

ครั้งที่แล้วผมได้นำเสนอกรอบการตรวจสอบเรื่องการทุจริต และตั้งใจว่าจะตามด้วยสัญญาเตือนภัยของเหตุการณ์ที่อาจก่อให้เกิดการทุจริต (Red Flag) ได้ อย่างไรก็ดี เพื่อให้ท่านผู้อ่านที่ติดตามเรื่องการตรวจสอบทางด้าน IT และ Non – IT Audit ได้ทราบถึงหัวข้อของแผนกลยุทธ์การตรวจสอบและกรอบการตรวจสอบภายในขององค์กรโดยทั่วไป ผมจึงจะขอนำเสนอและอธิบายด้วยแผนภาพ เพื่อให้เกิดความเข้าใจและติดตามได้โดยง่าย

Internal Auditing Standards and Auditors & CEA

Internal Auditing Standards and Auditors & CEA

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

Lists the phases of a typical audit and Auditors

Lists the phases of a typical audit and Auditors

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

ผมเองจะมุ่งให้คำอธิบายและแนะนำแนวทางการตรวจสอบที่ผสมผสานระหว่าง IT Audit และ Non – IT Audit ที่อาจไม่ได้กล่าวไว้ในหนังสือแนวทางดังกล่าวข้างต้น เพื่อให้เกิดความเข้าใจในอีกมุมมองหนึ่ง

Lists the phases of a typical audit and Auditors

Lists the phases of a typical audit and Auditors

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

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

Risk-based Audit Approach and Auditors

Risk-based Audit Approach and Auditors

สำหรับการตรวจสอบการปฏิบัติการ โดยเฉพาะอย่างยิ่งการตรวจสอบที่เกี่ยวกับความเสี่ยงทางด้านผู้บริหาร และพนักงาน (People Risk) กระบวนการดำเนินงาน (Process Risk) และเทคโนโลยี (Technology Risk) ซึ่งเป็นเรื่องที่มีความสำคัญมาก โดยเฉพาะอย่างยิ่ง ธนาคารแห่งประเทศไทย ก็ให้ความสำคัญและให้น้ำหนักของกระบวนการตรวจสอบด้าน Operational Risk ซึ่งจะมีผลอย่างสำคัญต่อ Management Risk ที่มีผลกระทบต่อองค์กรในวงกว้าง และบางกรณีมีผลกระทบไม่เฉพาะหน่วยงานใด หน่วยงานหนึ่ง แต่มีผลกระทบต่อระบบงานและสังคมในภาพใหญ่เลยทีเดียว

Understand the Control Environment and Flow of Transactions

Understand the Control Environment and Flow of Transactions

สำหรับการตรวจสอบและประเมินศัยกภาพการปฏิบัติตาม Compliance ขอให้ท่าน CAE และผู้ตรวจสอบทุกท่าน ได้โปรดอย่าลืมว่า การบริหารเพื่อสร้างคุณค่าเพิ่มในลักษณะของ GRC ซึ่งเป็นกระบวนการขับเคลื่อนระบบบริหารแบบบูรณาการทั่วทั้งองค์กร ที่เรียกว่า Integrity – Driven Performance และเป็น A New Strategy for Success ผ่านกระบวนการ GRC ซึ่งเป็นแนวทางปฏิบัติของการบริหารยุคใหม่ที่เปลี่ยนคำจำกัดความในการบรรลุเป้าหมาย โดยมุ่งเน้น Stakeholders แทน Shareholders และได้เพิ่มการปฏิบัติตามมาตรฐาน และการสร้างจริยธรรมทางธุรกิจในการบริหารอย่างเป็นกระบวนการ ตามที่ผมได้กล่าวไว้ในหัวข้อ GRC ในวันนี้และในวันต่อ ๆ ไปนั้น ขอให้ท่านผู้บริหารงานตรวจสอบได้ลองติดตามดูว่า หากท่านจะวางแผนการตรวจสอบการบริหารงานยุคใหม่ที่ใช้กรอบของ GRC เป็นหลักแล้วละก็ ท่านควรจะวางแผนและปฏิบัติงานตรวจสอบเช่นใดจึงจะเหมาะสมนะครับ

 

การพัฒนาระบบเทคโนโลยีสารสนเทศที่มีจุดอ่อนและอาจนำไปสู่ความเสียหาย (ต่อ)

วันนี้เรามาต่อกันในส่วนของการจัดการและการควบคุมจุดอ่อนของการพัฒนาระบบงานเทคโนโลยีสารสนเทศบางประการกันครับ

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

2. 1) กำหนดประเภทของกิจกรรม (Activities) และเป้าหมายหลัก (Objectives) ในการพัฒนาระบบงานให้เป็นมาตรฐานจากผู้ที่เข้าใจจริง
2) ให้ผู้บริหารระดับสูงขององค์กรหรือมอบหมายให้ผู้ตรวจสอบภายในทำหน้าที่ทบทวนและประเมินผลทุกขั้นตอนของการพัฒนาระบบงานทุกระบบ

3. 1) การจ้างบุคคลที่ได้รับการอบรมและฝึกฝนทางด้านนี้โดยเฉพาะหรือส่งพนักงานที่มีอยู่ไปเข้ารับการอบรมและฝึกฝนทางด้านเทคนิคเพิ่มเติมภายในและภายนอกอยู่เสมอ
2) ให้จัดทำเอกสารประกอบการวิเคราะห์ทุกขั้นตอน :-
2.1) รายงานการศึกษาระบบงาน
2.2) รายงานความต้องการของระบบงาน
2.3) รายงานเกี่ยวกับเทคนิค
2.4) แผนการสร้างระบบงาน ฯลฯ
3) ให้ผู้ใช้ข้อมูลเป็นผู้ทดสอบระบบงานหรือที่เรียกว่า Acceptance Test หรืออาจมอบหมายให้ผู้ตรวจสอบ ภายในเป็นผู้ทำหน้าที่ทดสอบระบบงาน

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

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

6. 1) การกำหนดให้ผู้บริหารโครงการพัฒนาระบบใหม่ (Project Leader) จัดทำแผนและตารางการปฏิบัติงาน แต่ละโครงการ (Project Planing) และการมอบหมายงานให้พนักงานที่อยู่ในความรับผิดชอบการประเมินผลงานและการรายงานความคืบหน้าของ โครงการ (Status report)
2) มอบหมายให้ผู้ควบคุมงาน ทบทวนผลลัพธ์ที่ได้จากงานทุกขั้นตอน
3) มอบหมายให้ผู้ตรวจสอบภายในหรือผู้ออกแบบระบบงานทบทวนระบบงานนั้นอีกครั้งหลังจากที่ปล่อยให้ใช้กับงานจริงแล้ว 3 – 6 เดือน เพื่อค้นหาข้อผิดพลาดที่ยังหลงเหลือ เช่น เสียค่าใช้จ่ายในการปฏิบัติงานมากเกินไป

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

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

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

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

11. 1) ให้ฝ่ายพัฒนาระบบงานจัดทำแผนงานและเป้าหมายของงานแต่ละขั้น เพื่อเป็นแนวทางในการปฏิบัติงานแก่พนักงานที่เกี่ยวข้อง
1.1) System Planing Steps
1.2) Development Steps
1.3) Implementation Steps
2) ให้ฝ่ายพัฒนาระบบงานทบทวนความถูกต้องทางด้านเทคนิคทั้งหมด
3) มอบหมายให้ผู้ตรวจสอบภายในเข้าไปร่วมในการพัฒนาระบบงานและทดสอบความถูกต้องของระบบงานนั้นก่อนนำออกไปใช้งานจริง
4) ให้ฝ่ายพัฒนาระบบงานทบทวนความถูกต้องของระบบงานนั้นอีกครั้งเมื่อปล่อยให้ใช้กับงานจริงแล้ว 3 – 6 เดือน
5) ให้จัดทำเอกสารประกอบระบบงานโดยละเอียดทั้งหมด

 

การพัฒนาระบบเทคโนโลยีสารสนเทศที่มีจุดอ่อนและอาจนำไปสู่ความเสียหาย

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

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

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

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

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

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

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

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

ในกรณีองค์กรซื้อโปรแกรมสำเร็จรูปมาใช้งาน แต่ผู้ใช้ไม่เข้าใจ “function” การทำงานต่าง ๆ ดีพอ จึงมีความพยายามในการ “Modify” และ/หรือ “Customize” ระบบงานใหม่

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

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

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

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

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

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

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

3. สูญเสียค่าใช้จ่ายและทำให้ฝ่ายบริหารตัดสินใจผิดพลาดได้ในขั้นตอนที่สำคัญ ๆ ซึ่งจะมีความเสียหายตามมาจากความเสี่ยงต่าง ๆ ที่เกิดขึ้นได้อีกมาก

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

5. การบันทึกข้อมูลทางบัญชีผิดพลาดหรือระบบบัญชีไม่เป็นที่ยอมรับกันโดยทั่วไป ทำให้ผู้บริหารตัดสินใจผิดพลาดหรือเสียค่าใช้จ่ายเกินความจำเป็น โดยเฉพาะการ Up-date ระบบงานหลักในภายหลัง โดย Supplier ไม่อาจดำเนินการได้ตามมาตรฐานที่ควรจะเป็นหากมีการ Modify/Customize โปรแกรมหลัก ๆ

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

สำหรับความเสียหายที่เกิดจากการ “Modify” และ/หรือ การ “Customize” นั้นก็อาจเกิด “จุดอ่อน” ตามมาได้มากมายและเกินกว่าที่ผู้บริหารและ Users จะคาดคะเนได้

7. 1) การตัดสินใจผิดพลาด
2) ผลตอบแทนการพัฒนา
3) ระบบงานใหม่ไม่คุ้มค่า
4) เสียประโยชน์จากการแข่งขัน
5) การประมวลผลหยุดชะงัก
6) ค่าใช้จ่ายมากเกินไป
7) การทุจริต
8) การประมวลผลผิดพลาด
9) การบันทึกบัญชีไม่ถูกต้อง

8. 1) สูญเสียค่าใช้จ่ายไปโดยไม่ได้รับประโยชน์คุ้มค่า
2) ใช้ IT ไม่สอดคล้องกับความต้องการของธุรกิจ/องค์กร
3) ใช้ IT ไม่คุ้มค่า

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

10. 1) สูญเสียค่าใช้จ่ายโดยไม่ได้รับประโยชน์คุ้มค่าและอาจต้องพัฒนาระบบงานขึ้นใหม่ทั้งหมด แทนที่จะเปลี่ยนแปลงเพียงบางส่วน ซึ่งจะทำให้เสียค่าใช้จ่ายเพิ่มมากขึ้น
2) เกิดปัญหาซ้ำซาก ทำให้องค์กรตกอยู่ในวังวนของปัญหาต่างๆ
3) ปัญหาอื่น ๆ ตามที่ได้กล่าวมาแล้วเกือบทุกข้อ

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

ครั้งหน้าไปต่อในส่วนของการจัดการและการควบคุมจุดอ่อนของการพัฒนาระบบงานด้านเทคโนโลยีสารสนเทศบางประการกันครับ

 

Control Self Assessment – CSA กับการควบคุมความเสี่ยงจากการทุจริตและบทบาทของผู้บริหาร

มีท่านผู้อ่านจำนวนหนึ่งกำลังติดตามความคืบหน้าของการเปิดเผยข้อมูล จากการทุจริตของสถาบันการเงินต่าง ๆ ที่อยู่ระหว่างการเปิดเผยของผู้บริหารระดับสูงขององค์กรเหล่านั้น ซึ่งท่านผู้อ่านอาจจะติดตามได้โดยตรง สำหรับผมเพียงแต่จะให้ข้อสังเกตบางมุมมองของการป้องกันความเสี่ยงในเชิงรุก และการติดตามช่องว่างที่เป็นจุดเปิดที่อาจก่อให้เกิดการทุจริตได้ (Exposure) โดยให้หน่วยงานที่เกี่ยวข้องกับสถาบันการเงินต่าง ๆ ร่วมกับสถาบันการเงินนั้น ๆ ทำการประเมินตนเองว่าองค์กรของตนมีความพร้อม หรือมีจุดอ่อนอะไรบ้าง ที่อาจเกิดจาก People Risk – P, Process Risk – P, และ Technology Risk – T ซึ่งเป็นองค์รวมหลักของ Operational Risk ของทุกองค์กร

สำหรับวันนี้ ผมขอ update ข้อมูลซึ่งหลุดหายไปจากระบบ จากการที่ผมได้เล่าสู่กันฟังเมื่อวันที่ 6 มิถุนายน 2552 ผมขอเริ่มต้นใหม่ที่มีเนื้อหาไม่แตกต่างกับหลักการเดิมที่ได้ให้ข้อสังเกตไปแล้ว โดยเน้นเทคนิคการตั้งคำถาม เพื่อหาคำตอบ และตั้งคำถามใหม่จากคำตอบนั้น ๆ จนบรรลุเป้าหมายการทำ CSA ตามที่ต้องการ ลักษณะการทำ CSA ที่จะกล่าวในวันนี้ จะเน้น Control – Based เป็นหลัก จากหลักการทำ CSA ซึ่งอาจมีได้หลายรูปแบบด้วยกันก็คือ Objective – Based, Risk – Based, Process Based, Situational Based หรือ Sceanario – Based สำหรับการทำ CSA ที่นอกเหนือจาก Control – Based จะนำมาเล่าสู่กันฟังในโอกาสต่อ ๆ ไป

แนวความคิดเพื่อสร้างความเข้าใจของกระบวนการทุจริตที่อาจเริ่มต้นจากกฎหมาย นโยบาย ++

แนวความคิดเพื่อสร้างความเข้าใจของกระบวนการทุจริตที่อาจเริ่มต้นจากกฎหมาย นโยบาย ++

คำถามบางประการในการทำ CSA แบบ Control – Based มีดังนี้

ระบบงานคอมพิวเตอร์ที่ควรทราบเบื้องต้น
– องค์กรใข้คอมพิวเตอร์ระบบ Centralize On-Line / ระบบรวมศูนย์ แบบOn-Line หรือระบบ Decentralize/ระบบกระจายศูนย์ (ซึ่งจะมีผลต่อกระบวนการทำงาน การบริหารความเสี่ยง การควบคุมภายในและ กระบวนการตรวจสอบที่แตกต่างกันไป +++ (อาจมีคำถามต่อเนื่องได้อีกมาก)

ผมมีข้อสังเกตเบื้องต้นว่า เมื่อระบบงานขององค์กรส่วนใหญ่ใช้คอมพิวเตอร์เข้าช่วยในการประมวลผล เช่น สถาบันการเงินหรือองค์กรใดก็ตามที่มีการประมวลผลโดยใช้คอมพิวเตอร์เป็นหลัก กระบวนการควบคุมต่างๆก็ใช้ระบบคอมพิวเตอร์เป็นหลัก หลักฐาน++ก็ล้วนเป็น Digital เป็นส่วนใหญ่ ซึ่งต้องการร่วมมือและประสานงาน อย่างใกล้ชิดระหว่าง IT Auditor & Non-IT Auditor ดังเช่นกรณีศึกษา ของการทุจริต VSRS

แนวความคิดและกระบวนการตรวจสอบเปลี่ยนแปลงไปอย่างสิ้นเชิงนั้น การตั้งคำถามเพื่อประเมินการควบคุมภายใน จากการบริหารความเสี่ยงอย่างเป็นกระบวนการ น่าจะได้ผลอย่างจำกัด ถ้าไม่มีความร่วมมืออย่างใกล้ชิด ระหว่าง IT Auditor & Non-IT Auditor อย่างเป็นกระบวนการและเข้าใจจริงของการตรวจสอบองค์กรที่ใช้คอมพิวเตอร์

ในวันนี้ผมจะยังไม่ลงรายละเอียดในเรื่อง Process Risk และ Technology Risk ซึ่งเกี่ยวข้องกับกับการรวบรวมข้อมูล และจุดอ่อนในการดำเนินงาน ที่ก่อให้เกิดการทุจริตต่างๆในวงการสถาบันการเงิน แต่จะให้ข้อสังเกตทั่ว ๆไป ที่น่าจะมีการสอบถามเพื่อการประเมินตนเอง / CSA เกี่ยวกับความพร้อมในระบบงานเพื่อป้องกันการทุจริต ซึ่งควรจะเริ่มต้นด้วยการทำ CSA ด้าน IT เสมอ!

– ระบบคอมพิวเตอร์ที่ใช้อยู่ในปัจจุบันมีความเสถียรเพียงใด หรืออยู่ระหว่างการปรับเปลี่ยน Core Banking System- CBS ที่ยังไม่เสถียรและมีปัญหา++++ (อาจมีคำถามต่อเนื่องได้อีกมากและมีผลต่อการประเมินความเสี่ยง การควบคุมภายใน หลักฐานและกระบวน การตรวจสอบตามมา)
-องค์กรมีนโยบายและบทลงโทษการทุจริต และมีการกำหนด Risk Appetite & Risk Tolerance จากการทุจริตภายในและภายนอกชัดเจน ถูกต้องตามหลักการ ERM
-มีหลักฐานการตรวจสอบการปฎิบัติตามนโยบาย และระเบียบข้อบังคับที่กำหนด
– องค์กรมีการทดสอบ ระเบียบห้ามพนักงานรับฝากสมุดคู่ฝากของลูกค้า และห้ามหรือให้ทำรายการถอนเงินโดยไม่มีสมุดคู่ฝากอย่างมีเงื่อนไข ที่ควบคุมได้โดยระบบ IT & Non-IT
– องค์กรมีระเบียบห้ามพนักงานทำรายการฝากถอนเงินแทนลูกค้า และมีระบบติดตาม
– องค์กรมีการติดตามและตรวจสอบ การกำหนดวงเงิน อำนาจ ในการทำรายการฝากถอน และโอนเงินของพนักงาน Teller อย่างเหมาะสม มีหลักฐานและรายงานชัดเจน
– องค์กรมีระเบียบปฏิบัติในการเปิดปิดเครื่อง Terminal การกำหนดช่วงเวลาในการเปิดปิดเครื่อง และการหยุดใช้งาน หรือเปลี่ยนแปลง Teller ประจำเครื่องระหว่างวัน
– องค์กรมีการทดสอบและตรวจสอบระเบียบการปฏิบัติงานเกี่ยวกับการใช้รหัสหรือบัตรผ่านแสดงตัวผู้ปฏิบัติงาน รหัสผ่านหรือรหัสอนุมัติรายการ รวมถึงกรณีมีการปฏิบัติงานทดแทนกัน เช่น ห้าม Authorize แจ้งรหัสผ่านให้ผู้อื่นทราบ และกำหนดให้เปลี่ยนรหัสที่เหมาะสม
– องค์กรมีการติดตามและตรวจสอบ การควบคุมเอกสารที่เกี่ยวกับเงินฝาก เช่น ใบคำขอเปิดบัญชี บัตรลายมือชื่อ ใบรับฝาก (NCD) สมุดคู่ฝากที่ยังไม่ได้ใช้อย่างรัดกุม โดยมีการกำหนดตัวผู้ดูแลรักษา เอกสารมีการ Running Number มีทะเบียนคุม มีการตรวจสอบบัญชีที่เปิดใหม่กับสมุดเงินฝากที่ถูกเบิกใช้ให้ตรงกันทุกวัน และตรวจนับสมุดคู่ฝากทุก 6 เดือน
– องค์กรมีระเบียบ หรือคำสั่ง ห้ามนำเอกสารที่เกี่ยวกับเงินฝากไปรับฝากนอกสถานที่ทำการเว้นแต่ได้รับอนุญาตจากผู้จัดการสาขาหรือผู้มีอำนาจที่เกี่ยวข้อง
– องค์กรจัดให้มีการติดตามและตรวจสอบ การทำรายการฝาก ถอนเงินสดหรือการโอนเงินเกินอำนาจ Teller ต้องมีผู้มีอำนาจอนุมัติรายการและต้องอนุมัติรายการด้วยตนเองไม่มีการให้ยืมบัตรผ่านรายการหรือบอกรหัสผ่านให้ทราบ รวมทั้งมีการกำหนดวงเงินสดที่ Teller สามารถถือครองได้ระหว่างวัน และมีหลักฐานรวมทั้งรายงานการตรวจสอบที่เกี่ยวข้อง
– องค์กรจัดให้มี การสุ่มบัญชีเงินฝากเพื่อส่งใบยืนยันยอดเงินฝากทุกประเภทเป็นครั้งคราว หรืออย่างน้อยทุก 6 เดือน
– องค์กรจัดให้มีการควบคุมและการตรวจสอบ การระเบียบวิธีปฏิบัติเกี่ยวกับบัญชีที่ขาดการติดต่อ (unclaim) ไว้อย่างรัดกุมชัดเจน และอยู่ในการควบคุมดูแลของเจ้าหน้าที่บริหาร
– การแก้ไขรายการ การปรับปรุงรายการต่าง ๆ เช่น การยกเลิกรายการฝากถอน ควรมีการตรวจทาน ควบคุมและได้รับการอนุมัติจากผู้มีอำนาจ รวมทั้งมีรายงานเพื่อควบคุมตรวจสอบรายการที่มีการแก้ไข และติดตามผลกระทบที่เกิดขึ้นจากการปฎิบัติดังกล่าว
– มีการตรวจสอบ การทำรายการโอนเงินถึงความถูกต้องของข้อมูลและเอกสาร รวมทั้งการอนุมัติรายการ หากมีรายการต้องสงสัย และมีระเบียบให้รายงาน ปปง.ทราบ
– องค์กรจัดให้มีมีระเบียบ วิธีปฏิบัติเกี่ยวกับการจัดเก็บเอกสารสำคัญของลูกค้าเงินฝาก เช่น ตัวอย่างลายมือชื่อ คำขอเปิดบัญชี ไว้ในที่ปลอดภัย รวมทั้งมีผู้รับผิดชอบ
– องค์กรจัดให้มีระเบียบปฏิบัติให้พนักงานแนะนำลูกค้าเงินฝากเกี่ยวกับความปลอดภัยของเงินฝากและเงินเบิกเกินบัญชี
– องคืกรมีข้อกำหนดเกี่ยวกับการเปิดบัญชีเงินฝากของพนักงาน และการควบคุมดูแล
– มีระเบียบ ห้ามเจ้าหน้าที่อื่นที่ไม่ใช่ Teller มาทำหน้าที่ รับ-จ่ายเงินกับลูกค้า
– มีการพิสูจน์ความถูกต้องของการทำรายการเงินฝากของ Teller แต่ละคน และเงินฝากรวมของสาขา ณ สิ้นวัน โดยมีหลักฐานและการรายงานอย่างเหมาะสม

ความเข้าใจและการรวบรวมข้อมูลที่เกี่ยวข้องกับสภาพแวดล้อมและองค์ประกอบของการตรวจสอบการทุจริต

ความเข้าใจและการรวบรวมข้อมูลที่เกี่ยวข้องกับสภาพแวดล้อมและองค์ประกอบของการตรวจสอบการทุจริต

– เงินฝากที่มีภาระการคำประกัน ควรอายัดทั้งเงินต้นและดอกเบี้ย และมีระบบงานรวมทั้งมีข้อมูลการอายัดชัดแจ้ง และ มีการจัดทำทะเบียนเงินฝากที่มีภาระอย่างรัดกุม

– การปลด (Hold)ภาระเงินฝาก ต้องมีกระบวนการตรวจสอบว่าปลอดภาระจริง โดยเฉพาะเงินฝากที่ค้ำประกันสินเชื่อ เจ้าหน้าที่สินเชื่อจะต้องทำการยกเลิกวงเงินสินเชื่อก่อน และมีหัวหน้าสินเชื่อตรวจสอบความถูกต้อง และต้องได้รับอนุมัติจากผู้จัดการสาขา
– มีการกำหนดหลักเกณฑ์และระบบงาน เงินฝากที่ค้ำประกันสินเชื่อเป็นการค้ำประกันทั้งบัญชีเพื่อไม่ให้มีการมาถอนส่วนที่ปลอดภาระในภายหลัง รวมทั้งจัดให้มีการรายงานอย่างเหมาะสม

– มีการกำหนดให้รายการที่มีนัยสำคัญหรือเกินอำนาจอนุมัติต้องผ่านการอนุมัติจากผู้จัดการสาขาหรือผู้รับมอบอำนาจอย่างเหมาะสม
– ผู้จัดการสาขามีระบบงานที่ใช้ในการติดตามการปฏิบัติงานของสาขาสำหรับรายการที่สำคัญต่าง ๆ ที่เพียงพอเช่น

– รายการที่ทำโดยผ่านรหัสของผู้จัดการสาขา
– รายการที่เกิดขึ้นหรือการเข้าระบบงาน (Sign on) หลังเวลาทำการ
– รายงานการปรับปรุงดอกเบี้ย
– รายงานการทำรายการที่เกินอำนาจ Teller
– รายงานการแก้ไขรายการ
– รายการฝากถอนเงินที่เกิน 1 ล้านหรือที่สำนักงานใหญ่หรือสาขาไม่เกินข้อ กำหนด

– มีการทดสอบกล้องวงจรปิดครอบคลุมจุดสำคัญของสาขา เช่น ห้องมั่นคง และมีการตรวจเช็คการทำงานของเครื่องอย่างสม่ำเสมอ รวมทั้งมีการเก็บบันทึกข้อมูลเป็นระยะเวลาที่กฎหมายกำหนด และรายงานผลอย่างเหมาะสม
– จัดให้มีการกำหนดผู้รับผิดชอบเปิดปิดสาขา และควบคุมการใช้สถานที่ทำงานนอกเวลาทำการและการเข้าถึงเครื่องรับ-ส่งข้อมูล

– สำนักงานใหญ่ควรดูแลสาขามีการตรวจสอบการปฏิบัติงานของสาขาไตรมาสละ 1 ครั้ง เพื่อตรวจสอบความถูกต้องครบถ้วนของเอกสาร และนิติกรรมสัญญาของการฝาก-ถอนเงิน การอนุมัติรายการ การแก้ไขรายการต่างๆ
– ต้องมีระบบการติดตามการปฏิบัติงานของผู้จัดการสาขา เช่น การตรวจสอบรายการที่มีนัยสำคัญ โดยเฉพาะรายการการโอนเงินไปยังบัญชีเดียวกันไม่ว่าภายในธนาคารเดียวกันหรือต่างธนาคาร
– องค์กรควรจัดให้ผู้ตรวจสอบ มีการ Surprise Check พนักงาน Teller ในการปฏิบัติตามระเบียบ

การเปลี่ยนแปลงกระบวนความคิดเพื่อหาหลักฐานการตรวจสอบในการสร้างคุณค่าเพิ่ม รวมทั้งการตรวจสอบการทุจริต

การเปลี่ยนแปลงกระบวนความคิดเพื่อหาหลักฐานการตรวจสอบในการสร้างคุณค่าเพิ่ม รวมทั้งการตรวจสอบการทุจริต

– องค์กรควรจัดให้มีการตรวจสอบการปฏิบัติงานของเจ้าหน้าที่เกี่ยวกับการฝากถอนเงินให้เป็นไปตามระเบียบที่กำหนดข้างต้น และติดตามรายงานประจำวันโดยใกล้ชิด เอาใจใส่จริงจัง
– ตรวจสอบความถูกต้องของข้อมูลและการควบคุมความครบถ้วนของเอกสารสัญญาที่เกี่ยวกับการเปิดบัญชี และการฝาก-ถอนเงิน
– ตรวจสอบการเบิกใช้สมุดคู่ฝาก รวมทั้งการเก็บรักษาสมุดคู่ฝากที่ยังไม่ใช้
– ตรวจสอบการปฏิบัติหน้าที่แทนกันตามหลักเกณฑ์ที่กำหนดไว้
– มีการระบุเรื่องการตรวจสอบบัญชีพนักงานอยู่ในขอบเขตการตรวจสอบ
– มีระบบงานตรวจจับรายการผิดปกติ ทั้งในระบบ Manual และระบบ Automated เช่น
– การทำรายการฝากถอนบัญชีของพนักงานสาขา
– การฝากและถอนเงินเป็นจำนวนใกล้เคียงกันในลูกค้ารายเดียวกันในวันเดียวกัน
– การฝาก ถอน โอนเงิน จำนวนสูงในบัญชี ซึ่งไม่เคยเกิดรายการลักษณะนี้
– การฝากและถอนเงินต่างสาขาหลายสาขา หรือ หลายครั้งในวันเดียวกัน
– การฝากเงิน ถอนเงิน และการโอนเงินที่มีความถี่ผิดปกติ
– การทำรายการนอกเวลาทำการ
– การกำหนดและจัดทำ Business Rules เพื่อป้องกันการทุจริตโดยอาศัย Logic
ที่อาจเกิดกิจกรรมที่เป็นช่องเปิดของจุดอ่อนและการทุจริต( Exposure )ได้
โดยติดตามพฎติกรรม จากการใฃ้ เครื่อง Terminal ของพนักงานและผู้บริหาร
ซึ่งควรรวมกิจกรรมที่ผิดกฎหมายและ Compliance ต่างๆ และส่งรายงานอย่าง
เป็น ระบบ ก่อนที่จะมีปัญหาเกิดขึ้น
– จัดให้มีการสอบทานการบันทึกบัญชี การจ่ายดอกเบี้ย การยืนยันยอด การกระทบยอดบัญชี
– จัดให้มีการตรวจสอบดอกเบี้ยจ่ายที่สูงผิดปกติ หรือค่าธรรมเนียมรับที่เกี่ยวกับเงินฝากที่ต่ำผิดปกติเมื่อเทียบกับช่วงเวลาที่ผ่านมา หรือไม่สัมพันธ์กับยอดเงินฝาก
– เมื่อพบการทุจริตได้มีการตรวจสอบรายการลักษณะเดียวกันทั้งระบบ ในกรณีที่องค์กรใช้ระบบ Centralize On-line ก็อาจสรุปได้ทันทีว่าสำนักงานหรือสาขาอื่น ก็มีโอกาสที่จะกระทำการทุจริตได้เช่นกัน เพราะใช้ระบบงาน และกระบวนการทำงานแบบเดียวกัน
– มีช่องทางการรับเรื่องร้องเรียนจากลูกค้า รวมทั้งช่องทางที่ให้พนักงานธนาคารชี้เบาะแส โดยไม่เปิดเผยชื่อผู้ร้องเรียน
– มีการกำหนดหน่วยงานที่ทำหน้าที่ติดตาม ตรวจสอบ ดูแลเรื่องร้องเรียนอย่างชัดเจน และมีกำหนดเวลาดำเนินการไว้ชัดเจน (จะได้นำเสนอโดยละเอียดต่อไป)
– มีการกำหนดให้มีการสับเปลี่ยนเจ้าหน้าที่ปฏิบัติงานระหว่างสาขา เช่นสับเปลี่ยนหมุนเวียนผู้จัดการสาขาทั่วประเทศ
– มีข้อบังคับให้เจ้าหน้าที่หยุดพักผ่อนต่อเนื่องตามจำนวนวันที่องค์กรกำหนด
– มีวิธีการดูแลความเป็นอยู่หรือพฤติกรรมของพนักงาน
– มีบุคคลที่ชำนาญการและมีประสบการณ์คอยให้คำแนะนำเจ้าหน้าที่อื่น
– การกำหนดหน้าที่ Teller แยกจากพนักงานการเงิน และผู้ทำหน้าที่เปิดบัญชี
– มีระเบียบปฏิบัติและการควบคุม เกี่ยวกับการทำงานผ่านระบบงานนอกเวลาทำการ
– มีการฝึกอบรมพนักงานให้มีความตื่นตัว มีความรู้ และมีส่วนร่วมในการป้องกันการทุจริต รวมทั้งให้เบาะแสเมื่อมีการปฏิบัติผิดปกติเกิดขึ้นในสาขา
– มีข้อกำหนดบทลงโทษพนักงานที่รู้เห็นการกระทำทุจริตแล้วไม่แจ้งเบาะแส แม้จะไม่มีส่วนเกี่ยวข้องกับการกระทำทุจริตนั้น
– ผู้ตรวจสอบควรมีความรู้ในการตรวจสอบ Log-file
– ควรมีการประสานงานการตรวจสอบระหว่าง IT Auditor และ Non-IT Auditor อย่างใกล้ชิด
– ควรตรวจสอบและดูแล การใฃ้ Super Password และ Super ID อย่างใกล้ชิดและด้วยความเข้าใจจริงถึงผลการใช้ รหัสพิเศษ ว่าทำให้องค์กรเสียหายได้อย่างคาดไม่ถึง

กรอบแนวการทำ CSA ดังกล่าวข้างต้น อาจใช้เป็นการประเมินตนเองเพื่อปรับปรุงการบริหารความเสี่ยงและการควบคุมภายในให้ดีขึ้นได้บางส่วน ทั้งก่อนและหลังจากที่องค์กรมีปัญหาได้ในทั้ง 2 กรณี ทั้งนี้ขึ้นกับวัตถุประสงค์ในการทำ Control Self Assessment – CSA และการทำ CSA ดังกล่าวก็มีประโยชน์กับทั้งผู้บริหาร และทั้งผู้ตรวจสอบภายในเป็นอย่างยิ่ง หากผู้อำนวยความสะดวก (Facilator) เข้าใจในกระบวนการบริหารความเสี่ยง การควบคุมภายในของหน่วยงานของตน ที่สัมพันธ์กับเป้าประสงค์และกลยุทธ์ระดับองค์กรเป็นอย่างดี มิฉะนั้นการทำ CSA ก็จะไม่ได้ผลเท่าที่ควร และจะมีปัญหาแบบลูกโซ่ต่อไปไม่มีที่สิ้นสุด

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

ในครั้งต่อไป ผมจะพูดถึงเรื่องการตรวจสอบการทุจริต หลังจากนั้นแล้วผมจะนำเสนอเรื่องวิธีการประเมินตนเองเพื่อการบริหารความเสี่ยงและการควบคุมภายใน (CSA – Control Self Assessment) ที่เป็นรายละเอียดมากขึ้น เพื่อนำไปสู่การปฏิบัติที่เป็นรูปธรรมได้ในที่สุด

 

การทุจริตของสถาบันการเงินต่าง ๆ โดยใช้ IT & Non – IT และการประเมินตนเอง(CSA)เพื่อการบริหารความเสี่ยง ของผู้บริหาร

ผมต้องขออภัยสำหรับผู้ที่ติดตามในหัวข้อนี้ เนื่องจากผมได้ update ข้อมูลไปเมื่อวันที่ 6 มิถุนายน 2552 และได้มีการปรับปรุงแก้ไขเนื้อหาเพียงเล็กน้อย ในวันที่ 7 มิถุนายน 2552 หลังจากทำการ post เนื้อหาขึ้นเว็บ ปรากฎว่าไม่พบเนื้อหาที่แก้ไข รวมถึงเนื้อหาเดิมก่อนทำการแก้ไขแล้ว ซึ่งผมเข้าใจว่าอาจเกิดปัญหาทางด้านเทคนิคบางประการ และเช้าวันนี้ ซึ่งเป็นวันที่ 8 มิถุนายน 2552 ก็ยังมีปัญหาใน Article นี้อยู่ ซึ่งผมจะพยายามดำเนินการต่อไปครับ