ฉาก 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
บริษัทเล็ก → เถ้าแก่ตัดสินใจเอง
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 นั่งอยู่ที่ไหนของ org chart — Third Line ของ Three Lines Model (ดู ตอน 02)

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

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

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 ข้อนี้