โครงของบท#

• ผลตรวจไม่ใช่คำสั่งแก้ — แยก recommendation ของผู้ตรวจ ออกจาก action plan ที่ management เป็นเจ้าของ
• บันไดคำศัพท์: criteria → condition → cause → effect → conclusion → recommendation ลำดับนี้ข้อสอบชอบสลับมาหลอก
• เจอปัญหาแล้วอย่ารีบลงดาบ — เข้าใจ root cause ก่อนเสมอ
• เห็นต่างกับ management ให้เดินตาม established methodology ไม่ใช่ดันทุรังหรือถอนข้อเสนอ
• หน้าที่ CAE: ประเมิน residual risk ของงานเทียบกับ risk appetite / risk tolerance ขององค์กร
• เมื่อ management เลือก “รับ risk ไว้เอง” CAE ต้องทำอะไร — และเมื่อไหร่ถึงจะขึ้นถึง board

รายงานไม่ใช่ใบสั่ง: recommendation กับ action plan คนละคนถือ#

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

แต่คนที่จะบอกว่า “เอาล่ะ ฉันจะแก้แบบนี้ ภายในสิ้นเดือน คนนี้รับผิดชอบ” คือผู้จัดการคลังเอง นั่นคือ management action plan — แผนลงมือที่ management เป็นเจ้าของ เป็นคนเลือกวิธี เป็นคนถือกำหนดเวลา และเป็นคนรับผลถ้ามันไม่เวิร์ก

ทำไมต้องแยกให้ชัดขนาดนี้? เพราะถ้าผู้ตรวจกระโดดลงไปแก้เอง หรือไปสั่งการบังคับ ความเป็นอิสระ (independence) กับความเที่ยงธรรม (objectivity) ก็พังทันที เดี๋ยวรอบหน้ากลับมาตรวจ ก็กลายเป็นตรวจงานตัวเอง แล้วใครจะเชื่อว่าตรวจตรง

ในภาษาของ the Standards เรื่องนี้ตกอยู่ที่ Standard 14.4 (Recommendations and Action Plans) จำเจตนาไว้พอครับ ไม่ต้องท่องเลข ใจความคือ ผู้ตรวจสอบภายในต้องตัดสินใจว่าจะ พัฒนา recommendation เอง, ขอ action plan จาก management, หรือ ทำงานร่วมกัน (collaborate) เพื่อตกลงว่าจะลงมือยังไง เป้าหมายมี 4 อย่าง คือ ปิดช่องว่างระหว่างสิ่งที่ควรเป็นกับสิ่งที่เป็นจริง, ลด risk ที่เจอให้อยู่ในระดับที่ยอมรับได้, แก้ที่ root cause ของ finding, แล้วก็ยกระดับ activity under review (กิจกรรมที่กำลังถูกตรวจ) ให้ดีขึ้น

มุมเถ้าแก่/สภา: เส้นแบ่งนี้คือเกราะกันกระเป๋าเงินโดยตรง ถ้าคนที่แก้ปัญหาเป็นคนเดียวกับคนที่ตรวจว่าปัญหาหายรึยัง เถ้าแก่ก็ไม่มีทางรู้ความจริง สภา (board) ต้องการมุมมองที่เป็นกลาง ไม่ใช่คนเดียวสวมสองหมวก และที่สำคัญ พอ management เป็นเจ้าของ action plan ก็แปลว่าถ้าเลือกแก้ผิดวิธี ความรับผิดชอบมันอยู่ที่ management ไม่ได้ลอยไปหาผู้ตรวจ

มุมผู้ตรวจ (คนสอบ): ข้อสอบชอบตั้งสถานการณ์ว่าเจอปัญหาแล้วถามว่า “auditor ควรทำอะไรต่อ” แล้วแอบวางตัวเลือกอย่าง “สั่งให้ management ยอมรับ recommendation เดิม”, “ลงมือแก้ให้เลย”, หรือ “หยุด/ระงับกิจกรรมนั้นทันที” — ทุกตัวเลือกที่ทำให้ผู้ตรวจกลายเป็นคน สั่ง หรือ ลงมือ แทน management คือคำตอบหลอก เพราะมันข้ามเส้นความเป็นอิสระ recommendation ไม่ใช่คำสั่ง มันคือข้อเสนอ

บันไดคำศัพท์ที่ข้อสอบชอบสลับ: จากข้อเท็จจริงไปหาข้อเสนอ#

ทีนี้มาถึงหัวใจที่ต้องแม่นจริงๆ ครับ finding หนึ่งอันเวลาเขียนออกมาให้ครบ มันมีชั้นของมันเป็นบันได ข้อสอบชอบหยิบประโยคนึงขึ้นมาถามว่า “อันนี้คือส่วนไหน” ถ้าไล่บันไดไม่แม่นตอบผิดง่ายมาก

ลองเทียบกับการวินิจฉัยของหมอตรวจร่างกายทั่วไปก็ได้ครับ (ไม่ใช่ระบบเฉพาะทางอะไร) หมอต้องมี “เกณฑ์ปกติ” ในหัวก่อน แล้วค่อยดูผลจริงของคนไข้ แล้วค่อยลงความเห็นว่าป่วยหรือไม่ป่วย แล้วสุดท้ายค่อยสั่งยา — ผู้ตรวจสอบก็เดินบันไดแบบเดียวกัน

• Criteria = สิ่งที่ ควรจะเป็น เกณฑ์หรือมาตรฐานที่ใช้วัด เช่น “ก่อนออกใบจ่ายเงิน ฝ่ายเจ้าหนี้ต้องกระทบยอดใบขอซื้อ ใบสั่งซื้อ และใบรับของกับใบแจ้งหนี้ให้ครบก่อน” — นี่คือสมมติฐานว่าโลกควรหมุนยังไง
• Condition = สิ่งที่ เป็นจริง หลักฐานเชิงข้อเท็จจริงที่ผู้ตรวจไปเจอมากับตา เช่น “ฝ่ายเจ้าหนี้ออกใบจ่ายเงินโดยไม่มีใบขอซื้อ” — เป็นข้อเท็จจริงล้วนๆ ยังไม่มีการตัดสิน
• Cause = เหตุผล ที่ทำให้สิ่งที่ควรเป็นกับสิ่งที่เป็นจริงมันต่างกัน และ recommendation ต้องยิงไปที่ cause นี้
• Effect = ผลกระทบ ความเสี่ยงหรือความเสียหายที่ตามมาเพราะ condition ไม่ตรงกับ criteria เช่น รายการที่เอกสารไม่ครบรวมเป็นเงินก้อนใหญ่ที่มีนัยสำคัญต่อองค์กร
• Conclusion = ข้อสรุป ที่ใส่ดุลพินิจวิชาชีพลงไปแล้ว บอกว่าโดยรวมน่าพอใจหรือไม่น่าพอใจ (satisfactory / unsatisfactory) เช่น “ระบบควบคุมภายในของงานจัดซื้อและเจ้าหนี้ไม่มีประสิทธิผล”
• Recommendation = ข้อเสนอ เพื่อแก้ ซึ่งจะโผล่มาได้ก็ต่อเมื่อมี condition และ conclusion อยู่ก่อนแล้วเท่านั้น

⚠️ กับดัก: ตัวเลขดิบหลอกได้เก่งมาก ประโยคแบบ “อัตราไม่ปฏิบัติตามอยู่ที่ 50%” หรือ “ผลการทดสอบ testwork ออกมาเป็นแบบนี้” หรือผลลัพธ์ที่โผล่มาทันทีหลังทำ work-program step หนึ่งจบ — พอมันมี ตัวเลข คนสอบเลยรู้สึกว่ามันเป็น conclusion แต่จริงๆ ตัวเลขดิบที่ ยังไม่มีคำตัดสิน ว่าดีหรือแย่ ยังเป็นแค่ condition (หรือ finding/observation) เท่านั้น อย่าให้ตัวเลขหลอกจนเผลอเลื่อนขึ้นบันได

⚠️ กับดัก: ประโยคที่ขึ้นต้นว่า “ยกเว้น…แล้วนอกนั้นทำงานตามที่ตั้งใจไว้ (functioning as intended)” ฟังดูเหมือนแค่การสังเกตเฉยๆ แต่พอมันมีคำตัดสินว่า น่าพอใจ / ไม่น่าพอใจ ซ่อนอยู่ นั่นคือ conclusion แล้ว — และจำไว้ว่า conclusion กับ opinion (ความเห็น) ในบริบทนี้คือคำที่ใช้แทนกันได้ ปัจจัยสำคัญที่สุดตัวเดียวที่ทำให้ conclusion มีค่าคือ ดุลพินิจของผู้ตรวจ ไม่ใช่ตัวเลขสวยๆ

⚠️ กับดัก: เวลาเฉลยคือ condition ข้อสอบมักจะแอบวาง criteria มาเป็นตัวเลือกหลอกคู่กันเสมอ (สิ่งที่ควรเป็น vs สิ่งที่เป็นจริง) และกลับกันก็เหมือนกัน ให้ถามตัวเองว่าประโยคนี้กำลัง บรรยายเกณฑ์ หรือ รายงานสิ่งที่เจอ — และมีมุมกลับที่แสบกว่านั้น: ถ้าโจทย์บอกว่า “การวิเคราะห์และประเมินที่เหมาะสมนำไปสู่…” คำตอบจะกระโดดขึ้นบันไดไปเป็น conclusion ไม่ใช่ condition เพราะมันผ่านการประเมินมาแล้ว

จุดที่ต้องแม่นเพิ่มอีกนิด: conclusion ครอบคลุมได้ทั้ง ทั้งขอบเขตงาน หรือแค่ องค์ประกอบเฉพาะบางส่วน ก็ได้ ไม่จำเป็นต้องเหมาว่าทั้งงานเสมอไป

มุมเถ้าแก่/สภา: เถ้าแก่อ่านรายงานไม่ได้อยากเห็นแค่ตัวเลขดิบ ตัวเลขดิบเฉยๆ ยังตัดสินใจอะไรไม่ได้ สิ่งที่เถ้าแก่ต้องการคือ conclusion ที่ผ่านดุลพินิจแล้วว่าตกลงงานนี้ “ผ่านหรือไม่ผ่าน” ต่างหาก เพราะนั่นคือสิ่งที่บอกได้ว่าจะนอนหลับสบายไหมคืนนี้

มุมผู้ตรวจ (คนสอบ): trigger word คือทุกอย่าง ถ้าประโยคแค่ เล่าข้อเท็จจริง/ผลทดสอบดิบ ไม่มีคำตัดสิน → condition. ถ้าเป็น สิ่งที่ควรเป็น เกณฑ์ที่ใช้วัด → criteria. ถ้ามี ดุลพินิจ บอก satisfactory/unsatisfactory → conclusion. ถ้า เสนอวิธีแก้ → recommendation (และต้องมาหลัง condition กับ conclusion เสมอ) ท่องลำดับให้ติดหัว เดี๋ยวเจอโจทย์สลับจะไม่หวั่น

เจอปัญหาแล้วอย่ารีบลงดาบ: root cause มาก่อน#

สมมติกองผู้ตรวจการเจอว่าคลังซื้อของเกินความจำเป็นเป็นเงินก้อนโต เพราะสต็อกบันทึกไม่ตรง คำถามคือก้าวแรกของผู้ตรวจควรทำอะไร?

สัญชาตญาณคือรีบเสนอวิธีแก้ทันทีเลย — ซื้อ software ใหม่มาคุมสต็อกสิ! ลดจำนวนสต็อกลงสิ! เพิ่มคนสิ! แต่นั่นมันแก้ที่ อาการ ไม่ใช่ ต้นเหตุ ก้าวแรกที่ถูกคือ คุยกับผู้จัดการที่รับผิดชอบ และ/หรือ ทำ root cause analysis ให้เข้าใจก่อนว่าทำไมมันถึงพลาด

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

⚠️ กับดัก: ข้อสอบชอบวางตัวเลือกแบบ ลงดาบรุนแรง มาล่อ ได้แก่ ไล่พนักงานออก, freeze/หยุดทุกธุรกรรม, ปิดระบบ, ระงับการสั่งซื้อ, หยุดรับคืนสินค้า ทุกตัวสร้างความปั่นป่วนและไม่แตะต้นเหตุเลย ตัวเลือกพวกนี้ผิดหมด

⚠️ กับดัก: อีกชุดคือ แก้ที่อาการ: ซื้อ software, ลดสต็อก, เพิ่มคน, ทำการตลาดเพิ่ม ฟังดูสมเหตุสมผลแต่ข้ามขั้นตอนวินิจฉัย และชุดที่สามคือ ข้ามหัว management คือรายงานตรงขึ้น board ทันที หรือ escalate เดี๋ยวนั้น ซึ่งเร็วเกินไปในเมื่อยังไม่ได้ลองทำงานร่วมกับ management เลย ที่ห้ามเด็ดขาดสุดคือ “บันทึกไว้แต่ไม่รายงาน” หรือ “รับ risk ไว้เฉยๆ” — อันนี้ผิดตลอด เพราะเป็นการปิดบัง risk

⚠️ กับดัก (มุมกลับ): แต่ถ้าโจทย์ ระบุ root cause มาให้แล้วในตัวคำถาม เช่นบอกชัดว่า “ไม่ปฏิบัติตามเพราะขาดการอบรม” — ตอนนี้อย่าไปเสียเวลาสั่งทำ root cause analysis ซ้ำ! คำตอบพลิกไปเป็นการเสนอวิธีแก้ที่ ตรงกับต้นเหตุนั้น พอดี คือจัด comprehensive training program ให้พนักงาน กฎคือ: ยังไม่รู้ต้นเหตุ → ขุดต้นเหตุ, รู้ต้นเหตุแล้ว → แก้ให้ตรงต้นเหตุ

มุมเถ้าแก่/สภา: การขุด root cause ก่อนคือการประหยัดเงินระยะยาว เถ้าแก่ไม่อยากจ่ายค่า software แพงๆ แล้วปีหน้าปัญหากลับมาเพราะต้นเหตุจริงคือ “ไม่มีใครสอนงานพนักงานใหม่” การแก้ที่อาการคือจ่ายซ้ำไปเรื่อยๆ

มุมผู้ตรวจ (คนสอบ): จับ trigger ให้ได้ — โจทย์บอกต้นเหตุมารึยัง? ถ้ายัง คำตอบเกือบทุกครั้งคือ “discuss กับผู้จัดการที่รับผิดชอบ” หรือ “conduct root-cause analysis” ถ้าเจอตัวเลือกที่ รุนแรง, ป่วนงาน, ข้ามหัว management, หรือไม่ทำอะไร/รับ risk เฉยๆ ให้ตัดทิ้งได้เลย

เห็นต่างกับ management: เดินตาม methodology อย่าดันทุรัง#

ทีนี้พอเสนอ recommendation ไปแล้ว management ไม่เห็นด้วยล่ะ? หรือ management เสนอแผนของตัวเองมา ต่างจากที่ผู้ตรวจคิด? เรื่องนี้เกิดบ่อย ข้อสอบก็ชอบมาก

หลักคือ พอผู้ตรวจกับ management เห็นต่างกันเรื่อง recommendation หรือ action plan ผู้ตรวจต้อง เดินตาม established methodology คือกระบวนการที่ตกลงกันไว้ล่วงหน้า (มักเขียนอยู่ในกฎบัตร charter ของ internal audit) เปิดให้ทั้งสองฝ่ายได้แสดงจุดยืนและเหตุผลของตัวเอง แล้วหาข้อยุติร่วมกัน หัวใจคือคุยกันว่าแผนที่เสนอมันแก้ root cause ได้จริงไหม ไม่ใช่มาเอาชนะกัน

จุดที่ต้องระวังในการรีวิว draft รายงานกับ management: ผู้ตรวจ ยืดหยุ่นได้ ในประเด็นที่ไม่กระทบเนื้อหาสาระ — แต่ ห้ามต่อรอง conclusion เด็ดขาด ข้อสรุปเชิงดุลพินิจต่อรองไม่ได้ ถ้ายังเห็นต่างกันจริงๆ ให้บันทึกทั้งสองจุดยืนและเหตุผลของความไม่ลงรอยไว้ในรายงานฉบับสุดท้าย

⚠️ กับดัก: ตัวเลือก “ยืนกรานให้ management ยอมรับ recommendation เดิม” ผิด เพราะ recommendation ไม่ใช่คำสั่ง บังคับไม่ได้ ส่วน “ถอน/ลบ recommendation ทิ้ง” ก็ผิด เพราะเป็นการปิดบัง risk และฆ่าความโปร่งใส

⚠️ กับดัก: “escalate ขึ้น board/หน่วยกำกับทันที” เร็วเกินไป การ escalate สงวนไว้สำหรับ risk ที่ยอมรับไม่ได้และแก้ไม่ตกจริงๆ เท่านั้น และ “ลงมือ implement เอง” — ผิดเพราะทำลายความเป็นอิสระและเกินอำนาจหน้าที่

⚠️ กับดัก (มุมกลับ): ถ้าความเห็นต่างมีรากมาจากเรื่อง cost-benefit คือ management บอกว่าแก้แล้วไม่คุ้ม ตอนนี้ผู้ตรวจต้อง บันทึกเหตุผลของ management ไว้ แล้วประเมินว่า risk ที่ยังไม่ได้แก้นั้น อยู่ในระดับที่ยอมรับได้หรือไม่ จะ escalate ขึ้น governance ก็ต่อเมื่อมัน ยอมรับไม่ได้ เท่านั้น อีกกรณีที่เจอ: ถ้า action plan ที่ management เสนอมา ไม่มีการวิเคราะห์ cost-benefit เลย ผู้ตรวจก็เสนอให้เพิ่มการวิเคราะห์นั้นเข้าไป

มุมเถ้าแก่/สภา: เถ้าแก่ไม่อยากให้กองผู้ตรวจการกับผู้จัดการทะเลาะกันจนงานไม่เดิน methodology ที่เขียนไว้ในกฎบัตรคือกติกากลางที่ทำให้ความเห็นต่างจบลงด้วยเหตุผล ไม่ใช่ด้วยอำนาจหรืออีโก้ และถ้าสุดท้ายยังตกลงไม่ได้ เรื่องที่มีความเสี่ยงสูงจริงๆ ต้องถูกยกให้ senior management และ board เป็นคนตัดสินการตอบสนองต่อ finding สำคัญ — เพราะเป็นคนที่มีอำนาจ รับ risk แทนองค์กร

มุมผู้ตรวจ (คนสอบ): ตั้งค่า default ไว้เลยว่าเจอ “เห็นต่าง” → เดินตาม methodology, collaborate. ถ้าเป็นเรื่อง cost-benefit → บันทึกเหตุผล + ประเมินว่า risk ยอมรับได้ไหม. ตัวเลือกที่ให้ ยืนกราน, ถอนข้อเสนอ, ลงมือเอง, หรือ escalate ทันที ตัดทิ้งได้เกือบตลอด

หน้าที่ CAE: วัด residual risk ด้วยไม้บรรทัดขององค์กรเอง#

ทีนี้ขยับขึ้นมามุมของ CAE (chief audit executive หัวหน้ากองผู้ตรวจการ) ครับ พอ management ลงมือแก้ตาม action plan แล้ว มันไม่เคยแก้ได้ 100% control ที่ใส่เข้าไปมันลด risk ลงได้ระดับหนึ่ง แต่ยังมีส่วนที่ เหลือค้าง อยู่เสมอ ส่วนที่เหลือนั่นแหละคือ residual risk และหน้าที่ของ CAE คือประเมินว่าเจ้า residual risk ที่เหลือของ activity under review นี้ ยอมรับได้หรือไม่

คำถามคือ ยอมรับได้ เทียบกับอะไร? นี่คือจุดตายของข้อสอบเลย

คำตอบคือ เทียบกับ risk appetite (ชนิดและปริมาณ risk ที่องค์กรยินดีรับเพื่อไล่ตามกลยุทธ์และเป้าหมายของตัวเอง) และ risk tolerance (ความผันผวนที่ยอมรับได้ในผลงานที่เกี่ยวกับการบรรลุเป้าหมาย) — ทั้งสองคำนี้เป็นไม้บรรทัด ของแต่ละองค์กรเอง ไม่ใช่ไม้บรรทัดกลางของอุตสาหกรรม

⚠️ กับดัก: ตัวเลือก “เทียบกับ industry best practices / benchmark ของหน่วยกำกับ” ฟังดูเนี้ยบมีหลักการ แต่มัน ไม่ได้ บอกว่า risk นี้ยอมรับได้สำหรับ องค์กรนี้ หรือเปล่า เพราะแต่ละองค์กรมี appetite ไม่เท่ากัน

⚠️ กับดัก: “ทำ cost-benefit analysis” หรือ “พิจารณาด้านการเงินก่อน” เป็นขั้นตอน ทีหลัง ไม่ใช่เกณฑ์แรก/เกณฑ์หลักในการตัดสินว่ายอมรับ risk ได้ไหม และ “ยอมรับการประเมินของ management/ผู้จัดการเพราะเขามีประสบการณ์มากกว่า” ก็ผิด เพราะเป็นการทิ้งหน้าที่ประเมินของผู้ตรวจเอง ส่วน “หยุดกิจกรรมนั้น / แนะนำให้รื้อ control ทิ้งทั้งหมด” ก็สุดโต่งเกินไปโดยไม่มีการวิเคราะห์

⚠️ กับดัก (มุมกลับ): เมื่อ management เลือก รับ risk ไว้เอง ไม่ยอมแก้ ไม้บรรทัดก็ยังเป็นอันเดิม CAE ต้อง ตรวจสอบว่าการรับ risk นั้นอยู่ในระดับ tolerance ขององค์กรหรือไม่ ไม่ใช่รับตามที่ management บอกแบบหลับหูหลับตา และก็ไม่ใช่รีบรายงานทันทีเช่นกัน

ตรงนี้ขอทวนคู่ inherent/residual สั้นๆ ตามที่ปูไว้ตอน /posts/cia-p3-41-risk-based-audit-plan/ แล้วครับ: inherent = risk สภาพดิบก่อนมี control, residual = ส่วนที่เหลือหลังใส่ control/risk response เข้าไปแล้ว จุดที่ตอนนี้สนใจไม่ใช่ตัวนิยาม แต่คือ residual risk หลังตรวจ ใครประเมิน ใครรับ — ผู้ตรวจเป็นคนประเมินว่ามันเหลือเท่าไหร่ แต่คนที่ตัดสินใจ รับ residual นั้นไว้เองคือ management ส่วน CAE มีหน้าที่ดูว่าการรับนั้นยังอยู่ในกรอบที่องค์กรรับได้หรือไม่

graph TD
  A["ผู้ตรวจ recommendation<br/>(ข้อเสนอแนะ)"] --> B["management action plan<br/>(แผนลงมือ)"]
  B --> C["CAE ประเมิน residual risk<br/>(เทียบ appetite / tolerance)"]
  C --> D{"ยอมรับได้ไหม"}
  D -->|"อยู่ในกรอบ"| E["จบ ติดตามต่อ"]
  D -->|"management รับ risk<br/>ที่รับไม่ได้"| F["escalate ถึง board"]
  style A fill:#fca5a5,color:#000
  style B fill:#fca5a5,color:#000
  style C fill:#fca5a5,color:#000
  style D fill:#a5b4fc,color:#000
  style E fill:#a5b4fc,color:#000
  style F fill:#fca5a5,color:#000

มุมเถ้าแก่/สภา: appetite คือการที่สภาบอกล่วงหน้าว่า “องค์กรเรายอมเสี่ยงแค่ไหน” เช่นยอมขาดทุนได้ไม่เกินสัดส่วนหนึ่งของเงินลงทุนก้อนใหม่ หรือยอมให้สต็อกสินค้าขายดีลดต่ำได้ไม่เกินระดับหนึ่งก่อนต้องรีบเติม — เมื่อไม้บรรทัดถูกตั้งไว้ชัด CAE ถึงจะวัดได้ว่า risk ที่เหลืออยู่มันล้ำเส้นที่เถ้าแก่รับได้รึยัง นี่คือเรื่องการนอนหลับของเจ้าขององค์กรตรงๆ

มุมผู้ตรวจ (คนสอบ): เจอโจทย์ถามว่า “จะตัดสิน residual risk / accepted risk ยังไง” → คำตอบคือ เทียบกับ risk appetite และ risk tolerance ขององค์กร ตัวเลือกที่ชู benchmark อุตสาหกรรม, cost-benefit, ยอมตามผู้จัดการ, หรือหยุดกิจกรรม → ผิดหมด (เป็นบริบทหรือสุดโต่ง ไม่ใช่ เกณฑ์)

ประเมินก่อน อย่ารีบรายงาน อย่ารีบรับ#

พอ CAE เจอ high-risk finding ที่ไม่ถูกแก้ทันเวลา หรือดูจะเสี่ยงเกินที่องค์กรรับได้ ก้าวต่อไปคืออะไร? สัญชาตญาณบอกให้รีบวิ่งไปบอก board แต่ช้าก่อนครับ

ก้าวต่อไปเกือบทุกครั้งคือ ประเมิน (evaluate/assess) นัยสำคัญของมันก่อน แล้วค่อยจัดลำดับความสำคัญ ส่วนการรายงานขึ้น board, การหยุดกิจกรรม, หรือการรับ risk พวกนี้ เร็วเกินไป ถ้ายังไม่ได้ประเมิน

⚠️ กับดัก: ตัวลวงที่ต้องตัดทิ้งมีเป็นชุด:

• “รายงานขึ้น board/หน่วยกำกับทันที” : เร็วเกินก่อนประเมิน
• “ยอมรับการตัดสินใจของ management / คำแก้ตัวของผู้จัดการ” : ข้ามหน้าที่ประเมินของผู้ตรวจเอง
• “ขออนุมัติจาก board ก่อนถึงจะไปทำ risk assessment” : ผิด เพราะการประเมินเชิงรุกไม่ต้องรอ board อนุมัติ
• “หยุดกิจกรรม/รื้อ control ทิ้ง” : สุดโต่งโดยไม่วิเคราะห์

⚠️ กับดัก (มุมกลับ): ถ้าเอกสาร governance ล้าสมัย เช่น risk-appetite statement ที่ไม่ได้อัปเดตมาหลายปี วิธีแก้คือ เสนอให้ board ทบทวนและปรับปรุง เอกสารนั้น ไม่ใช่ให้ internal audit ไปเขียนแก้เอง เพราะการไปเป็นเจ้าของเอกสาร governance เท่ากับ scope creep ล้ำเส้นหน้าที่ตัวเอง — จำภาพความรับผิดชอบไว้: board กำกับดูแล risk, management ตั้ง risk attitude และจัดการ risk, ส่วน internal audit function ให้ assurance (การให้ความเชื่อมั่น) ต่อระบบบริหาร risk ทั้งหมด ไม่ใช่คนถือ risk เอง

มุมผู้ตรวจ (คนสอบ): default คือ evaluate ก่อน escalate/accept เสมอ เจอ finding ใหม่แล้วถามก้าวต่อไป → ประเมินนัยสำคัญ + จัดลำดับ ตัวเลือกที่ รายงาน board, หยุด, หรือรับโดยไม่ประเมิน → ผิดเพราะเร็วเกิน

รวมข้อค้นพบเพื่อเห็น “รูปแบบ” ไม่ใช่เพื่อความสะดวก#

CAE มีเครื่องมือตัวนึงคือการ aggregate (รวม) และจัดลำดับ finding จากหลายๆ การตรวจเข้าด้วยกัน ข้อสอบชอบถามว่า “รวมไปทำไม” แล้วแอบวางเหตุผลผิดๆ มาล่อเต็มไปหมด

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

⚠️ กับดัก: เหตุผลผิดๆ ที่ถูกวางมาล่อมีเป็นชุด:

• “เพื่อให้แน่ใจว่าปฏิบัติตาม the Standards” : ผิด the Standards สนับสนุน แต่ไม่ได้ บังคับ ให้ aggregate มันไม่ใช่วัตถุประสงค์
• “เพื่อให้รายงานต่อ board/audit committee ง่ายและมีประสิทธิภาพขึ้น” : เป็นผลพลอยได้ ไม่ใช่เหตุผลหลัก
• “เพื่อลดจำนวน issue ที่ต้องรายงาน” : ผิดชัดเจน การรวมแค่ จัดกลุ่ม มันไม่ได้ทำให้ risk หดหายไป
• “เพื่อกระจายงานทีมให้เท่ากัน/ให้ติดตามการแก้ง่ายขึ้น” : เป็นประโยชน์เชิงปฏิบัติการข้างเคียง ไม่ใช่แก่นเรื่อง

⚠️ กับดัก (มุมกลับ): เฉพาะเรื่อง residual risk การ aggregate มีพลังพิเศษ — มันเผยให้เห็นว่าจุดอ่อนหลายๆ จุด ตัดกันและเสริมกัน จนดัน residual risk รวมให้ สูงกว่าผลบวกของแต่ละอัน ช่องเล็กๆ ห้าช่องที่แยกกันดูไม่น่ากลัว พอมารวมกันอาจเปิดทางให้ปัญหาใหญ่ทะลุเข้ามาได้ และถ้าโจทย์ถามเรื่อง “การ rank finding” ให้จำว่าต้องสะท้อนผลกระทบ ทั้งด้านการเงินและด้านชื่อเสียง เพราะ risk มีหลายมิติ ไม่ได้มีแค่ตัวเงิน

มุมเถ้าแก่/สภา: เถ้าแก่ได้ประโยชน์ตรงที่เห็นภาพใหญ่ ปัญหาเล็กๆ กระจัดกระจายห้าจุดอาจเป็นอาการของโรคเดียวกัน พอรวมให้ดูก็ตัดสินใจแก้ที่ต้นตอทีเดียวได้ ไม่ต้องไล่ปะรูทีละรู

สเกลให้คะแนน: เห็นภาพรวมเร็ว ไม่ใช่ตัวเลขแม่นเป๊ะ#

เครื่องมือสื่อสารอีกตัวคือ rating scale สเกลให้คะแนนภาพรวมของ control เช่น strong / satisfactory / unsatisfactory / critical หรือแบบสีเขียว-เหลือง-แดง วัตถุประสงค์ของมันคืออะไร? ข้อสอบชอบถามตรงนี้

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

⚠️ กับดัก: ตัวเลือกหลอกวางเรียงกันมาเป็นชุด:

• “ให้การวัดที่แม่นยำเชิงปริมาณ เทียบเคียงกันแบบภววิสัยได้” : ผิด rating เป็นเชิงคุณภาพ/เชิงหมวดหมู่ ไม่ใช่ตัวเลขแม่นเป๊ะ
• “benchmark สภาพแวดล้อม control เทียบกับอุตสาหกรรม/คู่แข่ง” : ผิด อันนั้นต้องใช้ข้อมูลภายนอก ไม่ใช่สิ่งที่สเกลภายในทำ
• “รับประกันว่าปฏิบัติตาม the Standards” : ผิด the Standards ปล่อยให้ CAE ใช้ดุลพินิจเรื่องรูปแบบ ไม่ได้บังคับ
• “แทนที่รายละเอียด finding ได้เลย ไม่ต้องดูอย่างอื่น” : ผิด สเกล เสริม รายละเอียด ไม่ได้แทนที่

⚠️ กับดัก (มุมกลับ): ถ้าทีมงานอยากได้บริบทเพิ่ม — เก็บ rating ไว้ แล้ว เพิ่มรายละเอียดแยกย่อยของแต่ละ issue เข้าไป ไม่ใช่โยน rating ทิ้งแล้วเขียนเป็นบรรยายยาวแทน rating บอก สถานะ ส่วนรายละเอียดบอก ว่าจะแก้ตรงไหน สองอย่างทำงานคู่กัน

⚠️ กับดัก (ความหมาย): เกรด “satisfactory” ไม่ได้ แปลว่า risk หายหมด และ ไม่ได้ แปลว่ารับ risk ไว้เพราะแก้แล้วไม่คุ้ม — มันแปลว่า residual risk อยู่ในระดับที่ยอมรับได้ตาม risk appetite ต่างหาก ส่วน “unsatisfactory” แปลว่า control ต่ำกว่ามาตรฐานที่ยอมรับได้ ต้องรีบแก้ด่วน จำเส้นนี้ให้ดี เพราะข้อสอบชอบเอาความหมายมาสลับ

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

มุมผู้ตรวจ (คนสอบ): เจอถามวัตถุประสงค์ของ rating/สเกลสี/ตัวเลข → เลือก สรุปภาพรวมเร็วเพื่อช่วยตัดสินใจและจัดลำดับ ตัดตัวเลือกที่อ้าง แม่นยำเชิงปริมาณ, benchmark, บังคับตาม Standards, หรือแทนที่รายละเอียด ทิ้งทั้งหมด

ตารางกับดักรวม#

สิ่งที่จดสำหรับวันสอบ#

• recommendation = ข้อเสนอของผู้ตรวจ, action plan = แผนที่ management เป็นเจ้าของ ผู้ตรวจไม่สั่ง ไม่ลงมือแก้เอง (ไม่งั้นเสีย independence)
• บันได finding: criteria (ควรเป็น) → condition (เป็นจริง, ข้อเท็จจริง) → cause → effect → conclusion (มีดุลพินิจ = opinion) → recommendation (มาหลังสุด)
• ตัวเลขดิบไม่มีคำตัดสิน = condition ไม่ใช่ conclusion — อย่าให้ตัวเลขหลอก
• เจอปัญหา: ยังไม่รู้ต้นเหตุ → discuss + root cause analysis; รู้ต้นเหตุแล้ว → แก้ให้ตรงต้นเหตุ (เช่น training)
• ห้ามเลือกตัวเลือกที่ รุนแรง / ป่วนงาน / ข้ามหัว management / รับ risk เฉยๆ
• เห็นต่างกับ management → established methodology; ห้ามยืนกราน ถอนข้อเสนอ ลงมือเอง หรือ escalate ทันที
• ห้ามต่อรอง conclusion (ยืดหยุ่นได้แค่เรื่องที่ไม่กระทบสาระ)
• residual risk = ที่เหลือหลังใส่ control; inherent risk = สภาพดิบยังไม่มี control
• ตัดสิน residual/accepted risk → เทียบ risk appetite / risk tolerance ขององค์กร ไม่ใช่ benchmark หรือ cost
• เจอ finding ใหม่ → evaluate นัยสำคัญก่อน เสมอ อย่ารีบรายงาน หยุด หรือรับ
• เอกสาร governance ล้าสมัย → เสนอให้ board แก้ ไม่ใช่ internal audit เขียนเอง
• aggregate finding → เพื่อเห็น รูปแบบเชิงระบบ จำไว้ residual risk รวมอาจ สูงกว่า ผลบวกของแต่ละอัน
• rating scale → อ่านภาพรวมเร็ว ไม่ใช่วัดแม่น; “satisfactory” = residual risk ยอมรับได้ตาม appetite
• เลข Standard (14.4, 13.2) จำเจตนาพอ ไม่ต้องท่องเลข

แยกได้แล้วว่า action plan เป็นของ management ไม่ใช่ของผู้ตรวจ แต่คำถามต่อคือ แล้วผู้ตรวจจะรู้ได้ยังไงว่าเขาทำจริง — ตอนหน้าลงเรื่อง follow-up ที่ the Standards บังคับ ทำไม “กำลังดำเนินการครับ” ถึงเชื่อไม่ได้ถ้าไม่มีหลักฐาน และบันได escalation ที่ต้องไต่ทีละขั้น ตอนถัดไป: ติดตามการแก้ไข

อ้างอิง: Gleim CIA Review (2026), Part 3 · IIA Global Internal Audit Standards (2024)