ITGC บริษัทลูกในไทย แนวทางการควบคุมภายในด้านไอที 2026

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

การแก้ไขระบบการรายงานการควบคุมภายในเปลี่ยนเงื่อนไขตั้งต้นของการรับมือควบคุมไอที

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

ช่วงเวลาประกาศและช่วงเวลาบังคับใช้การแก้ไข

การแก้ไขมาตรฐานและมาตรฐานการปฏิบัติของระบบการรายงานการควบคุมภายในถูกประกาศโดยสภาที่ปรึกษาการบัญชีธุรกิจ (Business Accounting Council) เมื่อวันที่ 7 เมษายน 2023 มีผลบังคับใช้ตั้งแต่ปีงบการเงินที่เริ่มต้นตั้งแต่วันที่ 1 เมษายน 2024 เป็นต้นไป หากเป็นบริษัทที่ปิดงบเดือนมีนาคม ปีงบการเงินมีนาคม 2025 จะเป็นรอบแรกที่ถูกบังคับใช้ เนื่องจากจังหวะการบังคับใช้ครั้งแรกจะต่างกันไปตามรอบปิดงบของแต่ละบริษัท จึงขอให้ตรวจสอบก่อนเป็นอันดับแรกว่าบริษัทของท่านถูกบังคับใช้แล้วหรือกำลังจะถูกบังคับใช้

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

วัตถุประสงค์เปลี่ยนจาก “ความน่าเชื่อถือของรายงานทางการเงิน” เป็น “ความน่าเชื่อถือของรายงาน”

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

อย่างไรก็ตาม ตรงนี้มีข้อจำกัดสำคัญอยู่ เนื่องจากกฎหมายการซื้อขายหลักทรัพย์ทางการเงิน (Financial Instruments and Exchange Act) เองยังไม่ได้ถูกแก้ไข การควบคุมภายในที่รายงานการควบคุมภายในครอบคลุมจึงยังคงเป็น “การควบคุมภายในที่เกี่ยวข้องกับรายงานทางการเงิน” เหมือนเดิม กล่าวคือขอบเขตของการประเมินและการรายงานไม่ได้ขยายไปครอบคลุมข้อมูลที่ไม่ใช่การเงินทั้งหมดในคราวเดียว

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

การนำเกณฑ์ตัวเลขมาใช้แบบอัตโนมัติถูกปฏิเสธ

ในทางปฏิบัติจริง จุดนี้คือส่วนที่ส่งผลกระทบมากที่สุด แต่เดิมเมื่อจะกำหนดขอบเขตการประเมิน มีการใช้เกณฑ์ตัวเลข เช่น “ประมาณ 2 ใน 3 ของยอดขายรวมเป็นต้น” หรือ “3 บัญชีคือยอดขาย ลูกหนี้การค้า และสินค้าคงคลัง” เป็นกฎเกณฑ์โดยพฤตินัยมาโดยตลอด แต่ในการแก้ไขครั้งนี้ได้ระบุอย่างชัดเจนว่าไม่ควรนำเกณฑ์ตัวเลขเหล่านี้มาใช้แบบอัตโนมัติ และเปลี่ยนทิศทางไปสู่การกำหนดขอบเขตแบบอิงความเสี่ยง (risk-based) โดยพิจารณาความสำคัญเชิงคุณภาพประกอบ

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

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

เนื้อหาที่ต้องระบุในรายงานเพิ่มขึ้น

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

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

ขนาดของบริษัทที่อยู่ในขอบเขต และความหนักเบาของบทลงโทษหากฝ่าฝืน

ขอบเขตของระบบนี้คือบริษัทจดทะเบียนในตลาดหลักทรัพย์ประมาณ 3,900 บริษัท และบริษัทลูกที่รวมงบการเงิน หากบริษัทลูกในไทยอยู่ในขอบเขตการรวมงบการเงิน ก็ไม่ได้อยู่นอกระบบนี้แต่อย่างใด และหากรายงานการควบคุมภายในมีการระบุข้อมูลอันเป็นเท็จ กฎหมายกำหนดบทลงโทษต่อบุคคลไว้ว่าจำคุกไม่เกิน 5 ปี หรือปรับไม่เกิน 5,000,000 เยน หรือทั้งจำทั้งปรับ

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

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

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

ความสัมพันธ์ระหว่าง ITGC กับการควบคุมกระบวนการประมวลผลด้านไอที

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

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

เรียบเรียงคำศัพท์ ขอบเขตของ ITGC กับ “ชุดเอกสาร 3 รายการ” เป็นคนละเรื่องกัน

ขอปิดจุดที่หน้างานมักสับสนไว้ล่วงหน้าก่อน ในบริบทของการควบคุมภายใน หากพูดถึง “ชุดเอกสาร 3 รายการ” โดยทั่วไปจะหมายถึงเอกสาร 3 ชนิด คือ คำอธิบายกระบวนการทำงาน (business description) ผังงาน (flowchart) และตารางความเสี่ยงและการควบคุม (RCM) ในขณะที่การแบ่งประเภทเมื่อพูดถึงองค์ประกอบของ ITGC จะหมายถึงการแบ่งขอบเขต เช่น การบริหารจัดการสิทธิ์การเข้าถึง การบริหารจัดการการเปลี่ยนแปลง และการบริหารจัดการการดำเนินงาน ขึ้นอยู่กับแหล่งข้อมูล บางแหล่งจะเพิ่มการบริหารจัดการผู้รับจ้างภายนอกเข้าไปด้วยเป็น 4 ขอบเขต

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

การบริหารจัดการสิทธิ์การเข้าถึง

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

โดยเฉพาะเจาะจง การควบคุมต่อไปนี้จะถูกนับเป็นขอบเขต

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

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

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

การบริหารจัดการการเปลี่ยนแปลง

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

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

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

การบริหารจัดการการดำเนินงาน

การบริหารจัดการการดำเนินงานคือการควบคุมเพื่อให้ระบบทำงานได้อย่างมั่นคงต่อเนื่อง องค์ประกอบหลักคือการสำรองข้อมูล (backup) การเฝ้าติดตามงานประมวลผล (job monitoring) และขั้นตอนการรับมือเมื่อเกิดเหตุขัดข้อง

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

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

ขอบเขตที่ 4 การบริหารจัดการผู้รับจ้างภายนอก

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

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

เมื่อเรียบเรียงขอบเขตของ ITGC จะได้ดังนี้

ท่านคงสังเกตเห็นว่าคำว่า “หลักฐาน” ปรากฏขึ้นซ้ำ ๆ หลายครั้ง ขอให้เข้าใจว่างานปฏิบัติจริงของการจัดวาง ITGC นั้น การเก็บรักษาหลักฐานให้สามารถแสดงย้อนหลังได้ว่าการควบคุมทำงานจริงมีความสำคัญพอ ๆ กับงานออกแบบการควบคุมเอง

5 เหตุผลที่การจัดวาง ITGC ในบริษัทลูกในไทยดำเนินไปได้ยาก

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

สำรวจข้อจำกัดเฉพาะของพื้นที่ก่อนเป็นอันดับแรก

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

เมื่อเรียบเรียงประเด็นเฉพาะของบริษัทลูกในไทย จะได้ดังนี้

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

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

จะพึ่งพาผลการประเมินของบริษัทแม่ได้มากน้อยแค่ไหน

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

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

วิธีดำเนินการจัดวาง ITGC 5 ขั้นตอน

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

แต่ละขั้นตอนต้องทำอะไรบ้าง

เรียบเรียงงานในแต่ละขั้นตอนดังนี้

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

ลำดับการเริ่มลงมือที่สมจริง

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

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

จะเสริมโครงสร้างการตรวจสอบภายในอย่างไร

คงมีฐานปฏิบัติการจำนวนไม่น้อยที่ในพื้นที่ไม่มีฟังก์ชันตรวจสอบภายใน หรือมีแต่ต้องทำงานควบตำแหน่งจนดูแลไม่ทัน ในประเด็นนี้ คำแนะนำจากบริษัทที่ให้บริการเอาต์ซอร์สและโคซอร์สงานตรวจสอบภายในโดยเฉพาะ ได้แสดงให้เห็นว่าด้วยภูมิหลังที่การขยายธุรกิจไปต่างประเทศของบริษัทต่าง ๆ มีความก้าวหน้าขึ้น และความเสี่ยงของฐานปฏิบัติการต่างประเทศเพิ่มขึ้นทุกปี จึงมีโครงสร้างที่ร่วมมือกับผู้เชี่ยวชาญในพื้นที่เพื่อรับมือกับการตรวจสอบที่รวมถึงบริษัทลูกในต่างประเทศด้วย การรู้ไว้ว่ามีรูปแบบโคซอร์ส (co-sourcing) ที่แบ่งงานเพียงบางส่วนให้ผู้เชี่ยวชาญภายนอกรับผิดชอบ จะช่วยเปิดทางเลือกให้กว้างขึ้น

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

จะประมาณการค่าใช้จ่ายและปริมาณงานของการจัดวาง ITGC อย่างไร

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

ระดับราคาที่เปิดเผยต่อสาธารณะ แต่ต้องระวังขอบเขตที่ครอบคลุม

คำอธิบายที่เรียบเรียงระดับค่าใช้จ่ายในการสร้างธรรมาภิบาลด้านไอที แสดงระดับราคาแยกตามขั้นตอนไว้ดังนี้

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

ปัจจัยที่ทำให้ค่าใช้จ่ายผันแปรมี 4 ข้อ คือ จำนวนกระบวนการเป้าหมาย จำนวนฐานปฏิบัติการ ระดับของผู้รับงาน และความลึกของผลงานที่ส่งมอบ สำหรับผู้รับงาน มีการแสดงความแตกต่างไว้ว่ากลุ่มสำนักงานสอบบัญชีขนาดใหญ่จะเริ่มต้นที่ 5,000,000 เยนขึ้นไป บริษัทที่ปรึกษาขนาดกลางเริ่มต้นที่ 2,000,000 ถึง 3,000,000 เยน ส่วนบริษัทอิสระหรือรูปแบบที่ร่วมเดินเคียงข้างไปจนถึงขั้นตอนการนำไปปฏิบัติจริง ช่วงราคาจะยิ่งกว้างขึ้นไปอีก คำอธิบายเดียวกันนี้ยังนำเสนอตัวอย่างการคำนวณสำหรับกรณีที่มีพนักงาน 300 คน ฝ่ายไอที 10 คน และจำกัดขอบเขตไว้ที่ 15 กระบวนการของ COBIT ว่าจะอยู่ที่ประมาณ 13,000,000 เยน ระยะเวลาประมาณ 12 เดือน แต่มีการระบุไว้อย่างชัดเจนว่านี่เป็นตัวเลขประมาณการสมมติ ไม่ใช่ตัวเลขของโครงการจริง

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

กรณีตัวอย่างปริมาณงานภายในบริษัท การประมาณการชั่วคราวบนสมมติฐานที่ตั้งไว้

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

เงื่อนไขที่ตั้งเป็นสมมติฐานมีดังนี้

• บริษัทลูกในไทย 1 ฐานปฏิบัติการ ขนาดพนักงาน 100 ถึง 300 คน
• ระบบเป้าหมายการประเมินเป็นระบบเฉพาะของพื้นที่ประมาณ 3 ระบบ ส่วนระบบที่ใช้ร่วมกับสำนักงานใหญ่ให้ถือว่าพึ่งพาผลการประเมินของบริษัทแม่ได้
• มีเจ้าหน้าที่ไอทีในพื้นที่ 2 คน และผู้จัดการชาวญี่ปุ่น 1 คนที่สามารถเข้ามาเกี่ยวข้องได้
• มีแม่แบบระเบียบเป็นภาษาญี่ปุ่นอยู่ที่สำนักงานใหญ่แล้ว แต่ฉบับพื้นที่ต้องสร้างขึ้นใหม่ตั้งแต่ศูนย์

ปริมาณงานโดยประมาณของปีแรกและปีที่ 2 เป็นต้นไปภายใต้สมมติฐานนี้มีดังนี้

เมื่อรวมทั้งหมดแล้ว ปีแรกจะอยู่ที่ประมาณ 60 ถึง 100 คน-วัน และปีที่ 2 เป็นต้นไปจะอยู่ที่ประมาณ 30 ถึง 50 คน-วัน หากเป็นฐานปฏิบัติการที่มีเจ้าหน้าที่ไอที 2 คน คำนวณแล้วปีแรกจะถูกดึงเวลาทำงานไปกับการรับมือระบบนี้ประมาณ 10 ถึง 20 เปอร์เซ็นต์ของเวลาทำงานทั้งปี ถือเป็นงานที่เพิ่มเข้ามาซ้อนทับกับงานดำเนินงานประจำวันและการรับมือเหตุขัดข้องที่มีอยู่แล้ว ไม่ใช่ภาระที่เบาเลย

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

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

ประเด็นที่มักถูกทักท้วงในการรับมือกับสำนักงานสอบบัญชี

แม้แต่ฐานปฏิบัติการที่จัดวางเสร็จเรียบร้อยแล้ว ก็ยังอาจได้รับข้อทักท้วงในการตรวจสอบได้ หากรู้รูปแบบที่พบบ่อยไว้ล่วงหน้า ก็สามารถแก้ไขปิดจุดเหล่านั้นได้ก่อน

รูปแบบทั่วไปของข้อทักท้วง

ข้อทักท้วงที่พบซ้ำ ๆ ในหน้างานมีดังนี้

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

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

สร้างสภาพที่สามารถอธิบายได้

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

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

ปรับคำศัพท์ให้ตรงกันระหว่างพื้นที่กับสำนักงานใหญ่

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

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

คำถามที่พบบ่อย

การจัดวาง ITGC มีค่าใช้จ่ายเท่าไร

ระดับราคาในประเทศญี่ปุ่นสำหรับการสร้างธรรมาภิบาลด้านไอทีอยู่ที่ การประเมินสถานะปัจจุบัน 2,000,000 ถึง 5,000,000 เยน การสร้างและนำไปใช้ 5,000,000 ถึง 15,000,000 เยน และการสนับสนุนให้เกิดผลถาวร 1,000,000 ถึง 3,000,000 เยน อย่างไรก็ตาม นี่ไม่ใช่จำนวนเงินที่จำกัดเฉพาะ ITGC แต่เป็นค่าใช้จ่ายในการสร้างธรรมาภิบาลด้านไอทีทั้งชุด โดย ITGC เป็นเพียงส่วนหนึ่งของสิ่งนั้น หากนำมาใช้ตรง ๆ จะได้ตัวเลขที่สูงเกินจริง

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

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

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

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

การควบคุมทั่วไปด้านไอทีต้องประเมินทุกปีหรือไม่

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

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

สรุป

ขอเรียบเรียงประเด็นที่ต้องจับให้ได้ในงานปฏิบัติจริงของบริษัทลูกในไทยเกี่ยวกับการรับมือด้านการควบคุมไอทีของการควบคุมภายใน ดังนี้

• การแก้ไขระบบถูกประกาศเมื่อวันที่ 7 เมษายน 2023 มีผลบังคับใช้ตั้งแต่ปีงบการเงินที่เริ่มต้นตั้งแต่วันที่ 1 เมษายน 2024 บริษัทที่ปิดงบเดือนมีนาคมจะเริ่มถูกบังคับใช้ครั้งแรกในปีงบการเงินมีนาคม 2025
• วัตถุประสงค์ที่กรอบพื้นฐานของการควบคุมภายในกำหนดไว้เปลี่ยนจาก “ความน่าเชื่อถือของรายงานทางการเงิน” เป็น “ความน่าเชื่อถือของรายงาน” และมีการระบุการประเมินความเสี่ยงจากการทุจริตไว้อย่างชัดเจน แต่การควบคุมภายในที่รายงานการควบคุมภายในครอบคลุมยังคงเป็นการควบคุมภายในที่เกี่ยวข้องกับรายงานทางการเงินเช่นเดิม
• การนำเกณฑ์ตัวเลขของขอบเขตการประเมินมาใช้แบบอัตโนมัติถูกปฏิเสธ เปลี่ยนไปสู่การตัดสินใจแบบอิงความเสี่ยงตามความสำคัญเชิงคุณภาพ ฐานปฏิบัติการที่มีสัดส่วนยอดขายน้อยก็อาจถูกนับเป็นขอบเขตได้เช่นกัน
• การประเมินแบบหมุนเวียนของการควบคุมกระบวนการประมวลผลด้านไอทีก็ไม่ควรกำหนดด้วยจำนวนปีแบบอัตโนมัติเช่นกัน ตั้งอยู่บนสมมติฐานว่าต้องหารือความถี่ร่วมกับผู้สอบบัญชี
• ขอบเขตของ ITGC มองเป็น 4 หมวด คือการบริหารจัดการสิทธิ์การเข้าถึง การบริหารจัดการการเปลี่ยนแปลง การบริหารจัดการการดำเนินงาน และการบริหารจัดการผู้รับจ้างภายนอกที่เพิ่มเข้ามา สำหรับฐานปฏิบัติการในไทยที่พึ่งพาผู้รับจ้างสูง หมวดที่ 4 มีความสำคัญมาก
• วิธีดำเนินการเรียงลำดับดังนี้ กำหนดขอบเขต ออกแบบและจัดทำเอกสารการควบคุม การประเมินสถานะการจัดวางระบบควบคุม การประเมินสถานะการปฏิบัติตามระบบควบคุม และการแก้ไขข้อบกพร่อง หากแจกจ่ายแบบฟอร์มหลักฐานก่อนแล้วเริ่มหมุนการดำเนินงาน ปีแรกจะเบาแรงขึ้น
• ระดับราคาที่เปิดเผยต่อสาธารณะเป็นของการสร้างธรรมาภิบาลด้านไอทีทั้งชุด หากนำมาใช้กับ ITGC เพียงอย่างเดียวจะได้ตัวเลขที่สูงเกินจริง เนื่องจากไม่พบสถิติที่เปิดเผยต่อสาธารณะของระดับราคาในพื้นที่ไทย จึงควรตรวจสอบด้วยใบเสนอราคาจากหลายบริษัท

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

ข้อมูลอ้างอิง

• ประเด็นสำคัญของการแก้ไขระบบการรายงานการควบคุมภายใน โดย Issoh (ภาษาญี่ปุ่น)
• การทบทวนระบบการรายงานการควบคุมภายในและการรับมือของบริษัท โดย Nikkei xTECH (ภาษาญี่ปุ่น)
• คำอธิบายการแก้ไขมาตรฐานการควบคุมภายใน โดย EY Japan (ภาษาญี่ปุ่น)
• ระบบการรายงานการควบคุมภายใน (J-SOX) คืออะไร ภาพรวมมาตรฐานที่แก้ไขและงานปฏิบัติที่เกี่ยวข้อง โดย THE FINANCE (ภาษาญี่ปุ่น)
• การเอาต์ซอร์สและโคซอร์สงานตรวจสอบภายใน โดย PwC Japan (ภาษาญี่ปุ่น)
• การแก้ไขระบบการรายงานการควบคุมภายในและช่วงเวลาบังคับใช้ โดย IPO Support Media (ภาษาญี่ปุ่น)
• ระดับค่าใช้จ่ายในการสร้างธรรมาภิบาลด้านไอที โดย GXO (ภาษาญี่ปุ่น)
• 4 ขอบเขตของการควบคุมทั่วไปด้านไอที (ITGC) และงานปฏิบัติด้านการประเมิน โดย TOKIUM (ภาษาญี่ปุ่น)
• การรับมือ J-SOX ความรู้พื้นฐานของการประเมินการควบคุมภายในในบริษัทลูกต่างประเทศ โดย AIM Consulting (ภาษาญี่ปุ่น)