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

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

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

มาตรฐานและรายงานที่เราเปิดอ่านระบุอะไร

แหล่งแรกคือ NIST SP 800-53 Revision 5 ซึ่งเป็นชุดข้อกำหนดด้านการควบคุมความปลอดภัยและความเป็นส่วนตัวของหน่วยงานมาตรฐานสหรัฐฯ (ดูเอกสารของ NIST) เราเปิดอ่านข้อ AC-5 เรื่อง Separation of Duties หรือการแบ่งหน้าที่แล้ว ใจความของข้อนี้มีสองส่วน ส่วนแรกคือองค์กรต้องระบุและบันทึกว่าหน้าที่ใดต้องแยกจากกัน ส่วนที่สองคือต้องกำหนดสิทธิ์การเข้าถึงระบบให้สนับสนุนการแยกนั้น

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

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

แหล่งที่สองคือรายงาน Occupational Fraud 2024: A Report to the Nations ของ ACFE ซึ่งเป็นสมาคมผู้ตรวจสอบการทุจริต เราอ่านจากบทสรุปที่สำนักงานบัญชี Anchin เขียนไว้ ไม่ได้เปิดรายงานต้นฉบับของ ACFE (ดูบทสรุปของ Anchin) ตามบทสรุปนั้น รายงานศึกษา 1,921 คดีทุจริตภายในองค์กรที่ผู้ตรวจสอบการทุจริตสืบสวน ระหว่างมกราคม 2022 ถึงกันยายน 2023 ใน 138 ประเทศและเขตแดน มูลค่าความเสียหายตรงกลาง (median) อยู่ที่ 145,000 ดอลลาร์สหรัฐ และแผนทุจริตตรงกลางใช้เวลา 12 เดือนกว่าจะถูกพบ จุดอ่อนขององค์กรที่ถูกอ้างถึงมากที่สุดคือการไม่มีการควบคุมภายใน ซึ่งพบใน 32% ของคดี และอันดับสองคือการข้ามการควบคุมที่มีอยู่แล้ว ซึ่งพบใน 19%

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

เอกสารเหล่านี้ผูกพันใคร และไม่ผูกพันใคร

ข้อนี้ต้องพูดให้ชัด เพราะบางครั้งมีคนอ้างมาตรฐานต่างประเทศเหมือนเป็นกฎหมายไทย

NIST SP 800-53 เป็นเอกสารที่เขียนขึ้นสำหรับระบบของหน่วยงานรัฐบาลกลางสหรัฐฯ และใช้เป็นแนวอ้างอิงในหลายอุตสาหกรรม แต่ไม่ได้เป็นกฎหมายไทย และไม่ได้บังคับบริษัทไทยโดยตรง ส่วนรายงานของ ACFE เป็นงานศึกษาข้อมูลคดี ไม่ใช่ข้อบังคับของใครเลย เราไม่ได้อ้างว่ามีกฎหมายหรือประกาศของไทยฉบับใดกำหนดให้ต้องแบ่งหน้าที่ตามรูปแบบนี้ และเราไม่ได้ตรวจสอบว่าผู้สอบบัญชี หน่วยงานกำกับของคุณ หรือคู่ค้ารายใหญ่ ใช้เกณฑ์ใดกับองค์กรของคุณ ซึ่งเป็นเรื่องที่ควรถามโดยตรง

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

หน้าที่ที่ไม่ควรอยู่กับคนเดียว

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

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

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

• การรับสินค้ากับการสั่งซื้อหรือสั่งจ่าย คนที่ยืนยันว่าของมาถึงแล้วควรแยกจากคนที่ตัดสินใจซื้อและคนที่จ่ายเงิน เพราะการรับของคือหลักฐานว่าควรจ่ายหรือไม่

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

อีกข้อที่คำอธิบายของ AC-5 ระบุโดยตรงคือ คนที่ดูแลการเข้าถึงไม่ควรเป็นคนเดียวกับที่ดูแลบันทึกตรวจสอบ ถ้าคนที่ให้สิทธิ์ได้ลบหรือแก้ log ได้ด้วย ร่องรอยของการเปลี่ยนสิทธิ์ก็ไม่น่าเชื่อถือ เรื่องการเก็บ log และระยะเวลาที่ควรเก็บ เราเขียนไว้ในบทความเรื่องการเก็บ log และ audit trail

ตารางสิทธิ์หนึ่งหน้าที่เจ้าของงานเขียนเองได้

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

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

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

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

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

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

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

เมื่อคนย้ายตำแหน่งหรือลาออก

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

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

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

สิ่งที่ควรขอจากผู้พัฒนาตอนส่งมอบระบบ

ถ้าคุณกำลังซื้อหรือรับมอบระบบ ERP การแบ่งหน้าที่ควรอยู่ในเอกสารส่งมอบ ไม่ใช่เป็นสิ่งที่ค่อยมาแก้หลังใช้งานจริง เราแนะนำให้ขอสิ่งเหล่านี้เป็นลายลักษณ์อักษร

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

• การยืนยันว่าระบบกันการอนุมัติรายการของตัวเองได้หรือไม่ และกันด้วยวิธีใด เป็นการตั้งค่าที่ปิดได้หรือเป็นกฎที่ฝังในระบบ

• รายงานสิทธิ์ผู้ใช้ที่ดึงได้เอง โดยไม่ต้องขอผู้พัฒนาทุกครั้ง และดึงได้ว่าใครมีสิทธิ์ใด ใครเปลี่ยนสิทธิ์เมื่อไร

• รายชื่อบัญชีที่มีสิทธิ์ผู้ดูแลระบบ รวมบัญชีของผู้พัฒนา และเงื่อนไขว่าจะปิดหรือลดสิทธิ์เมื่อสิ้นสุดโครงการเมื่อไร

• บันทึกการเปลี่ยนสิทธิ์และการแก้ข้อมูลหลัก เช่น ข้อมูลผู้ขายและบัญชีธนาคาร ที่ผู้ดูแลระบบลบหรือแก้ไม่ได้

• ขั้นตอนเมื่อมีบัญชีที่ต้องปิดทันที ใครสั่งได้ ใครทำได้ และใช้เวลานานแค่ไหน

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

เรื่องที่ไม่ควรทำเพียงเพราะอ่านบทความนี้

ในมุมของเรา มีสามเรื่องที่ไม่ควรรีบทำ

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

ข้อจำกัดที่ต้องบอกตรง ๆ

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

อีกข้อ เรายืนยันได้เฉพาะสิ่งที่เปิดอ่านจริง คือข้อ AC-5 และ AC-6 ของ NIST SP 800-53 Revision 5 และตัวเลขจากบทสรุปรายงาน ACFE ที่ Anchin เขียน เรายังไม่ได้เปิดรายงานต้นฉบับของ ACFE เราไม่ทราบว่าระบบ ERP ยี่ห้อใดตั้งค่ากันอนุมัติรายการตัวเองไว้เป็นค่าเริ่มต้น และไม่ทราบว่าองค์กรของคุณถูกกำหนดเกณฑ์ใดจากผู้สอบบัญชีหรือหน่วยงานกำกับ ควรถามบุคคลเหล่านั้นโดยตรง

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

ข้อโต้แย้งที่ได้ยินบ่อย

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

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

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

จะเริ่มตรงไหน

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

2. เขียนคู่หน้าที่ที่ห้ามรวมกันสามถึงห้าคู่ เริ่มจากการเพิ่มผู้ขายกับการสั่งจ่าย และการออกใบสั่งซื้อกับการอนุมัติ

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

4. ตั้งรอบทบทวนสิทธิ์ครั้งแรก ส่งรายการให้หัวหน้าสายงานยืนยัน และบันทึกวันที่ ผู้ยืนยัน และสิ่งที่เปลี่ยน

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

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

สรุป

NIST SP 800-53 ข้อ AC-5 ให้องค์กรระบุหน้าที่ที่ต้องแยกจากกัน และตั้งสิทธิ์ในระบบให้เป็นไปตามนั้น รายงานของ ACFE ฉบับปี 2024 ตามบทสรุปของ Anchin ชี้ว่าการไม่มีการควบคุมภายในและการข้ามการควบคุมเป็นจุดอ่อนสองอันดับแรกในคดีที่ศึกษา ทั้งสองแหล่งไม่ใช่กฎหมายไทย แต่ให้ภาษากลางที่ใช้คุยกับผู้ตรวจสอบและผู้พัฒนาได้ ถ้าจะหยิบไปทำอย่างเดียวจากบทความนี้ ให้เขียนตารางหนึ่งหน้าว่าใครเพิ่มผู้ขาย ใครอนุมัติ ใครสั่งจ่าย แล้วเทียบกับรายงานสิทธิ์จริงของระบบ

หากต้องการคุยรายละเอียดของโครงการ ติดต่อเราได้ที่ 088-983-9386 หรืออีเมล [email protected] สำนักงานของเราอยู่ที่บางกะปิ กรุงเทพฯ สำหรับองค์กรที่ยังอยู่ระหว่างร่างขอบเขตงาน เรายินดีนัดคุยเพื่อทำความเข้าใจโจทย์ก่อน โดยยังไม่ต้องมีเอกสารครบ และหากคุยแล้วพบว่าโจทย์ยังไม่ถึงเวลาต้องพัฒนาระบบใหม่ เราจะบอกตรง ๆ เพราะการเริ่มโครงการผิดจังหวะ มีต้นทุนสูงกว่าการรออีกหนึ่งไตรมาส