โครงของบท#

• finding คืออะไร — ข้อเท็จจริงล้วนจาก testwork ไม่ใส่ความเห็น
• engagement conclusion คืออะไร — การตีความ finding ด้วยดุลพินิจ (ศัพท์ใหม่ เดิมเรียก opinion)
• เทียบ condition (สภาพจริง) กับ criteria (เกณฑ์ที่ควรเป็น) แล้วหา root cause ก่อนจะแนะนำอะไร
• วัด significance ของ finding ยังไง — ที่ผลกระทบและความเสี่ยง ไม่ใช่จำนวนนับหรือความรู้สึก
• เชื่อม conclusion กลับไปที่ objectives ของงานเสมอ

กองหลักฐานคือ “ข้อเท็จจริง” — ยังไม่ใช่คำพิพากษา#

เริ่มจากคำที่ข้อสอบ Part 2 ใช้ตรงตัว: finding

finding คือข้อมูลดิบที่ได้จากการทำ audit procedure ผู้ตรวจไปเทสต์ ไปตรวจ แล้วก็บันทึกสิ่งที่หลักฐานบอก โดยไม่ใส่การตีความหรือความเห็นส่วนตัวลงไปเลย ลองคิดดูนะ ถ้าเอาผู้ตรวจอีกคนที่ไม่รู้จักกันมาทำ procedure ชุดเดียวกัน เขาต้องบันทึกข้อเท็จจริงชุดเดิมเป๊ะ นั่นแหละคือ finding ที่ดี — มันทวนซ้ำได้ (repeatable) ยืนหยัดได้เวลาโดนโต้แย้ง

ตัวอย่างที่เป็น finding จริงๆ หน้าตาแบบนี้:

• “จากใบสั่งซื้อที่สุ่มมา ไม่พบใบที่ไม่ได้รับอนุมัติเลย”
• “พบสามรายการที่จัดซื้อจาก vendor นอกขอบเขตสัญญาที่ตกลงกันไว้”
• “พบห้ารายการที่คนอนุมัติ invoice เป็นคนเดียวกับคนตรวจรับของ — ขัดกับหลัก segregation of duties”

สังเกตมั้ยว่าทุกประโยคเล่าแค่ “เห็นอะไร” ไม่มีคำว่า “ดี/แย่”, “ควร/ไม่ควร” ปนเข้ามาเลย นั่นแหละหัวใจ

พอมี finding แล้ว ผู้ตรวจถึงจะใช้ดุลพินิจ (professional judgment) ตีความว่าข้อเท็จจริงพวกนี้ หมายความว่าอะไร — control ตัวนี้ใช้ได้ไหม ต้องปรับปรุงไหม หรือเป็นความเสี่ยงหนัก การตีความนี่แหละที่ Part 2 เรียกว่า engagement conclusion

ตรงนี้มีจุดที่ต้องจำให้แม่น ศัพท์ข้อสอบใช้คำว่า engagement conclusion ไม่ใช่ engagement opinion (เดิมเรียก opinion) สองคำนี้ความหมายเดียวกัน สลับกันได้ เหมือนกับที่ finding กับ observation ก็เป็นคู่คำที่แทนกันได้ ข้อสอบชอบเอาเรื่องนี้มาเล่น ถามว่า “สองคำไหนที่ใช้แทนกันได้” คำตอบคือ conclusion กับ opinion — ไม่ใช่ finding คู่กับ conclusion แล้วก็ไม่ใช่ finding คู่กับ opinion

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

มุมผู้ตรวจ (คนสอบ): โจทย์คลาสสิคคือโยนประโยคมาให้หนึ่งประโยค แล้วถามว่ามันคือ finding, conclusion, หรือ recommendation ทริกคือดูที่ กริยาของประโยค — ถ้าเล่าว่า “เห็นอะไร” (states what was observed) = finding/observation/condition; ถ้าตีความว่า “น่าพอใจ/ไม่น่าพอใจ/แปลว่าอะไร” = conclusion/opinion; ถ้าสั่งว่า “ควรทำอะไรเพื่อแก้” = recommendation (มาทีหลังสุด)

⚠️ กับดัก: ข้อสอบชอบเอาประโยคที่เป็นข้อเท็จจริงล้วน เช่น “อัตราไม่ปฏิบัติตามของเงินสดย่อยอยู่ที่ 50%” มาติดป้ายว่าเป็น “conclusion” (ผิด นั่นคือ condition ซึ่งเป็นข้อเท็จจริง) และกลับกัน เอาประโยคที่ตีความแล้ว เช่น “ยกเว้นเอกสารที่ขาดไป control ทำงานตามที่ออกแบบ” มาติดป้ายว่าเป็น “finding” — ก็ผิด นั่นคือ conclusion เพราะมันตัดสินว่า “ทำงานตามที่ออกแบบ” ไปแล้ว

⚠️ กับดัก: อีกแบบคือ “กระโดดข้ามขั้น” — พอ testwork เพิ่งได้ข้อเท็จจริงมา คำถามถามว่าขั้นต่อไปทำอะไร แล้วเอาตัวเลือก “recommendation” หรือ “ไปประชุมกับ senior management” มาล่อ ทั้งที่ตอนนั้นมีแค่ข้อเท็จจริง ยังไม่ถึงเวลาสั่งแก้ ขั้นแรกสุดคือ บันทึกมันเป็นข้อเท็จจริงลง workpapers ก่อน

สรุปได้ต่อเมื่อมีเกณฑ์ให้เทียบ — condition เทียบ criteria#

จะตัดสินว่าอะไร “ผิด” ได้ ต้องมีเส้นให้เทียบก่อน เส้นนั้นคือ criteria (เกณฑ์/มาตรฐานที่ควรจะเป็น) ซึ่งผู้ตรวจกำหนดไว้ตั้งแต่ตอนวางแผน ก่อนจะไปเก็บหลักฐานด้วยซ้ำ แล้ว criteria มาจากไหน — จากนโยบายองค์กร, กฎหมาย, มาตรฐานอุตสาหกรรม, KPI, ข้อผูกพันตามสัญญา หรือสิ่งที่คาดหวังจากการออกแบบ control

อีกฝั่งคือ condition — สภาพจริงของสิ่งที่ถูกตรวจ (activity under review) ก็คือหลักฐานที่ finding บันทึกไว้นั่นเอง

การประเมิน finding แท้จริงคือการวางสองอย่างนี้ทาบกัน: condition (สิ่งที่เป็นอยู่จริง) ต่างจาก criteria (สิ่งที่ควรเป็น) ตรงไหน ช่องว่างตรงนั้นแหละคือประเด็น

graph LR
  CR["Criteria<br/>(เกณฑ์ที่ควรเป็น)"] --> G["Cause<br/>(ต้นเหตุ)"]
  CO["Condition<br/>(สภาพจริง)"] --> G
  G --> E["Effect<br/>(ผลกระทบ)"]
  E --> RE["Recommendation<br/>(ข้อเสนอแนะ)"]
  style CR fill:#86efac,color:#000
  style CO fill:#86efac,color:#000
  style G fill:#a5b4fc,color:#000
  style E fill:#a5b4fc,color:#000
  style RE fill:#86efac,color:#000

ตรงนี้มีบทเรียนสำคัญเรื่อง “อย่าสรุปเกินหลักฐาน” ลองคิดดูนะ ถ้าโจทย์บอกว่าผลผลิตเพิ่มขึ้น 4% แต่ ไม่เคยบอกว่าเป้าหมายของโครงการคือเท่าไหร่ — เราจะฟันธงว่าโครงการ “สำเร็จ” ได้มั้ย ตอบไม่ได้ครับ เพราะไม่มี criteria ให้เทียบ คำตอบที่ถูกคือ “ยังต้องการข้อมูลเพิ่ม (more information needed)” ไม่ใช่ประกาศว่าสำเร็จหรือล้มเหลว

มุมผู้ตรวจ (คนสอบ): ต้องแยกสองสถานการณ์ที่ดูคล้ายกันให้ออก

• ไม่มีเป้า/มาตรฐานระบุไว้ → สรุปความมีประสิทธิผลไม่ได้ → ตอบ “ต้องการข้อมูลเพิ่ม”
• มีมาตรฐานอยู่ และทำได้ตามนั้นไม่มีข้อบกพร่อง (เช่น รอยรั่วทุกจุดที่รายงานถูกซ่อมครบในไตรมาสนั้น) → สรุปได้ว่า “เข้าใจและปฏิบัติตามมาตรฐานแล้ว” ไม่ใช่ไปสรุปว่า “ต้องเปลี่ยนมาตรฐาน”

มุมเถ้าแก่/สภา: เรื่องนี้เจ็บกระเป๋าเถ้าแก่ตรงที่ ถ้าผู้ตรวจสรุปเกินหลักฐาน เช่นบอกว่า “ทุกใบสั่งซื้อได้รับอนุมัติถูกต้อง” ทั้งที่สุ่มมาแค่บางส่วน พอถึงวันเกิดปัญหาจริง สภาจะเชื่อรายงานตัวไหนได้อีก ในตัวอย่างเรื่องใบสั่งซื้อ ผู้ตรวจสรุปได้แค่ว่า ด้วยความเชื่อมั่น (confidence) แต่ไม่ใช่ความแน่นอน (certainty) ว่ากลุ่มตัวอย่างเป็นตัวแทนของทั้งกอง คำว่า “ทุกใบ” ต้องมาจากการตรวจทุกใบเท่านั้น

⚠️ กับดัก: เวลาจะเช็คว่าปฏิบัติตามหรือถูกต้องไหม ให้เทียบกับมาตรฐานที่ใช้บังคับโดยตรง เช่น เทียบการรับรู้รายได้กับ accounting standards, เทียบชั่วโมง/อัตราค่าจ้างกับอัตราที่อนุมัติไว้ ข้อสอบชอบเอาตัวล่อมาแทน เช่น เทียบกับ “การคาดการณ์ (projections)”, “ความคาดหวัง”, หรือ “ความเห็นจากการสัมภาษณ์” — พวกนี้ไม่ใช่ criteria ที่ใช้ตัดสินการปฏิบัติตามได้

เจอปัญหาแล้ว หา “ทำไม” ก่อน อย่าเพิ่งฟันธง#

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

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

ลองดูตัวอย่างคลาสสิค audit เจอว่ามี 3 บัญชีจาก 50 บัญชีที่มีรายการค้างเกิน 60 วันโดยไม่ได้รายงานให้ผู้จัดการตามนโยบาย — นั่นคือ finding ถ้าหยุดแค่นี้แล้วสั่ง “ให้รายงานให้ครบ” ก็จบแบบผิวเผิน แต่พอขุด root cause ลึกลงไป: คนทำ reconciliation เป็นพนักงานใหม่ → ไม่ได้รับการอบรมเพียงพอ → เพราะหัวหน้าก็ใหม่และงานล้นจากคนขาด → คนขาดเพราะไม่พอใจค่าตอบแทนและเส้นทางอาชีพ → เพราะมองว่างานนี้เป็นงานเสมียน ไม่ใช่งานวิชาชีพ

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

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

⚠️ กับดัก: ตัวล่อยอดฮิตของหมวดนี้มีสี่พันธุ์ จำไว้ว่าทั้งหมดตอบผิด:

• “รายงาน senior management ทันที” — อาจทำทีหลัง แต่ไม่ใช่ก่อนเข้าใจสาเหตุ
• “ตักเตือน/ไล่ออกพนักงาน” — ไม่ใช่หน้าที่ผู้ตรวจ และข้ามการหาสาเหตุ
• “แนะนำ/ติดตั้ง control ใหม่ทันทีโดยยังไม่สืบต่อ” — วางยาก่อนวินิจฉัยโรค
• “โยนให้ vendor/IT/regulator ไปจัดการ หรือมองว่าเป็นเคสโดดๆ ไม่ต้องสน”

วัดความร้ายแรงที่ “ผลกระทบ” ไม่ใช่ที่ “จำนวน” หรือ “ความรู้สึก”#

finding ทุกอันไม่ได้หนักเท่ากัน ผู้ตรวจต้องจัดลำดับ significance (ความร้ายแรง/นัยสำคัญ) เพื่อรู้ว่าอันไหนต้องเข้ารายงานพร้อม recommendation อันไหนแค่คุยกับ management ของหน่วยงานก็พอ

หลักคือ วัดที่ ผลกระทบที่อาจเกิดต่อองค์กร (potential effect) และความเสี่ยง — ทั้งเชิงปริมาณ (financial impact) และเชิงคุณภาพ (ความถี่และความแพร่กระจายของปัญหา)

ในตัวอย่างชุดเดิม จะเห็นการชั่งน้ำหนักนี้ชัด การที่คนอนุมัติ invoice เป็นคนตรวจรับของด้วย นี่คือ finding ที่ชัดและร้ายแรง (segregation of duties ล้มเหลว) ต้องเข้ารายงานพร้อมวิเคราะห์ root cause; ส่วนเรื่องส่วนลดที่ไม่ได้ขออนุมัติ พอสืบแล้วพบว่าไม่ได้ทำเพื่อทุจริต แต่ทำตามคำสั่งผู้จัดการฝ่ายขายเพื่อเพิ่มยอด — ก็ยังต้องรายงานและแนะนำวิธีคุมการให้ส่วนลด แต่ระดับความหมายมันคนละเรื่องกัน ส่วนกรณีที่ประเมินว่าเป็นแค่ความผิดปกติชั่วคราว (anomaly) จากจังหวะแก้สัญญา อาจแค่แจ้ง management ไม่ต้องใส่ในรายงานฉบับสุดท้าย

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

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

⚠️ กับดัก: สี่ตัวล่อที่ต้องปฏิเสธเสมอเวลาโจทย์ถามเรื่องความร้ายแรง:

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

เชื่อม conclusion กลับไปที่ objectives เสมอ#

จุดจบของทั้งกระบวนการ engagement conclusion ต้องสรุปผลงาน เทียบกับ objectives ของงานตรวจ และ objectives ของ management แล้วก็ต้องสรุปดุลพินิจของผู้ตรวจต่อความร้ายแรงโดยรวมของ finding ทั้งหมดที่รวมกันแล้ว

conclusion อาจทำที่ระดับภาพรวมของงาน หรือลงลึกที่ระดับ process ย่อยก็ได้ และมักใช้เป็นสเกลให้คะแนน เช่น น่าพอใจ / น่าพอใจบางส่วน / ต้องปรับปรุง / ไม่น่าพอใจ สำหรับงานให้ความเชื่อมั่น (assurance engagement) conclusion ต้องมีดุลพินิจต่อความมีประสิทธิผลของ governance, risk management หรือ control ของสิ่งที่ถูกตรวจ

ที่ต้องระวังคือ ถ้า procedure ตาม work program ให้ข้อมูลไม่พอจะสรุป ผู้ตรวจ ต้องปรับแผนแล้วเทสต์เพิ่ม — engagement supervisor มีหน้าที่ยืนยันว่าข้อเท็จจริงและสถานการณ์ที่จำเป็นต่อการสรุปถูกบันทึกครบแล้ว อย่าฝืนสรุปทั้งที่หลักฐานยังไม่พอครับ

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

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

• finding = ข้อเท็จจริง (ทวนซ้ำได้, ไม่มีความเห็น) → conclusion = การตีความ ด้วยดุลพินิจ; conclusion = opinion (คู่คำที่แทนกันได้), finding = observation
• ลำดับตายตัว: บันทึก finding ลง workpapers → เทียบ condition กับ criteria → หา root cause → ประเมิน significance → สรุป conclusion → recommendation มาท้ายสุด
• ไม่มี criteria/เป้าหมาย = สรุปประสิทธิผลไม่ได้ → “ต้องการข้อมูลเพิ่ม”
• เช็คการปฏิบัติตาม ให้เทียบกับมาตรฐานบังคับโดยตรง ไม่ใช่ projection หรือความเห็น
• เจอปัญหา ตอบ “หาสาเหตุก่อน” เสมอ — ไม่ตักเตือน ไม่รายงานทันที ไม่ติดตั้ง control ก่อนสืบ
• significance วัดที่ ผลกระทบ + ความเสี่ยง ปฏิเสธ benchmark คู่แข่ง, ความรู้สึกคน, การนับดิบ, ความซ้ำในอดีต
• conclusion ต้องผูกกลับไปที่ objectives ของงานและ management เสมอ; หลักฐานไม่พอ = ปรับแผน เทสต์เพิ่ม อย่าฝืนสรุป

มี finding มี conclusion แล้ว ก็เหลืองานสองด้านสุดท้ายของหัวหน้าทีม ตอนหน้าเป็นตอนปิด Part 2 ครับ — supervision (มอบงาน รีวิว workpapers ประเมินทีม โดย CAE รับผิดชอบสูงสุดเสมอ) กับการสื่อสารผล (oral vs written, exit conference, เรื่องไหนต้อง escalate ถึงใคร) พร้อมรวบเส้นทางทั้ง Part ตอนถัดไป: supervision การสื่อสาร และปิด Part 2

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