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

ตุลาคม 24, 2009

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

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

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

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

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

Leave a Comment » | IT Audit, Non - IT Audit / การตรวจสอบโดยทั่วไป | ติดป้ายกำกับ: , , , , , , , | ลิงก์ถาวร
โพสต์โดย Metha Suvanasarn

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

ตุลาคม 16, 2009

วันนี้ ท่านผู้ที่ติดตามในเรื่องการตรวจสอบ จะได้พบกับคำใหม่คำหนึ่ง ซึ่งผมพึ่งนำมาใช้ในการเขียนเกี่ยวกับการตรวจสอบ ก็คือ 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 อย่างมีนัยสำคัญ ตามที่กล่าวข้างต้น

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

1 ความเห็น | IT Audit, Non - IT Audit / การตรวจสอบโดยทั่วไป | ติดป้ายกำกับ: , , , , | ลิงก์ถาวร
โพสต์โดย Metha Suvanasarn

ความเข้าใจในกระบวนการตรวจสอบ กับการวางแผนการตรวจสอบ (ต่อ)

ตุลาคม 10, 2009

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

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

ในมุมมองดังกล่าวข้างต้น หากคณะกรรมการและผู้บริหารระดับสูง ยังไม่แน่ใจ หรือขาดความเชื่อมั่นในตนเอง ในระดับหนึ่ง ก็มักจะมอบหมายให้การนำเสนอเรื่องราวต่าง ๆ รวมทั้ง การวางแผนการตรวจสอบ (Audit Plan) เพื่อสนองตอบต่อ Stakeholders ในมุมมองของ Business Model ใหม่ เริ่มต้นในลักษณะ Bottom – Up ซึ่งจะได้ผลค่อนข้างจำกัด ในการสนองตอบต่อ Vision + Mission และกลยุทธ์ใหม่ขององค์กร เนื่องจาก พนักงานในระดับรอง ๆ ลงไป มีความเข้าใจในมุมมองระดับสูง และระดับกว้าง โดยเฉพาะระดับนโยบายขององค์กร หรือระดับประเทศที่แตกต่างกันค่อนข้างมาก

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

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

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

ขอให้ท่านผู้อ่านได้พิจารณาแผนภาพกระบวนการวางแผน และการตรวจสอบ ที่เกี่ยวข้องกับงานด้าน IT และมีผลโดยตรงต่อการประเมินความน่าเชื่อถือได้ของข้อมูล (Data) และสารสนเทศ (Information) ตามหลักการของ IT Governance และ CobiT v.4.1 ที่เน้นเรื่อง ความน่าเชื่อถือได้ของ Information เป็นสำคัญ เพราะมีผลต่อกระบวนการบริหาร ตามหลักการบริหารความเสี่ยงของ COSO – ERM ตามหลักการ S – O – F – C ที่ผมกล่าวถึงหลาย ๆ ครั้งมาแล้ว

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

การตรวจสอบระบบงานที่ใช้เทคโนโลยีสารสนเทศ

กาตรวจสอบระบบงานที่ใช้เทคโนโลยีสารสนเทศ

การตรวจสอบระบบงานที่ใช้เทคโนโลยีสารสนเทศ

คณะกรรมการตรวจสอบ ผู้ตรวจสอบ ผู้บริหาร และรับผิดชอบการบริหารความเสี่ยงทั่วทั้งองค์กร ที่ใช้หลัก COSO – ERM หากต้องการได้รับความมั่นใจอย่างสมเหตุสมผลของกระบวนการควบคุมภายใน และการตรวจสอบตามฐานความเสี่ยง เพื่อให้การบรรลุวัตถุประสงค์ระดับองค์กร และระดับสายงาน ประสบความสำเร็จดังที่ตั้งใจไว้ และเป็นไปตาม Vision + Mission + Policy + Strategy + Action Plan + KPI ที่เกี่ยวข้อง ในมุมมองต่าง ๆ โดยเฉพาะอย่างยิ่ง มุมมองของการสอดประสานและบูรณาการ ตามหลักการ GRC หากเข้าใจและมั่นใจกระบวนการติดตามผลของคณะกรรมการและผู้บริหารระดับต่าง ๆ รวมทั้งการตรวจสอบภายใน ซึ่งรวม ๆ แล้วอาจจะเรียกว่า Assurance แล้วละก็ คงจะสบายใจได้ขึ้นมาก ว่าองค์กรสามารถก้าวสู่การบรรลุวัตถุประสงค์ หากได้รับผลการตรวจสอบที่น่าเชื่อถือได้ จากผู้ตรวจสอบที่มีศักยภาพที่เข้าใจความต้องการของ Stakeholders ในมุมมองต่าง ๆ และมีการวางแผนการตรวจสอบได้ตรงกับวัตถุประสงค์ที่ Stakeholders ต้องการในมุมมองที่เกี่ยวข้อง

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

Leave a Comment » | IT Audit, Non - IT Audit / การตรวจสอบโดยทั่วไป | ติดป้ายกำกับ: , , , , , | ลิงก์ถาวร
โพสต์โดย Metha Suvanasarn

ขั้นตอนในการวางแผนการตรวจสอบ เพื่อสร้างคุณค่าเพิ่มให้กับองค์กร โดยรวม ภายใต้สภาพแวดล้อมปัจจุบัน

ตุลาคม 5, 2009

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

1. ระบุความต้องการของฝ่ายบริหาร เพื่อสร้างคุณค่าเพิ่มให้กับ Stakeholders ในมุมมองของ หัวหน้าผู้ตรวจสอบ และฝ่ายตรวจสอบภายในขององค์กร ก็คือ การพิจารณาว่า คณะกรรมการและฝ่ายบริหารขององค์กร ต้องการสร้างคุณค่าเพิ่มให้กับ Stakeholders ในมุมมองใดบ้าง

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

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

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

4. เชื่อมโยงความเสี่ยงทางด้านการตรวจสอบ ที่มาจากฝ่ายจัดการ จากการบริหารความเสี่ยงที่ไม่ได้ผล โดยเฉพาะอย่างยิ่ง ความเสี่ยงจากการที่ข้อมูลและสารสนเทศ เชื่อถือได้ในระดับจำกัด ให้เข้ากับการวางแผนการตรวจสอบ ทางด้าน IT และ Non – IT

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

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

7. ให้ระบุกระบวนการในการประมวลข้อมูลที่ขาดประสิทธิภาพในการดำเนินงาน (Inefficient Processes) ที่มีอยู่ ภายใต้สถานการณ์การควบคุมที่เป็นปัจจุบัน ที่จำเป็นต้องเปลี่ยนแปลง หรืออาจต้องเปลี่ยนแปลงให้เหมาะสมกับสภาพแวดล้อม ที่มาจากภายนอกและภายในองค์กร

8. ประเมินความเสี่ยงจากการบริหารและการจัดการ ที่อาจมองข้ามจุดอ่อนของการควบคุมกิจกรรม และกระบวนการทำงาน ที่มาจากระบบคอมพิวเตอร์ ทั้งทางด้าน General Control และ Application Control และจุดอ่อนจากกระบวนการบริหารความเสี่ยงเชิงรุก ที่ไม่อาจนำหลักการบริหารความเสี่ยงทั่วทั้งองค์กร (COSO – ERM) มาใช้ได้อย่างมีประสิทธิผลและประสิทธิภาพ

9. ทบทวนและสอบทานจุดอ่อนจากบทเรียนขององค์กรอื่น ๆ ภายใต้สภาพแวดล้อมที่เกี่ยวข้องกับทางด้านเทคโนโลยีสารสนเทศและการจัดการที่ดี อย่างเช่น การนำบทเรียนกรณีทุจริตของธนาคาร Socgen ซึ่งเป็นธนาคารใหญ่ที่สุดเป็นอันดับ 2 ของประเทศฝรั่งเศส และเสียหายจากการทุจริตและการดำเนินงาน เป็นเงินประมาณ 4 แสนล้านบาท จากการทุจริตของคน ๆ เดียว และกรณีทุจริตต่าง ๆ ที่เกิดจาก คน + กระบวนการดำเนินงาน + เทคโนโลยี ซึ่งรวม ๆ เรียกว่า ความเสี่ยงในการดำเนินงาน หรือ PPT – People – Process – Technology และพิจารณาวางแผนการตรวจสอบ เพื่อปิด Gap ต่าง ๆ ที่อาจจะเกิดขึ้นจาก Lesson Learned จากกรณีของต่างประเทศ และภายในประเทศที่ได้เกิดขึ้นแล้ว เพื่อไม่ให้เกิดซ้ำอีกในองค์กรของเรา

10. พิจารณาในภาพโดยรวม จากปัจจัยต่าง ๆ ที่กล่าวข้างต้น รวมทั้ง แนวทางเพื่อลดต้นทุนภายในองค์กรที่อาจจะเกิดจากจุดอ่อน จากการละเลยมิได้มีการพิจารณานำหลักการของ GRC – Governance, Risk, Compliance ที่เป็นแนวการปฏิบัติที่ดี ภายใต้กรอบ CG และ ITG ซึ่งเป็นการบริหารและขับเคลื่อนในลักษณะ Integrity – Driven Performance ซึ่งจะช่วยลดต้นทุนในการดำเนินงาน และสร้างคุณค่าเพิ่มให้กับผู้มีผลประโยชน์ร่วม (Stakeholders) ได้เป็นอย่างดี

11. ประเมินศัยกภาพ (Competency) ของทรัพยากรภายในองค์กร โดยเฉพาะอย่างยิ่ง ภายในสายงานการตรวจสอบ ทางด้าน IT และ Non – IT ถึงความพร้อมในการปฏิบัติงานตรวจสอบ ให้ได้มาตรฐาน และสัมพันธ์กับความก้าวหน้าทางด้านเทคโนโลยีสารสนเทศ ที่พัฒนาไปอย่างรวดเร็ว และมีผลกระทบโดยตรงต่อความเสี่ยงที่จะก้าวไปสู่ความสำเร็จตามเป้าประสงค์ ตามหลักการของ Balanced Scorecard และกลยุทธ์ที่เกี่ยวข้องทั้ง 4 มุมมอง

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

สำหรับการปฏิบัติการตรวจสอบจริง ก็ควรพิจารณามุมมองในการสร้างคุณค่าเพิ่มให้กับ Stakeholders ที่ครอบคลุมหัวข้อต่าง ๆ ทั้งทางด้าน IT และ Non – IT ตามแผนภาพที่ได้แสดงไว้ข้างต้น และให้คำแนะนำที่เหมาะสมกับการจัดการตามมาตรฐานการตรวจสอบที่เกี่ยวข้อง และเป็นไปได้ต่อไป

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

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

สรุปอีกครั้งก็คือ คณะกรรมการและผู้บริหารขององค์กรต่าง ๆ ควรประเมินช่องว่างระหว่างศักยภาพของบุคลากร ที่ควรมีความรู้ขั้นต่ำที่จำเป็น ให้ได้มุมมองจาก IT Risks ที่มีผลต่อ Business Risks อย่างสำคัญ ซึ่ง C – Level ในระดับต่าง ๆ ควรเข้าใจผลกระทบต่อเทคโนโลยีที่สามารถระบุความเสี่ยงในมุมมองของงานที่ตนเองรับผิดชอบโดยตรง และจากมุมมองที่มีผลกระทบจากสายงานอื่น ๆ ที่เกี่ยวข้อง (Impact Risk) ที่ต้องร่วมด้วยช่วยกันในการบริหารแบบบูรณาการ จากจิตสำนึก (Conscience) ความรับผิดชอบ (Acountability) ในการบริหารงานที่พิจารณาจากกระบวนการทำงาน และผลลัพธ์ที่มีต่อองค์กรเป็นสำคัญ

Leave a Comment » | IT Audit, Non - IT Audit / การตรวจสอบโดยทั่วไป | ติดป้ายกำกับ: , , , | ลิงก์ถาวร
โพสต์โดย Metha Suvanasarn

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

กันยายน 21, 2009

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

ภายหลังเกิดการทุจริต ธนาคารได้ดำเนินการปรับปรุงการทำงานในด้านต่าง ๆ เพื่อป้องกันสาเหตุที่ก่อให้เกิดการทุจริต ซึ่งสามารถจัดกลุ่มได้ดังนี้

กลุ่มกำหนดระบบรักษาความปลอดภัยของระบบ
1. การใช้ MENU HXFER, TRTRAN, TM ทำงานกำหนดให้พนักงานที่มี Work Class ตั้งแต่เกรด 9 ขึ้นไป จึงจะทำรายการได้ 1 คน ทำหน้าที่บันทึกและอีก 1 คน ทำหน้าที่ Verify ขณะนี้อยู่ระหว่าง Set Up และทดสอบระบบเพื่อป้องกันการเข้าถึงหัวบัญชีของ GL ประเภทรายได้และค่าใช้จ่าย

2. ปรับปรุงวงเงิน เงินฝาก ถอน รายการโอน เคลียริ่ง และยอดเงินสะสมคงเหลือในมือของ Teller ระดับต่าง ๆ ใหม่ ให้มีวงเงินที่ลดลงจากเดิม

3. การทำรายการเกิน Limit ตามข้อ 2 ต้องมีการ Override รายงานโดยพนักงานเกรด 9 ขึ้นไป

4. ปรับปรุงการทำงานบันทึกรายการด้วย MENU HXFER และ TM (Transaction Maintenance) โดยกำหนดให้มีระบบควบคุมการทำรายการมี Marker Checker ทุกครั้งที่ทำรายการ

5. กำหนดหัวบัญชี GL ที่สำคัญให้เป็นหน้าที่ของ Checker ซึ่งเป็นพนักงานเกรด 9 ขึ้นไป ที่จะทำการ Post transaction เท่านั้น

กลุ่มปรับปรุงกระบวนการทำงาน
1. การหมุนเวียนพนักงานสาขาหลักไปทำงานที่ Booth/oss/สาขาย่อย สาขาหลักจะต้องทำแผนล่วงหน้า 1 เดือน ส่งให้ฝ่ายงานต้นสังกัดอนุมัติและส่งให้ CORE TEAM เพื่อปรับ Work Class

2. การขอสร้างเปลี่ยนแปลง/แก้ไข หรือยกเลิกรหัสผู้ใช้งานเพื่อเข้าสู่ระบบ CBS กำหนดให้ ผอ.ฝ่าย/สำนัก เป็นผู้อนุมัติตามแบบฟอร์มที่กำหนด

3. การปรับปรุงกระบวนงานปฏิบัติงานของสาขาทั้งหมด โดยแต่งตั้งคณะกรรมการกำหนดกระบวนงานปฏิบัติสาขา และคณะทำงานกระบวนการปฏิบัติงานสาขา อีก 3 คณะ เพื่อดำเนินการปรับปรุง งานการเงินสาขา งานบัญชีสาขา และงานสินเชื่อสาขา

กลุ่มการปรับปรุงรายงานและผลการตรวจสอบ
1. การตรวจสอบรายละเอียดของรายการที่ทำไปแล้ว กำหนดให้ USER ใช้เมนู TI (Transaction Inquiry) ตรวจสอบรายละเอียดของรายการ

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

กลุ่มปรับปรุงระเบียบปฏิบัติงานและการอบรม
1. ธนาคารได้ปรับปรุงระเบียบปฏิบัติงานด้านการเงิน ซึ่งประกอบด้วยระบบเงินฝาก การกำหนดวงเงินรับจ่ายของสำนักงานพระราม 9 และสาขา การกำหนดวงเงินสดในเมือเกินอำนาจอนุมัติของพนักงาน การใช้เมนู TM และ MENU HXFER

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

คณะกรรมการสอบสวนสรุปไว้อย่างน่าสนใจว่า จะเห็นว่าการปรับปรุงข้างต้นเป็นการสะท้อนให้เห็นถึงปัญหาข้อบกพร่อง และความไม่พร้อมของระบบคอร์แบงกิ้ง (Core Banking System : CBS) อันเป็นสาเหตุของการทุจริตที่เกิดขึ้น ซึ่งสอดคล้องกับสาเหตุที่คณะกรรมการสอบสวนข้อเท็จจริงสรุป

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

Leave a Comment » | IT Audit, Non - IT Audit / การตรวจสอบโดยทั่วไป | ติดป้ายกำกับ: , , , , | ลิงก์ถาวร
โพสต์โดย Metha Suvanasarn

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

กันยายน 5, 2009

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

Leave a Comment » | IT Audit, Non - IT Audit / การตรวจสอบโดยทั่วไป | ติดป้ายกำกับ: , , , , | ลิงก์ถาวร
โพสต์โดย Metha Suvanasarn

ผลการสอบทุจริต “ธอส.” และข้อสังเกตในการบริหารความเสี่ยงเมื่อเทียบกับความเสียหายที่เกิดขึ้น ในบางมุมมอง

สิงหาคม 15, 2009

ก่อนผลการสอบข้อเท็จจริงกรณีการทุจริตที่ ธอส. จะเปิดเผยทางสื่อมวลชน ผมได้เคยกล่าวถึงกรณีทุจริตที่ ธอส. โดยกล่าวถึงหลักการกว้าง ๆ ว่า การทุจริตทุกประเภทมีเพียง 3 ประเด็นเท่านั้นที่ให้พิจารณา ก็คือ คน + กระบวนการทำงาน + เทคโนโลยี ที่ใช้คำย่อ ๆ ว่า PPT – People – Process – Technology

การประเมินตนเองของผู้บริหารในมุมมองของการควบคุม Operational Risk และ Business Risk

การประเมินตนเองของผู้บริหารในมุมมองของการควบคุม Operational Risk และ Business Risk

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

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

วิวัฒนาการจากมุมมองของ Operational Risk พัฒนาสู่ Business Risk ที่เชื่อมต่อเข้ากับการ Design และการกำหนด Strategy ที่ต้องเข้าใจถึง Culture และการบริหารทางด้าน Architecture ระหว่าง PPT กับ Design/Strategy

วิวัฒนาการจากมุมมองของ Operational Risk พัฒนาสู่ Business Risk ที่เชื่อมต่อเข้ากับการ Design และการกำหนด Strategy ที่ต้องเข้าใจถึง Culture และการบริหารทางด้าน Architecture ระหว่าง PPT กับ Design/Strategy

คณะกรรมการสอบสวนกรณีการทุจริต ของ ธอส. อาจใช้ Model ดังกล่าวในการไต่สวนหาข้อมูล และสารสนเทศในส่วนที่เกี่ยวข้องกับ PPT + Strategy ตามแผนภาพข้างต้น โดยนำปัจจัยต่าง ๆ ตามที่ปรากฎในการเชื่อมโยง 4 ประเด็นหลัก ๆ ซึ่งจะเกี่ยวข้องกับการบริหาร Operational Risk และการบริหารองค์กร แบบสอดประสานและบูรณาการ ตามองค์ประกอบหลักที่เกี่ยวข้องที่เชื่อมโยงด้วยการบริหารความเสี่ยงที่เกี่ยวเนื่อง คือ การหลอมรวม (Emergence) การบริหารความเสี่ยงในทุกมุมมองที่เกี่ยวข้องกับ S-O-F-C และ การบริหารทรัพยากรบุคคล และกลไกหรือตัวขับเคลื่อน รวมทั้งการสนับสนุนด้านเทคโนโลยีสารสนเทศที่มีประสิทธิภาพ

ตามที่กล่าวข้างต้นคือภาพแรกของ PPT ที่เกี่ยวข้องกับการบริหาร Emergence, Human Factors and Enabling & Support อย่างสอดประสานและเป็นบูรณาการ ซึ่งในแต่ละองค์ประกอบหลักและองค์ประกอบย่อย จะมีกิจกรรมต่าง ๆ ที่เกี่ยวข้องและสัมพันธ์กันอย่างมกาในการขับเคลื่อนความสำเร็จ เพื่อก้าวไปสู่การมีประสิทธิภาพและประสิทธิผลของการดำเนินงานขององค์กร และถ้าตรงกันข้ามก็คือ ความเสี่ยงที่อาจก่อให้เกิดความเสียหายและก่อให้เกิดการทุจริตในองค์กรได้

จากรูปภาพที่ 2 ท่านผู้ที่สนใจในเรื่องการบริหารความเสี่ยง ซึ่งเป็นส่วนหนึ่งในการขับเคลื่อน CG + ITG และเป็นองค์ประกอบหลักของ GRC ที่ผมเคยเล่าสู่กันฟังสั้น ๆ ไปแล้วก่อนหน้านี้หลายตอนนั้น ท่านกำลังจะเห็นคุณค่าจากความเข้าใจในการบริหารภายใต้ร่มของการกำกับดูแลกิจการที่ดี ควบคู่กันไปกับการบริหารสารสนเทศเพื่อการจัดการที่ดี ที่สามารถสร้างความเชื่อมั่น สร้างความน่าเชื่อถือให้กับผู้มีผลประโยชน์ร่วม (Stakeholders) อย่างกว้างขวาง นี่คือ Value Creation ของกระบวนการจัดการที่ทุกองค์กรสามารถก้าวไปสู่จุดนี้ได้อย่างมั่นใจ หากองค์กรของท่านมีความเข้าใจในกระบวนการบริหารความเสี่ยง ทั้งทางด้าน IT และ Non – IT ที่สามารถวัดคุณค่าเพิ่มได้จาก Intangible Assets และ Tangible Assets ซึ่งนับวันคุณค่าเพิ่มจากการบริหาร Intangible Assets จะมีบทบาทเพิ่มขึ้นอย่างมากในทุกองค์กร ขณะเดียวกันก็สร้างจุดอ่อนเป็นอย่างยิ่งให้กับหลายองค์กรที่ขาดความพร้อมทางด้านการบริหารและการจัดการ PPT อย่างแท้จริง

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

จากแผนภาพที่ 2 ซึ่งเชื่อมโยงกระบวนการบริหารจัดการด้าน PPT ไปสู่กระบวนการออกแบบระบบ และการกำหนดกลยุทธ์ขององค์กรที่มีความเกี่ยวข้องกับข้อสังเกตของคณะกรรมการตรวจสอบข้อเท็จจริงของ ธอส. เป็นอย่างมาก ถึงกรณีระบบ CBS – Core Banking System ที่มีกระบวนการทำงาน (Process) ที่มีจุดอ่อนหลายประการผสมผสานกับบุคลากรที่ไม่จงรักภักดีต่อองค์กร รวมทั้งกระบวนการบริหารขององค์กรที่น่าจะปรับปรุงได้หลายประการนั้นเป็นต้นเหตุสำคัญ (Root Cause) ของการทุจริตใน ธอส. ทั้งสิ้น

จากแผนภาพข้างต้น หากทำเป็นกรณีศึกษา (Case Study) ก็จะพบประเด็นต่าง ๆ ที่มีกระบวนการบริหารความเสี่ยงที่ขาดดุลยภาพและคุณภาพในการจัดการ ตามหลักการของ COSO – ERM หลายประการ

ขอได้โปรดติดตาม ผลสอบการทุจริต กรณียักยอกเงิน 500 ล้านบาท ของ ธอส. ในตอนต่อไปนะครับ

Leave a Comment » | IT Audit, Non - IT Audit / การตรวจสอบโดยทั่วไป | ติดป้ายกำกับ: , , , , | ลิงก์ถาวร
โพสต์โดย Metha Suvanasarn

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

กรกฎาคม 21, 2009

ครั้งที่แล้วผมได้นำเสนอกรอบการตรวจสอบเรื่องการทุจริต และตั้งใจว่าจะตามด้วยสัญญาเตือนภัยของเหตุการณ์ที่อาจก่อให้เกิดการทุจริต (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 ความเห็น | IT Audit, Non - IT Audit / การตรวจสอบโดยทั่วไป | ติดป้ายกำกับ: , , , , , , , , , , , , , | ลิงก์ถาวร
โพสต์โดย Metha Suvanasarn

เว็บใหม่ itgthailand.com

กรกฎาคม 21, 2009

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

ทุกท่านที่ติดตามเนื้อหา สาระ ข้อมูลความรู้ในหัวข้อต่าง ๆ ของ http://www.itgthailand.wordpress.com แห่งนี้ สามารถเข้าชมและติดตามเนื้อหาตอนต่อ ๆ ไปได้ใน http://www.itgthailand.com หรือคลิก link http://www.itgthailand.com ตั้งแต่วันนี้ (8 กรกฎาคม 2552) เป็นต้นไปครับ

Leave a Comment » | การดำเนินงานและการตรวจสอบสถาบันการเงินด้านคอมพิวเตอร์, แนวทางการบริหารความเสี่ยงทั่วทั้งองค์กร COSO-ERM Framework, CG & ITG & GRC และองค์ประกอบที่เกี่ยวข้อง, COSO-ERM กับ ITG และ GRC กับการวิเคราะห์เพื่อสร้างสรรสาระ, IT Audit, Non - IT Audit / การตรวจสอบโดยทั่วไป | ลิงก์ถาวร
โพสต์โดย Metha Suvanasarn

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

กรกฎาคม 11, 2009

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

การจัดการ/การควบคุมบางประการ
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) ให้จัดทำเอกสารประกอบระบบงานโดยละเอียดทั้งหมด

Leave a Comment » | IT Audit, Non - IT Audit / การตรวจสอบโดยทั่วไป | ติดป้ายกำกับ: , , , , | ลิงก์ถาวร
โพสต์โดย Metha Suvanasarn

กลับไปหน้าที่แล้ว
รายการถัดไป »