ฉาก 1 — บริษัทเล็ก เถ้าแก่ตัดสินใจคนเดียว#

ลองนึกถึงโรงงานชิ้นส่วนยานยนต์ที่เถ้าแก่ก่อตั้งเมื่อ 20 ปีก่อน 8 คน

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

มีปัญหาเรื่อง “ระบบ IT” เหรอ? เถ้าแก่ก็โทรหาหลานชายที่เรียนคอม ให้มาช่วยลง Excel ใหม่ หรือเปลี่ยนคอมเก่า

ในยุคนี้ IT ไม่ใช่ “เรื่อง” มันเป็นเครื่องมือเล็กๆ ใช้แทนปากกาแทนกระดาษเฉยๆ ไม่มีใครต้องคิดเรื่อง “governance ของ IT” เพราะมันยังไม่ใหญ่พอจะ govern อะไร

ฉาก 2 — บริษัทโต IT ก็โตตาม (อย่างกระจัดกระจาย)#

10 ปีผ่านไป โรงงานเดิมที่มี 8 คน กลายเป็น 800 คน

ฝ่ายขายขอระบบ CRM เพื่อจัดการลูกค้า → IT จัดให้ ฝ่ายผลิตขอระบบ MES → IT จัดให้ ฝ่ายบัญชีอัปเกรดเป็น ERP → IT จัดให้ HR ใช้ระบบเงินเดือน cloud → IT จัดให้

ทีละโครงการ ทุกโครงการ make sense เป็นรายๆ ไปครับ แต่พอถอยห่างไปดูภาพใหญ่ เถ้าแก่ (ที่ตอนนี้เริ่มสับสน) เห็นว่า:

• ระบบ CRM กับ ERP ไม่เชื่อมกัน → ลูกค้าหนึ่งคนมี 3 ID ใน 3 ระบบ
• ฝ่ายผลิตซื้อ server ใหม่ทุกปี ไม่มีใครรู้ว่าของเก่าเอาไปไหน
• ระบบเงินเดือน cloud ตั้งอยู่ในต่างประเทศ — ข้อมูลพนักงานไทยอยู่ที่ไหน?
• ค่า IT ปีละหลายสิบล้าน แต่ไม่มีใครตอบได้ว่าค่าอะไรไปลงตรงไหน

นี่คือจุดที่ “IT” หยุดเป็นเครื่องมือแล้ว มันกลายเป็นสิ่งมีชีวิตที่ต้องมีคนกำกับ เถ้าแก่คนเดียวกำกับไม่ไหวแล้วครับ

ฉาก 3 — เถ้าแก่จ้าง CIO#

เถ้าแก่ตัดสินใจจ้างมืออาชีพมาดูแล IT ทั้งบริษัท → เกิดตำแหน่ง CIO (Chief Information Officer)

หลายคนอาจคุ้น CTO มากกว่า แต่ CTO กับ CIO เป็นคนละตำแหน่งนะครับ CTO เน้น technology direction (มักอยู่ใน tech company) ส่วน CIO ดู IT ทั้งบริษัท เป็น มาตรฐานที่ ISACA และ CRM ใช้ ในซีรีส์นี้ก็เลยใช้ CIO ตลอด

CIO มาแล้วก็เริ่มจัดระบบ:

• ตั้งทีม IT ของตัวเอง
• เขียน policy ใช้ระบบบริษัท
• จัดมาตรฐาน security
• วางแผน IT 3 ปีข้างหน้า

ดูเหมือนจบ แต่จริงๆ ไม่จบครับ เพราะ เถ้าแก่ยังไม่รู้ว่า CIO ทำงานดีหรือเปล่า เถ้าแก่อ่าน technical report ของ CIO ไม่ออก ถาม CIO ว่า “ระบบ IT บริษัทเรามี control พอมั้ย” คำตอบคือ “พอครับ” อ้าว แล้วจะรู้ได้ยังไงว่าจริง?

ฉาก 4 — เริ่มเข้าใจว่า “การจัดการ” กับ “การกำกับ” คนละเรื่อง#

นี่คือจุดที่ผมว่าน่าสนใจที่สุดของ Domain 2 เลย

Management = ทำงาน จัดการ ดำเนินการประจำวัน CIO เป็น Management

Governance = กำหนดทิศทาง อนุมัติงบ รับผิดชอบต่อผู้ถือหุ้น ดูว่า management ทำตามทิศทางจริงมั้ย board เป็น Governance

ลองเทียบกับโรงเรียน:

• Governance = คณะกรรมการโรงเรียน (กำหนดนโยบาย อนุมัติงบ ติดตามผลการเรียน)
• Management = ผู้อำนวยการ + ครู (สอนจริง จัดการรายวัน)

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

ในบริษัทก็เหมือนกัน CIO กำกับ IT ด้วยตัวเองไม่ได้ เพราะ CIO คือ management ที่ถูกกำกับ ผู้กำกับต้องเป็น board

นี่คือคอนเซ็ปต์ใหญ่ที่ ISACA เรียกว่า EGIT — Enterprise Governance of Information and Technology

ฉาก 5 — Stakeholder เริ่มถามคำถามที่ตอบยาก#

ระหว่างที่บริษัทโต stakeholder ภายนอกเริ่มเข้ามาด้วย:

• ผู้ถือหุ้นรายใหญ่ ถามในที่ประชุม: “บริษัทเรา invest IT ปีละ 50 ล้าน — ผลตอบแทนคืออะไร?”
• ลูกค้าองค์กร ส่งแบบสอบถามมา: “บริษัทท่านมี SOC 2 report มั้ย? PDPA compliance ทำถึงไหนแล้ว?”
• ธนาคาร (เวลาขอกู้) ขอ: “audit report ของระบบบัญชีปีที่แล้ว”
• regulator (ก.ล.ต., สำนักงาน PDPA, หน่วยงานเฉพาะวงการ) เริ่มมาตรวจ

เถ้าแก่ที่เคยตอบได้ทุกคำถามด้วยสามัญสำนึก เริ่มตอบไม่ได้ครับ คำตอบประมาณ “ผมเชื่อ CIO ว่าทุกอย่างเรียบร้อย” ใช้ไม่ได้กับ regulator

ฉาก 6 — ระบบ Governance ต้องเกิด#

ถึงจุดนี้ board (ที่เถ้าแก่ตั้งขึ้นมาตอนแปลงเป็นบริษัทมหาชน หรือตอนรับนักลงทุน) เริ่มเข้าใจว่าต้อง:

1. กำหนด direction — บริษัทอยากใช้ IT เพื่ออะไร? ความเสี่ยงด้าน IT รับได้แค่ไหน?
2. มอบอำนาจให้ management — CIO มีอำนาจอะไรบ้าง? ตัดสินใจคนเดียวได้ถึงระดับไหน?
3. ตรวจสอบ management — มีกลไกอะไรบ้างที่ทำให้รู้ว่า CIO ทำตามทิศทางจริง?
4. รับผิดชอบต่อ stakeholder — สามารถตอบ regulator, ผู้ถือหุ้น, ลูกค้า ได้

นี่คือ โครงกระดูกของ EGIT — ที่ Domain 2 ทั้ง domain จะมาเจาะรายละเอียด

Flow ของส่วนที่ 1#

1
บริษัทเล็ก → เถ้าแก่ตัดสินใจเอง
2
    ↓
3
บริษัทโต → IT เริ่มกระจัดกระจาย → เถ้าแก่จ้าง CIO
4
    ↓
5
CIO = Management → ใครกำกับ CIO?
6
    ↓
7
Board ต้องเข้ามา = Governance ต่างจาก Management
8
    ↓
9
Stakeholder ภายนอกเริ่มถาม → Governance ต้องตอบได้
10
    ↓
11
EGIT = ระบบ Governance ของ IT ทั้งบริษัท

มุม Auditor — สิ่งที่ Domain 2 จะมาเจาะ#

ขอแย้มเป็น roadmap คร่าวๆ ของ 8 ตอนถัดไป ไม่ต้องจำตอนนี้นะครับ แค่เห็นภาพว่ากำลังจะไปไหน:

Part A — Foundation (ตอน 15-17): กฎเกณฑ์, โครงสร้าง, ความเสี่ยง

• ตอน 15 — กฎที่ IT ต้องอยู่ใต้: laws ภายนอก → policies ภายใน → standards → procedures
• ตอน 16 — EGIT, Three Lines, SoD, Enterprise Architecture (บทใหญ่สุด — โครงสร้างของ governance ทั้งหมด)
• ตอน 17 — Risk Management, Privacy, Data Governance — บริหารความเสี่ยงและข้อมูล

Part B — Operational (ตอน 18-22): การจัดการประจำวัน

• ตอน 18 — IT Resource Management: คน, เงิน, การเปลี่ยนแปลงระบบ
• ตอน 19 — Vendor Management: outsourcing ที่ accountability ไม่หาย
• ตอน 20 — Performance Monitoring: KPI, KRI, KGI, PDCA, Balanced Scorecard
• ตอน 21 — Quality Assurance ของ IT
• ตอน 22 — ปิด Domain 2 + เกริ่น Domain 3

ทุกตอนคือ “เรื่องที่ auditor ตรวจ” เมื่อประเมิน governance ขององค์กร

Theme ที่จะเดินผ่านทั้ง Domain 2#

ระหว่างอ่าน Domain 2 ผมเห็น 3 theme ใหญ่ที่เดินผ่านทุก section ขอแย้มไว้ให้สังเกตตอนอ่าน:

Auditor ตรวจ Governance ยังไง?#

จาก D1 เรารู้แล้วว่า IS auditor ต้อง อิสระ จาก management และมี Audit Charter ที่ board approve (ดู ตอน 02)

ใน Domain 2 จะเห็นว่า “ความอิสระ” นั้นถูกจัดวางในโครงสร้างที่เรียกว่า Three Lines Model — มี First Line (operational management ที่ owns risk) กับ Second Line (risk + compliance functions) ทำงานอยู่ข้างหน้า และ Third Line (auditor) ที่ต้อง อิสระ จากทั้งสอง Line นั้น เดี๋ยวลงรายละเอียดในตอน 16A

เวลา auditor เข้าไปตรวจ governance ขององค์กร เขามองหา:

1. โครงสร้าง — มี board, audit committee, IT steering committee, audit function จริงมั้ย และต่อกันถูกหลักมั้ย
2. เอกสาร — Audit Charter (กฎบัตรการตรวจสอบ), Information Security Policy, ISP, Privacy Notice, Vendor contract — มีและเป็นปัจจุบัน
3. กระบวนการ — Risk assessment, change management, vendor monitoring — ทำตามที่เขียนจริงมั้ย
4. ผลลัพธ์ — KPI/KRI/KGI ขึ้นใน dashboard board มั้ย action จริงเกิดเมื่อตัวเลขเตือนมั้ย
5. การปรับปรุง — เจอปัญหาแล้วแก้และ tracked ไหม หรือเขียน finding ทิ้งไว้เฉยๆ

ทุกตอนใน Domain 2 จะวนเข้ามาตอบคำถาม 5 ข้อนี้