ความเสี่ยงกับมุมมองของการติดตามของผู้บริหาร และการตรวจสอบ – ด้านกลยุทธ์ ตอน 2

กุมภาพันธ์ 6, 2011

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

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

Strategic Risk

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

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

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

ทั้งนี้ เพื่อที่จะสามารถแก้ไขปัญหาได้ทันท่วงทีก่อนที่เกิดความเสียหายหรือความเสียหายลุกลามจนยากแก่การควบคุม

Strategic Risk Management

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

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

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


ความเสี่ยงกับมุมมองของการติดตามของผู้บริหาร และการตรวจสอบ – ด้านกลยุทธ์ ตอน 1

มกราคม 20, 2011

ผมไม่ได้เขียนคอลัมน์นี้มานาน วันนี้ผมจะมาเล่าเรื่องที่เกี่ยวข้องกับการบริหารความเสี่ยงในอีกมุมมองหนึ่งก็คือ การตรวจสอบความเสี่ยง ซึ่งมีหลายมุมมองที่เกี่ยวข้อง ไม่ว่าจะในมุมมองของ COSO – ERM หรือมุมมองของ ความเสี่ยง 5 – 7 ด้านของ ธปท. ทั้งนี้ไม่รวมหัวข้อที่เกี่ยวข้องกับ IT Audit และ Integrated Audit รวมทั้งมุมมองการตรวจสอบความเสี่ยงด้าน CobiT ซึ่งจะหนักไปทาง IT Audit นะครับ

ท่านผู้อ่านครับ มาถึงช่วงต้นเดือนมกราคม 2554 และนับต่อจากนี้เป็นต้นไป ท่านคงจะได้ยินและได้อ่านเรื่องเกี่ยวกับ GRC – Governance + Risk Management + Compliance มากขึ้น ในวงการบริหารและปฏิบัติงานยุคใหม่ กระบวนการบริหารต่าง ๆ มีความสัมพันธ์กันอย่างแยกกันไม่ได้ โดยเฉพาะอย่างยิ่งทางด้านเทคโนโลยีสารสนเทศ และการบริหารธุรกิจในระดับต่าง ๆ ของทุกองค์กร

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

GRC และการจัดการ

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

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

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

แนวการตรวจสอบความเสี่ยงนั้น มีวัตถุประสงค์ เพื่อให้ผู้บริหารและผู้ตรวจสอบใช้เป็นข้อสังเกตเบื้องต้น และใช้เป็นแนวทางในการติดตาม (Monitoring) และตรวจสอบ (Audit – Assurance/Consoulting) และประเมินความเสี่ยงด้านกลยุทธ์ และด้านอื่น ๆ ที่เกี่ยวข้อง ตามเป้าประสงค์ของการบริหารความเสี่ยงในแต่ละองค์เป็นสำคัญ และ

เพื่อให้มั่นใจว่าองค์กรมีระบบการบริหารความเสี่ยงที่ใช้ในการระบุ วัด ติดตาม และควบคุมความเสี่ยงต่าง ๆ อย่างเพียงพอ ทั้งกำหนดหน้าที่และความรับผิดชอบ ในการจัดให้มีระบบการบริหารความเสี่ยงที่เหมาะสมกับปริมาณ ความซับซ้อนของระบบงาน โครงสร้างขององค์กร และสภาพแวดล้อมต่าง ๆ ที่เกี่ยวข้อง ทั้งนี้เพราะ ความเสี่ยงด้านกลยุทธ์จะมีผลกระทบอย่างกว้างขวางต่อผลสำเร็จของการบริหารในทุกมุมมองของการจัดการ โดยเฉพาะอย่างยิ่ง ความเสี่ยงทางด้านการดำเนินงาน (Operational Risk) ที่เกี่ยวข้องกับ P + P + T และการบริหารโครงการ / แผนงานต่าง ๆ ขององค์กร

ความสำเร็จในการติดตามและตรวจสอบ ต้องอาศัยความรู้เกี่ยวกับธุรกรรมขององค์กร และลักษณะที่แตกต่างของธุรกิจ สภาพแวดล้อม และวัฒนธรรมขององค์กรที่เกี่ยวข้องกับการดำเนินธุรกิจ แนวทางในการบริหารความเสี่ยง รวมทั้งพัฒนาการของวิธีการ / เครื่องมือบริหาร ความเสี่ยง และทักษะในการประเมินผลกระทบจากความเสี่ยงเหล่านั้นในลักษณะบูรณาการ (integrated) ภายใต้ร่มของ GRC

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

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


Integrated Auditors and Management ตอน 2

มกราคม 5, 2011

จากครั้งที่แล้ว ผมได้พูดถึงเรื่องของ Integrated Auditors and Management ซึ่งยังพูดคุยกันค้างไว้อยู่ และในวันนี้เราจะมาคุยกันต่อ ถึงแม้บทบาทของคอมพิวเตอร์ และระบบอัตโนมัติจะมีความสำคัญยิ่งยวดเพียงใด และนับวันช่องว่างระหว่าง Technology Computer กับศักยภาพหรือ Competency ของบุคลากร ในระดับบริหารจนถึงระดับปฏิบัติการ มีช่องว่างเพิ่มขึ้นตามลำดับ นี่คือความเสี่ยงที่มีนัยสำคัญยิ่ง และมีผลสำคัญมากต่อกระบวนการตัดสินใจที่มีประสิทธิภาพ และประสิทธิผลในการดำเนินงานที่แท้จริง ที่หลายองค์กรยังต้องการความเข้าใจอย่างลึกซึ้งถึงผลกระทบต่อ IT Risk ที่มีผลต่อ Business Risk และกระบวนการตัดสินใจของผู้บริหารในภาพโดยรวม

ผู้บริหารของหลายองค์กรส่วนใหญ่ มักจะมีความเข้าใจคลาดเคลื่อนว่า เรื่องของเทคโนโลยี การควบคุมทางเทคโนโลยี และการจัดการทางด้านเทคโนโลยี เป็นของ CIO – Chief Information Officer จึงมีการมอบหมายงานสำคัญ ๆ ในการตัดสินใจไปยัง CIO และ CIO เกือบทั้งหมดก็มอบความไว้วางใจต่อ ๆ ไปยังผู้ใต้บังคับบัญชา รวมทั้ง Outsource ที่เกี่ยวข้อง ซึ่งเพิ่มความเสี่ยงในกระบวนการตัดสินใจ อันเกิดจากผลกระทบของ IT Risk ซึ่งมีผลต่อ Enterprise Risk Management อย่างสำคัญยิ่ง ทั้ง ๆ ที่เรื่องนี้เป็นความรับผิดและความรับชอบ ซึ่งเรียกสั้น ๆ ว่าเป็น Accountability ของผู้บริหารระดับสูงสุด รวมถึงคณะกรรมการที่จะต้องกำหนดนโยบายในเรื่องที่เกี่ยวข้องกับ การบริหารความเสี่ยง ทั้งทางด้าน IT และ Non – IT ในภาพโดยรวมให้เป็นภาพเดียวกัน มิใช่เพียงมาเชื่อมกัน หรือ นำมาต่อกันในภายหลัง+++ เท่านั้น

มาตรฐานการปฏิบัติงานทางด้านคอมพิวเตอร์ หรือเทคโนโลยีสารสนเทศทางการสื่อสาร (ICT) ที่เป็นสากล หรือที่เป็น Best Practice หรือ Good Practice ได้ถูกนำมาใช้ หรือถูกนำมาบังคับใช้อย่างหลีกเลี่ยงไม่ได้ และในกรณีที่การปฏิบัติงานไม่มีกรอบ Standard หรือ Best Practice ในเรื่องที่เกี่ยวข้อง ก็ต้องนำ Guideline ในเรื่องนั้น ๆ มาใช้ในทางปฏิบัติ เพื่อให้เกิดการยอมรับต่อผู้มีผลประโยชน์ร่วม (Stakeholders) ทั้งภายในและต่างประเทศ

Integrated Thinking แนวคิด หรือการคิดให้ครบจนจบความ / ครบถ้วน ความคิดให้กว้างอย่างสร้างสรรค์ (Creative Thinking) การคิดให้ลึกเชิงวิเคราะห์ (Analytical Thinking) เพื่อให้เกิดความเข้าใจโดยรวมของทั้งระบบ (System Thinking) เพื่อก้าวสู่เป้าหมาย-วัตถุประสงค์อย่างเป็นระบบเพื่อการจัดการที่ดี (Systematic Thinking Approach) เพื่อให้เกิดความสมบูรณ์ ความครบถ้วน ความถูกต้อง ที่จะนำไปสู่ประสิทธิภาพและประสิทธิผลในการดำเนินงาน และยกระดับการแข่งขัน จึงเป็นเรื่องที่จำเป็นอย่างยิ่งของการบริหารองค์กรยุคใหม่ ที่นำไปสู่หลักการที่นำไปสู่กระบวนการบริหารที่รวมเป็นชุด ที่มีความสัมพันธ์กันและกันในองค์ประกอบหลักการบริหารด้านการกำกับดูแลกิจการที่ดี (Governance – CG + ITG) การบริหารความเสี่ยงระดับองค์กร (Risk หรือ ERM) และการปฏิบัติตามกฎเกณฑ์ และกติกาสังคม ทั้งในระดับประเทศ และระหว่างประเทศ (Compliance) เพื่อสร้างความพึงพอใจให้กับผู้มีผลประโยชน์ร่วม (Stakeholders) ทั้งในระยะสั้นและระยะยาว ที่เรียกว่า GRC จึงเกิดขึ้น และเป็นแนวการบริหารยุคใหม่ล่าสุดที่จะยั่งยืนไปอีกนานแสนนาน

อย่างไรก็ดี การก้าวสู่กระบวนขับเคลื่อนการบริหารที่เน้น “กระบวนการ” หรือ “Process” ที่หลอมรวมการบริหาร PPT หรือ People + Process + Technology ที่เน้น Operational Management และเป็น Core Function ในการผลักดันองค์กรไปสู่ Integrity – Driven Performance ภายใต้องค์ประกอบหลัก GRC เพื่อตอบสนองความต้องการของผู้มีผลประโยชน์ร่วมอย่างผสมผสานเป็นหนึ่งเดียวของธุรกิจนั้น จะเป็นสุดยอดของกระบวนการบริหารการจัดการ ที่องค์กรชั้นนำของโลกได้นำมาใช้ในการบริหารในปัจจุบัน และผู้กำกับ (Regulators) ได้นำกรอบแนวคิดนี้ไปใช้กับผู้ปฏิบัติ (Operators) ในองค์กรที่เกี่ยวข้อง เพื่อให้เกิดประสิทธิภาพการบริหารและการจัดการที่ดี เพื่อก้าวไปสู่ Corporate Governance หรือบรรษัทภิบาลที่เป็นรูปธรรม +++

ก่อนการก้าวสู่ GRC ตามวรรคต้น แนวความคิดในเรื่อง Integrated Thinking โดยการคิดให้ครบจนจนความ โดยดูเป้าประสงค์สุดท้ายที่ใช้กรอบ Business Balanced Scorecard เชื่อมโยงกับ Information Balanced Scorecard จะเป็นขั้นตอนแรก ๆ ขององค์กรส่วนใหญ่ ซึ่งจะกำหนดเป็นนโยบายและแนวปฏิบัติที่ชัดเจน ของการผสมผสานการบริหาร การจัดการของ Business Objectives และ IT Objectives เป็นหนึ่งเดียวหรือภายใต้ร่มเดียวกัน นั่นคือ จะไม่แยกนโยบายเรื่อง Business Objectives กับ IT Objectives ออกจากกัน นี่คือ Integrated Thinking ในเบื้องต้น ก่อนจะก้าวไปสู่ GRC ที่ท้าทายต่อไป

กระบวนการบริหารความเสี่ยง กระบวนการควบคุม กระบวนการตรวจสอบ กระบวนการติดตามการบริหารและการจัดการ รวมทั้ง กระบวนการตัดสินใจ ของคณะกรรมการและผู้บริหารระดับสูง จะเกี่ยวข้องกับ Integrated Thinking เป็นอย่างน้อยทั้งสิ้น

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


Integrated Auditors and Management ตอน 1

ธันวาคม 25, 2010

วันนี้ผมขอเล่าสู่กันฟังในเรื่องเกี่ยวกับ Integrated Audit และ CAE ว่าในอดีตที่ผ่านมาและจนกระทั่งถึงทุกวันนี้ อาจกล่าวได้ว่า องค์กรส่วนมากยังเข้าใจความหมายของ Integrated Audit และประโยชน์ของการตรวจสอบในลักษณะนี้ที่แตกต่างกันมาก จากการที่องค์กรไม่ได้มีการปฏิบัติที่เป็นรูปธรรมของการผสมผสานการตรวจสอบและใช้ประโยชน์จากแนวคิดที่เป็นลักษณะ Interdependent Approach ของกระบวนการตรวจสอบระหว่าง IT Audit และ Non – IT Audit เข้ามาใช้เป็นพลังร่วม (Synergy) ในการขับเคลื่อนกระบวนการตรวจสอบไปสู่การจัดทำรายงานการตรวจสอบที่มีคุณภาพสูงสุด จากการหลอมรวมกระบวนความคิด ซึ่งนำไปสู่ความเข้าใจในการวางแผนการตรวจสอบ ที่คำนึงถึง Audit Universe หรือเรื่องที่ควรได้รับการทดสอบในภาพโดยรวมที่เกี่ยวข้อง ซึ่งจะเชื่อมโยงหรือมีผลกระทบต่อกระบวนการจัดทำรายงาน ทั้งทางด้าน IT และ Non – IT ที่จะสัมพันธ์กับการควบคุมความเสี่ยงจาก Risk Universe ในแง่มุมต่าง ๆ ในมุมมองของ Business Balanced Scorecard และ Information Balanced Scorecard หรือแม้กระทั่งเป้าประสงค์หลักของการควบคุมความเสี่ยง ตามหลักการของ COSO – ERM ซึ่งก็ได้แก่ Strategic Risk – S, Operation Risk – O, Reporting Risk – R or F, Compliance Risk – C ที่ส่วนใหญ่จะเคยชินกับคำที่เรียกกันสั้น ๆ ว่า S – O – F – C

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

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

จากจุดอ่อนดังกล่าว ในทางปฏิบัติของหลาย ๆ องค์กร ทั้งภายในและต่างประเทศหลายแห่ง เกิดจากการบริหารและการจัดการที่มีแนวความคิดจากโครงสร้างขององค์กร ที่ส่วนใหญ่ยังแบ่งงานในลักษณะ Silo – Based นั่นคือ การแบ่งงานตามหน้าที่ หรือตาม Function มากกว่า การคำนึงถึงกระบวนการในการดำเนินงาน ที่ในปัจจุบันใช้คอมพิวเตอร์เข้าช่วยในแทบทุกองค์กร ซึ่งกระบวนการทำงานโดยใช้คอมพิวเตอร์ในขั้นตอนการปฏิบัติงานเป็นส่วนใหญ่นั้น จะมีลักษณะเป็น Integrated – Based ซึ่งอาจจะกล่าวโดยย่อได้คือ เป็นการดำเนินงานที่เชื่อมต่อ กระบวนการทำงานในแต่ละกิจกรรมและในแต่ละขั้นตอนเข้าด้วยกันอย่างต่อเนื่อง ภายในสายงานเดียวกันและข้ามสายงานอย่างอัตโนมัติ โดยเฉพาะอย่างยิ่ง ขั้นตอนการประมวลผล (Process) ซึ่งในขั้นตอนนี้ องค์กรที่ใช้คอมพิวเตอร์เป็นหลักในการดำเนินงาน เช่น ในวงการการเงิน การธนาคาร ตลาดหลักทรัพย์ บริษัทการบิน และการให้บริการแบบอัตโนมัติ ทั้งในลักษณะ Online และ Offline โดยเฉพาะอย่างยิ่ง การให้บริการที่เป็นลักษณะ One Stop Service จะมีลักษณะการใช้คอมพิวเตอร์เข้ามาช่วยในการดำเนินงานเป็นส่วนใหญ่ และมีนัยสำคัญยิ่งต่อความพึงพอใจของลูกค้า และผู้ที่เกี่ยวข้องอย่างมีนัยสำคัญที่ไม่อาจปฏิเสธได้

ความเป็นจริงดังกล่าวตามวรรคต้น มีนัยสำคัญยิ่งต่อกระบวนการควบคุมความเสี่ยง ที่เกี่ยวข้องกับ IT Risk และ IT – Related Risk ที่มีผลต่อ Business Risk ที่เชื่อมโยงกับ Business Process และ Business Control และลึกลงไปถึง Application Control และ General Control ตามหลักการจัดการบริหารที่เป็นกระบวนการที่ใช้ Computer – Based เป็นหลักทั้งสิ้น

เรื่องของ Integrated Auditors and Management ที่ผมเล่าในวันนี้ ยังไม่จบเพียงเท่านี้ ครั้งหน้าไปติดตามกันต่อนะครับ


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

ตุลาคม 27, 2010

ในหัวข้อของ IT Audit นี้ จากครั้งที่ผ่านมา ผมได้ยกตัวอย่างของการทดสอบข้อมูลโดย Test Data Method – TDM ในระบบงานเงินฝากขององค์กร แบบ 1 Cycle ไปหลายตัวอย่างพอสมควร สำหรับครั้งนี้ผมจะขอยกตัวอย่าง TDM ในระบบงานเงินฝากขององค์กร แบบ 2 Cycle ที่ได้กล่าวถึงไว้ในครั้งก่อน ๆ เพื่อให้ท่านผู้อ่านได้ลองพิจารณาถึงความแตกต่างของการทดสอบข้อมูลโดย Test Data Method ทั้ง 2 แบบ ดังนั้น เราไปติดตามกันเลยนะครับว่า การทดสอบข้อมูลโดย TDM แบบ 2 Cycle ที่จะกล่าวถึงนี้เป็นอย่างไร

ตัวอย่าง Test Data Method 2 Cycle

Test Data 2 Cycle_ตย 1

Test Data 2 Cycle_ตย 2

Test Data 2 Cycle_ตย 3_1
Test Data 2 Cycle_ตย 3_2

Test Data 2 Cycle_ตย 4_1
Test Data 2 Cycle_ตย 4_2


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

ตุลาคม 4, 2010

การทดสอบข้อมูลโดย Test Data Method – TDM ซึ่งผมได้ยกตัวอย่างของ Test Data ในระบบงานเงินฝากขององค์กร แบบ 1 Cycle ไป 2 – 3 ตัวอย่างในครั้งที่แล้ว เป็นอย่างไรบ้างครับ คงพอทำให้ท่านผู้อ่านเข้าใจและเห็นภาพของการจัดทำ Test Data ที่ชัดเจนยิ่งขึ้น หลังจากที่ได้นำเสนอถึงรายละเอียด ขั้นตอนและข้อดี ข้อเสียของการจัดทำไปในครั้งก่อน ๆ สำหรับครั้งนี้ ผมยังมีตัวอย่างของการจัดทำ Test Data แบบ 1 Cycle ที่แตกต่างกันในรายละเอียดมาให้พิจารณาอีกสัก 2 – 3 ตัวอย่าง ไปติดตามกันต่อเลยนะครับ

Test Data 1 Cycle_ตย 4

Test Data 1 Cycle_ตย 5

Test Data 1 Cycle_ตย 6

ครั้งหน้าไปติดตามตัวอย่าง Test Data ในระบบงานเงินฝากขององค์กร แบบ 2 Cycle กันนะครับ


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

กันยายน 23, 2010

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

สำหรับในครั้งนี้ ผมขอยกตัวอย่าง Test Data 1 Cycle เป็นตัวอย่างสัก 2 – 3 ตัวอย่างก่อนนะครับ

Test Data 1 Cycle_ตย 1

Test Data 1 Cycle_ตย 2

Test Data 1 Cycle_ตย 3


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

กันยายน 16, 2010

ครั้งก่อนผมได้ยกตัวอย่างขั้นตอนของการจัดทำ Test Data ในระบบ On-line โดยได้แยกเป็นการเตรียมการก่อนการทดสอบ, ระหว่างการ Key ข้อมูล และเมื่อเสร็จสิ้นการ Key ข้อมูล ซึ่งจะทำให้เข้าใจในกระบวนการของการจัดทำได้ง่ายขึ้น นอกเหนือจากขั้นตอนที่ได้กล่าวไปแล้ว ยังมีข้อควรพิจารณาในการจัดทำ Test Data รวมถึงข้อดี ข้อเสีย ของการนำ Test Data มาใช้งาน ที่เป็นสิ่งที่ควรรู้และเข้าใจซึ่งผมจะได้กล่าวถึงในวันนี้ ก่อนที่จะได้นำเสนอตัวอย่างของการจัดทำ Test Date ในระบบงานเงินฝากในโอกาสต่อไป

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

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

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

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

5. ควรใช้โปรแกรมที่ได้แปลงรหัสแล้วพร้อมที่จะนำมาประมวลผลได้ทันที ไม่ควรใช้โปรแกรมที่ได้จากการนำ Source Program มาแปลงรหัสใหม่ เมื่อนำมาประมวลผลข้อมูลทดสอบโดยเฉพาะ

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

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

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

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

ข้อดี ข้อเสีย ของการ Test Data มาใช้งาน

ข้อดี
1. ไม่จำเป็นต้องใช้บุคลากรที่มีความรู้ความชำนาญสูงในการเตรียมข้อมูลทดสอบ

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

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

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

4. ผู้ตรวจสอบสามารถใช้ผลลัพธ์จากการทดสอบเป็นหลักฐานในการปฏิบัติงานตรวจสอบของตน

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

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

ดังนั้น ผู้ตรวจสอบควรตรวจสอบ Source Program Listing ควบคู่ไปด้วย โดยเน้นเฉพาะการค้นหาคำสั่งผิดปกติที่ประมวลผลรายการใดรายการหนึ่งเป็นกรณีพิเศษ

2. ผู้ตรวจสอบต้องเสียเวลามากในการจัดเตรียม Test Data และคำนวณผลลัพธ์ที่คาดไว้ล่วงหน้า

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

4. ประสิทธิภาพและประสิทธิผลที่จะได้รับ ขั้นอยู่กับความสามารถของผู้ตรวจสอบแต่ละคน ผู้ตรวจสอบอาจมองข้ามประเด็นสำคัญที่ควรทดสอบไปได้


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

กันยายน 1, 2010

สำหรับเรื่องของ Test Data ที่ผมนำเสนอไปในครั้งที่แล้ว และได้กล่าวถึงขั้นตอนของการจัดทำ Test Data ไว้ในหัวข้อที่ 1 นั้น วันนี้ผมจะขอยกตัวอย่างขั้นตอนของการจัดทำ Test Data ในระบบ On-line ต่อเป็นหัวข้อที่ 2 โดยเป็นตัวอย่างการปฏิบัติงานตรวจสอบระบบเงินฝากขององค์กรโดยทั่วไป ซึ่งการปฏิบัติงานจริงอาจมีรายละเอียดบางอย่างแตกต่างกันไปบ้างในแต่ละองค์กร

2. ตัวอย่างขั้นตอนการจัดทำ Test Data ในระบบ On-line

2.1. การเตรียมการก่อนการทดสอบขององค์กร

2.1.1. ต้องศึกษาและทำความเข้าใจในระบบการปฏิบัติงานขององค์กรก่อนลงมือทดสอบในแต่ละระบบอย่างละเอียด

2.1.2. ต้องศึกษาและทำความเข้าใจใน Format และ Transaction Code ต่าง ๆ

2.1.3. ทำความเข้าใจในระบบการจัดเก็บ File และ Program ของระบบงานต่าง ๆ

2.1.4. ทำความเข้าใจในการทำ Copy ข้อมูล และโปรแกรมที่จะนำมาใช้ในการทดสอบ

2.1.5. ทำความเข้าใจและเจรจากับหัวหน้าศูนย์คอมพิวเตอร์ขององค์กรในเรื่องต่อไปนี้
ก) เวลาที่จะเริ่มทำการทดสอบ
ข) ระยะเวลาที่จะใช้สำหรับการทดสอบ
ค) ชื่อ Report ที่จะขอให้องค์กรพิมพ์มีทั้งสิ้นเท่าใด
ฆ) Printer และ Keyboard ที่จะใช้สำหรับการทดสอบมีจำนวนเท่าใด
ง) เจ้าหน้าที่ผู้ประสานงานขององค์กรมีกี่คน และใครบ้าง
จ) Passbook หรือ Slip ต่าง ๆ ที่จะใช้สำหรับการทดสอบ จะต้องเตรียมการไว้ให้พร้อม เช่น Debit Slip, Credit Slip และ Transfer Slip รวมทั้งแบบพิมพ์อื่น ๆ ที่เกี่ยวข้อง
ฉ) ในกรณีที่องค์กรมีเครื่องคอมพิวเตอร์จำกัด ก็จะต้องทราบว่าหลังจากเสร็จสิ้นงาน On-line แล้ว จะต้องทำงาน Batch อีกนานเท่าใด จึงสามารถเริ่มต้นให้เวลาสำหรับการ Test Data การออก Report และการ Load ข้อมูลกลับเข้าไปในเครื่อง เพื่อทำงานปกติขององค์กรต่อไปได้
ช) ให้องค์กรเตรียม PASS-WORK และUSER-ID กับกุญแจเครื่องของเจ้าหน้าที่ระดับ Authorized แล้วจะเปลี่ยนแปลงใหม่ เมื่อการทดสอบข้อมูลเสร็จสิ้นลงแล้ว

2.1.6. สร้าง Logic และข้อมูลต่าง ๆ เพื่อใช้สำหรับการทดสอบ การสร้างข้อมูลนี้จะต้องคำนึงถึงความสะดวก และจุดมุ่งหมายในการทดสอบด้วย คือ
ก) สร้างข้อมูลขึ้นมาใหม่ทั้งหมด วิธีนี้จะต้องเปิดบัญชีขึ้นมาใหม่ สร้างรายการทั้งที่เกี่ยวกับตัวเลข และประวัติที่อยู่ของลูกค้าขึ้นใหม่ทั้งหมด คงจะเสียเวลาไปบ้าง แต่จะได้ประโยชน์สำหรับการทำงานของเครื่อง คือ ใช้เวลาในการ Sort และการออก Report สั้นและเร็ว เพราะมีจำนวน Data เฉพาะส่วนที่ Key เข้าไปเท่านั้น
ข) ใช้ข้อมูลหรือบัญชีเดิมขององค์กรมาทำรายการต่อไป เช่น ยอดคงเหลือวงเงินต่าง ๆ Clearing Cheque จะมีการเปิดบัญชีและเพิ่มเติมข้อมูลใหม่เข้าไปบ้าง แต่จะน้อยกว่าการสร้างบัญชีขึ้นมาใหม่ วิธีการนี้จะทำให้ใช้เวลาสำหรับการ Key สั้นลง เพราะมีข้อมูลอยู่ใน File แล้วจำนวนหนึ่ง แต่จะมีข้อเสียคือ ใช้เวลาในการทำงานของเครื่องมาก เพราะการ Sort การออก Report จะใช้เวลานาน เนื่องจากมีจำนวน Data อยู่ใน File มาก

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

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

2.2. ระหว่างการ Key ข้อมูล

2.2.1. ต้องแจ้งให้องค์กรทราบว่า วันที่ในระบบงานที่กำหนดให้ทำ Test Data เป็นวันเดือนปี ใด Yesterday และ Next day เป็นวันที่เท่าใด Clearing Hold กี่วัน ทั้งนี้ เพื่อใช้สำหรับการออกวันที่ใน Report และการคิดดอกเบี้ย ฯลฯ

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

2.2.3. ในระหว่างที่ Operator ทำการ Key แล้ว แจ้งแก่ผู้ตรวจสอบว่า อาจจะ Key ไม่ได้หรือขัดข้องแน่ จะขอข้ามไปหรือแก้ไขโจทย์ได้หรือไม่

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

2.2.4. ก่อนการปลด Lock Cheque Clearing อย่าลืมให้ Operator ผู้รับผิดชอบทำรายการ Key รายละเอียดเช็คฉบับที่คืน (Return Cheque) เสียก่อน หากไม่ทำ Step นี้โดยปลด Lock เช็คแล้วจะถือว่าทั้งหมดผ่านการ Clearing

2.3. เมื่อเสร็จสิ้นการ Key

2.3.1. เมื่อเสร็จสิ้นการ Key ข้อมูลแล้ว ควรจะให้มีการพิมพ์รายละเอียดและยอดรวมของ Teller ทุกคน

2.3.2. ขอให้ออก Journal Roll จากเครื่อง Printer และเก็บโจทย์ที่มอบให้แก่ Operator กลับคืนโดยครบถ้วน

2.3.3. ก่อนจะปิดเครื่อง ตรวจนับ PASS-BOOK และ SLIP ต่าง ๆ ว่าได้รับคืนมาครบถ้วนหรือไม่ เพราะบางองค์กรหากปิดเครื่องไปแล้วจะให้เปิดและทำรายการใหม่ไม่ได้

2.3.4. ตรวจนับ Report ที่ได้รับว่าครบถ้วนตามที่ต้องการหรือไม่


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

สิงหาคม 25, 2010

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

Test Data คือ อะไร

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

Test Data Method

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

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

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

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

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

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