การแบ่งแยกหน้าที่ในระบบ IT (Segregation of Duties) — ความรู้เบื้องต้นที่นักบัญชีควรรู้

SoD คืออะไร และทำไมนักบัญชีต้องรู้

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

Segregation of Duties (SoD) เป็นหลักการเรียบง่ายแต่ทรงพลังครับ ในทุกกระบวนการควรมีอย่างน้อย 2 คนที่ตรวจสอบถ่วงดุลกัน ไม่ใช่ปล่อยให้คนเดียว “ทำเอง ตรวจเอง อนุมัติเอง” สำหรับนักบัญชี เรื่องนี้สำคัญ เพราะข้อมูลบัญชี-การเงินถูกบันทึก ประมวลผล และจัดเก็บในระบบ IT ทั้งสิ้น หากคนที่แก้ไขข้อมูลในระบบเป็นคนเดียวกับคนที่อนุมัติหรือตรวจสอบ ตัวเลขในงบการเงินก็อาจถูกบิดเบือนได้โดยไม่มีใครรู้ การเข้าใจ SoD จึงช่วยให้นักบัญชีตั้งคำถามที่ถูกต้องกับฝ่าย IT และมองเห็นจุดเสี่ยงของข้อมูลที่ตัวเองรับผิดชอบ

หลัก Maker-Checker — หัวใจของการแบ่งแยกหน้าที่

หลักการง่ายๆ คือ แยก “คนทำ” ออกจาก “คนตรวจ” ให้ชัดเจน

แนวคิดที่เข้าใจง่ายที่สุดของ SoD คือ Maker-Checker:

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

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

4 จุดในระบบ IT ที่ต้องแยกหน้าที่

ตอบสั้น ๆ คือ พัฒนา-ทดสอบ, แก้ไข-อนุมัติ, ให้สิทธิ์-ตรวจ Log, สำรอง-กู้คืน

นี่คือ 4 จุดวิกฤตที่ผู้ตรวจสอบ IT ดูเป็นอันดับแรก อธิบายแบบเข้าใจง่ายสำหรับนักบัญชี:

• การพัฒนาโปรแกรม ≠ การทดสอบ (Dev vs Test) คนเขียนโปรแกรมมักมองข้ามข้อผิดพลาดของตัวเอง (เหมือนเราตรวจคำผิดงานเขียนตัวเองไม่ค่อยเจอ) จึงต้องมีทีมทดสอบอิสระ ถ้าไม่แยก ข้อผิดพลาดอาจหลุดเข้าระบบจริง หรือเลวร้ายกว่านั้นคือมีคนแอบฝัง “ช่องลับ” ไว้แก้ข้อมูลภายหลัง
• การเปลี่ยนแปลงโปรแกรม ≠ การอนุมัติ (Change vs Approval) ทุกการแก้ไขระบบที่ใช้งานจริงต้องผ่านการอนุมัติจากคนอื่นก่อน ไม่มีใครควรแก้เองแล้วกดอนุมัติเอง ถ้าไม่แยก คนอาจแอบแก้ระบบเพื่อเอื้อประโยชน์ตัวเอง เช่น เปลี่ยนสูตรคำนวณค่าคอมมิชชัน แล้วอนุมัติเองทันที โดยฝ่ายบริหารไม่รู้
• การให้สิทธิ์ผู้ใช้ ≠ การตรวจสอบ Log (Access vs Log Review) Log (บันทึกการใช้งานระบบ) จะไร้ประโยชน์ทันที ถ้าคนที่ดูแล Log เป็นคนเดียวกับคนที่ให้สิทธิ์เข้าถึงระบบ เพราะอาจ “ทำผิดแล้วลบหลักฐาน” คือแอบให้สิทธิ์ตัวเองเข้าไปขโมยข้อมูล แล้วลบ Log ทิ้ง
• การสำรองข้อมูล ≠ การตรวจสอบการกู้คืน (Backup vs Recovery) หลายองค์กรสำรองข้อมูลทุกวัน แต่พอเกิดวิกฤตกลับกู้คืนไม่ได้ เพราะไม่เคยมีคนจากภายนอกมาทดสอบว่าไฟล์สำรองใช้งานได้จริง — Backup ที่ไม่เคยทดสอบกู้คืน คือ “ภาพลวงตา” ของความปลอดภัยครับ

ถ้าองค์กรเล็ก แยกคนไม่ได้จริง ทำอย่างไร

ไม่มีปัญหาครับ เราควรใช้ “มาตรการชดเชย” (Compensating Control) แทนชั่วคราว

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

ข้อควรระวังที่ผมเจอเอง

1. หลายๆ คนคิดว่า SoD เป็นเรื่องของ IT อย่างเดียว จริง ๆ มันคือเรื่องเดียวกับการควบคุมภายในทางบัญชี (แยกคนบันทึก-คนอนุมัติ-คนเก็บเงิน) เพียงแต่ย้ายไปอยู่ในระบบ ไว้ผมจะมาเขียนเรื่องการแบ่งแยกหน้าที่ในระบบการทำงานอื่นๆ เพื่อให้นักบัญชีเข้าใจมากขึ้นครับ
2. ให้สิทธิ์ Admin กว้างเกินจำเป็น พนักงานคนเดียวมีสิทธิ์ทั้งแก้ข้อมูลและอนุมัติ เพราะ “ความสะดวก” — เป็นจุดเริ่มของความเสี่ยงที่พบบ่อยที่สุด
3. มี Log แต่ไม่มีใครดู เก็บ Log ไว้เฉย ๆ โดยไม่มีคนอิสระ หรือผู้ตรวจสอบมาสอบทาน เท่ากับไม่มี Log คิดง่ายๆ ครับ มี Log แต่ไม่เคยเปิดดูเลย ไม่มีประโยชน์ครับ
4. Backup ที่ไม่เคยทดสอบกู้คืน มั่นใจว่าสำรองข้อมูลแล้วปลอดภัย แต่ไม่เคยลอง Restore จริง เป็นความชะล่าใจเกินไปครับ พอเกิดเหตุฉุกเฉินแล้ว Restore หรือกู้คืนข้อมูลไม่ได้ ส่งผลกระทบต่อการทำธุรกิจได้เลยนะ
5. องค์กรเล็กใช้ Compensating Control แล้วคิดว่าจบ ต้องบันทึกหลักฐานการ Review จริง ไม่ใช่แค่บอกปากเปล่าว่าผู้บริหารดูแล้ว