IS Strategy คืออะไร?#

ในยุคก่อน board + senior management ตัดสินใจเรื่อง IT แบบ ad-hoc ปีต่อปี ส่วน day-to-day ก็ปล่อยให้ functional management

ปัจจุบันใช้ approach นี้ไม่ได้แล้วครับ เพราะ:

• บริษัทต้อง depend on IS สำหรับ daily operations
• IS disasters (natural / cyber attack / financial system failure) มี impact สูงและเร็ว
• IT ไม่ใช่แค่ enabler — มันเป็น integral part ของ strategy

IS Strategy = การ align IT capabilities + investments กับ enterprise’s long-term direction เป็น component ของ governance structure ไม่ใช่งาน standalone ของ IT

Strategic Planning Process#

Strategic planning for IS management = top management กำหนดว่า IT จะ support enterprise goals ยังไง

ขั้นตอน:

1. ระบุ business objectives ระยะยาว
2. Assess current IT capability — system portfolio (functional fit, age, risk), infrastructure, support processes
3. Define future-state IT — ระบบใหม่ที่ต้องการ + ระบบเก่าที่ต้อง decommission
4. Cost projection — ค่าใช้จ่ายของ current state + planned initiatives
5. Action plan — milestones, resources, ownership

ที่สำคัญ: Strategic plan ต้อง synchronized กับ business strategy ถ้า IT plan วิ่งคนละทางกับ business plan = governance failure

Frequency: ทำบ่อยแค่ไหน?#

แบบดั้งเดิม — เขียนแผน 3-5 ปี แล้วทบทวนทุก 5 ปี

ปัญหาคือ world เปลี่ยนเร็วกว่าแผน 5 ปีจะ obsolete ก่อนถึงปลายอีก ตัวอย่าง บริษัทที่เขียน “5-year cloud migration plan” ในปี 2018 → COVID เกิดปี 2020 → ทุก assumption ของแผนต้อง redo

วิธีใหม่:

Agile Strategy / Rolling Strategy Planning

• ปรับแผนต่อเนื่อง — short cycle (รายไตรมาส / ราย 6 เดือน)
• Strategic plan = living document ไม่ใช่ frozen document
• เหมาะกับ industry ที่ technology + competitive landscape เปลี่ยนเร็ว

ที่ exam ถาม: “ในธุรกิจที่ technology landscape เปลี่ยนเร็ว — strategic planning frequency ที่เหมาะ?”

• หลอก: 5-year cycle เป็นมาตรฐาน
• จริง: agile/rolling planning — ปรับต่อเนื่อง

มุม IS Auditor#

Auditor ดูอะไรเมื่อตรวจ strategic planning?

• IT plan synchronized กับ business plan มั้ย
• CIO หรือ senior IT มีบทบาทใน business strategy creation มั้ย ถ้า IT ถูกตัดออกจาก business strategy meeting = red flag
• Plan ครอบคลุม current portfolio + future initiatives ครบมั้ย
• Risk assessment integrated ในกระบวนการ planning มั้ย
• Monitoring + evaluation ของ plan execution ทำต่อเนื่องมั้ย

IT Strategy Committee#

• อยู่ระดับ Board — สมาชิก = board members + specialists + invited advisors
• Authority: Advise the board and management on IT strategy
• Focus: current + future strategic IT issues
• ขอบเขต: ระยะยาว 3-5 ปี
• ไม่ตัดสินใจเอง — แค่ advise board

ความรับผิดชอบหลัก (ตาม CRM):

• Relevance ของ IT developments จากมุม business
• Alignment ของ IT กับ business direction
• Achievement ของ strategic IT objectives
• Availability ของ IT resources, skills, infrastructure
• Optimization ของ IT costs (รวม external sourcing)
• Risk, return, competitive aspects ของ IT investments
• Progress ของ major IT projects
• Contribution ของ IT ต่อ business
• IT risk exposure (รวม compliance risk)
• Direction สำหรับ management ในเรื่อง IT strategy

ตัวอย่างประเด็นที่คุย: “บริษัทควร migrate ไป cloud ภายใน 3 ปีมั้ย”, “ควร invest ใน AI ไหม”, “Risk appetite ของ IT spending ระดับไหน”

IT Steering Committee#

• อยู่ระดับ Management — สมาชิก = sponsoring executive + business executives (key users) + CIO + key advisors (audit, legal, finance)
• Authority: Assists executive in delivering IT strategy
• Focus: implementation
• ขอบเขต: ระยะใกล้ 1-2 ปี
• ตัดสินใจเอง — ภายในกรอบที่ board approve

ความรับผิดชอบหลัก (ตาม CRM):

• Decide level ของ IT spending + cost allocation
• Align + approve enterprise IT architecture
• Approve project plans, budgets, priorities, milestones
• Acquire + assign appropriate resources
• Ensure projects meet business requirements (รวม reassessment ตลอด)
• Monitor project plans (value, outcomes, time, budget)
• Monitor resource + priority conflict ระหว่าง divisions/projects
• Make recommendations + requests for changes (strategy, priorities, funding, technology, resources)
• Communicate strategic goals to project teams

ตัวอย่างประเด็นที่คุย: “Project ERP ใหม่จะ go-live เมื่อไหร่”, “Budget ของ project A เกิน 30% — approve ต่อหรือ kill?”

ความต่างที่ออกข้อสอบ#

Test ในข้อสอบ: “Project ERP มีปัญหา budget เกิน ใครต้องตัดสินใจ?” → Steering Committee (เป็นเรื่อง execution ไม่ใช่ strategic direction)

อีกข้อ: “Board สงสัยว่า IT investment 5 ปีหน้าควรเน้น cloud หรือ on-premise ใครให้คำแนะนำ?” → Strategy Committee (เป็นเรื่อง direction)

Roles ที่ออกข้อสอบ#

CIO — Chief Information Officer

• ดู IT operations + governance ทั้งบริษัท
• Report ขึ้น CEO (best practice) ไม่ใช่ CFO

CISO — Chief Information Security Officer

• ดู security ของบริษัท
• Report ขึ้น CEO หรือ board (best practice) — ไม่ใช่ใต้ CIO (เราคุยใน 16A แล้ว)

Data Owner — เจ้าของข้อมูล

• คือ business manager ที่รับผิดชอบ data — ไม่ใช่ IT
• มีอำนาจตัดสินว่าใครเข้าถึง data ได้
• กำหนด classification ของ data
• ตัวอย่าง: Head of Sales = data owner ของ customer database

Data Custodian — ผู้ดูแลข้อมูล

• คือ IT (DBA, system admin) ที่ เก็บและปกป้อง data ตาม classification ของ owner
• ไม่มีอำนาจตัดสิน access — แค่ implement ตามที่ owner สั่ง

Security Administrator

• คนที่ implement security controls ตาม policy
• กำหนด user access rights ตาม approved request

Trap คลาสสิก: “DBA approve การให้ developer access ระบบ production”

ผิดครับ DBA = custodian ไม่มีอำนาจอนุมัติ access Data owner (business) ต้องเป็นคนอนุมัติ DBA แค่ทำตาม

Other Key IT Roles ที่ exam ออก#

CRM ระบุ roles ที่ IS auditor ต้องรู้จัก:

• Systems Analyst — แปลง business requirement เป็น technical specification
• Security Architect — design security infrastructure ระดับ enterprise
• System Security Engineer — implement security tools + monitoring
• Database Administrator (DBA) — บริหาร database (privileged access)
• Network Manager — บริหาร network infrastructure
• Infrastructure Operations — รัน data center, server, storage
• Applications Development — เขียน + maintain application code
• Help Desk / Support — รับ user issues

ทำไมต้องรู้ทุก role? เพราะแต่ละ role มี access level + risk profile ต่างกัน auditor ต้อง map role กับ control matrix ว่า access ที่ได้รับ appropriate กับ job duty หรือไม่

SoD — Separation of Duties#

SoD = แบ่งหน้าที่สำคัญ ระหว่างคนหลายคน เพื่อให้ ไม่มีคนเดียวที่ทำได้ครบทุกขั้นตอนของกระบวนการที่ critical

หลักการ: 3 หน้าที่ที่ห้ามรวมในคนเดียวกัน:

• Custody — ครอบครอง asset
• Authorization — อนุมัติ
• Recording — บันทึกบัญชี/log

ตัวอย่าง classic: cashier ที่นับเงิน + อนุมัติคืนเงิน + ปิดบัญชีกะ ทั้งหมดในคนเดียว = ทำทุจริตได้ง่าย เพราะไม่มี cross-check

ในมุม IT:

• คนสร้าง user account ≠ คนอนุมัติ access ≠ คนใช้ access
• คน develop code ≠ คน deploy ไป production
• DBA ไม่ควร approve การ access ของตัวเองไป production
• Network admin ไม่ควรเป็นคนเดียวที่ review network log

SoD ในบริษัทเล็ก — ทำไม่ได้ ทำยังไง?#

หลายบริษัทไทยขนาดกลางเล็กมาบ่นว่า “ทีมไม่พอจะแยก SoD ได้”

CISA ตอบว่า ถ้าแยกไม่ได้ → ต้องมี compensating controls

เช่น:

• ผู้บริหารระดับสูงทำ review ทุกสัปดาห์ (แทนการแยกหน้าที่)
• log monitoring ที่เข้มกว่าปกติ
• บังคับ mandatory leave (เปิดเผยถ้ามีการทำงานผิดปกติ)
• Periodic external audit ของ activity logs

SoD ห้ามต่อรองในหลักการ — ห้ามต่อรองในการ implement compensating controls

Mandatory Leave + Job Rotation — Control ไม่ใช่สวัสดิการ#

นี่เป็นคู่ที่ออกข้อสอบบ่อยมาก:

Mandatory Leave (บังคับลา / Required Vacation)

• หลายบริษัทมีนโยบายว่าพนักงานในตำแหน่ง sensitive (DBA, finance, treasury, network admin) ต้องลาติดต่อกัน 1-2 สัปดาห์ต่อปี
• ไม่ใช่ “สวัสดิการ” นะครับ มันคือ fraud detection control
• หลักการคือ ถ้าพนักงานทำทุจริต เขาต้องอยู่ทุกวันเพื่อปิดบัง บังคับลา + คนอื่นเข้ามาทำแทน → ความผิดปกติจะถูกค้นพบ

Trap คลาสสิก: บริษัทที่บอกว่า “พนักงาน IT ของเรามาทำงานทุกวัน 5 ปีไม่เคยลา ทุ่มเทมาก” auditor มองเป็น red flag ไม่ใช่เรื่องดี

Job Rotation (หมุนเวียนหน้าที่)

• หมุนพนักงานระหว่าง role/team ทุก 1-3 ปี
• ผลพลอยได้ 3 อย่าง:
  1. Cross-training — มีคนหลายคนทำงานนั้นเป็น (continuity)
  2. Fraud detection — เหมือน mandatory leave — ใครทุจริตในงานเก่าจะถูกเปิดเผยเมื่อคนใหม่มาแทน
  3. Career development — พนักงานพัฒนาทักษะหลากหลาย

Trap: Cross-training ที่ทำมากเกินไปจน 1 คนรู้ครบทุก phase ของกระบวนการ critical → SoD violation

ตัวอย่าง: ในระบบ payroll การ cross-train ผู้จัดการคนหนึ่งให้สามารถ enter ข้อมูลพนักงาน + อนุมัติเงินเดือน + ดู report = SoD violation 3 หน้าที่ในคนเดียว

→ Job Rotation ดี แต่ต้องไม่ทำลาย SoD ต้องแบ่งระหว่าง role/responsibility ที่ acceptable

ทำไม BI สำคัญใน Governance Context#

Strategic planning + decision making ของ governance depend on data quality

ลองนึกดู board จะ approve $5M IT investment โดยไม่มี data ของ ROI ของ investment ก่อนหน้า ได้มั้ย? ถ้า data fragmented ทั่วระบบ ไม่มีใครดึงมารวมได้ → board ตัดสินใจบนความรู้สึก

นี่คือ pain ที่ Business Intelligence มาแก้

BI = ระบบที่:

• Aggregate data จากหลายแหล่ง
• Transform ให้ analyze ได้
• Present ให้ผู้บริหารใช้ตัดสินใจ

4 Capabilities ของ BI#

CRM ระบุว่า BI ช่วย management ใน 4 มิติ:

1. Identify trends and patterns — เห็น signal ที่ raw data ซ่อนไว้
2. Understand customer behavior — needs, wants, preferences
3. Benchmark against competitors — วัดตัวเองเทียบ industry
4. Make better decisions — data-driven แทน gut-driven

Application Areas ที่ BI ใช้#

ในธุรกิจจริง BI ถูกใช้ใน 4 area:

• Buying patterns — ลูกค้าซื้ออะไร เมื่อไหร่ ที่ไหน
• Customer profitability — กลุ่มไหนทำกำไร, attribute ไหนทำนาย profitability
• Staff + sales conversion — KPI ของ sales team
• Risk management — unusual transaction, incident pattern, loss accumulation

Data Architecture — 11 Layers ของ Data Flow#

CRM Figure 2.3 แสดง Data Flow Architecture ที่ enterprise BI ต้องสร้าง — มี 11 layers:

Layers หลัก (Vertical Stack):

1. Presentation/Desktop Access Layer — end user เห็น (spreadsheet, dashboard, BSC tool)
2. Data Mart Layer — subsets ของ core warehouse สำหรับ business unit เฉพาะ
3. Data Feed/Data Mining Indexing Layer — automated processing + analysis delivery
4. Data Warehouse Layer — large enterprise-wide storage
5. Core Data Warehouse — fully normalized data center
6. Data Staging and Quality Layer — scrubbing, transformation, quality control
7. Data Access Layer — connect storage layer กับ data sources
8. Data Source Layer — operational, external, non-operational data

Layers สนับสนุน (Cross-cutting):

9. Metadata Repository Layer — data about data (business purpose + context)
10. Warehouse Management Layer — scheduling tasks + admin security
11. Application Messaging (Transport) Layer + Internet/Intranet Layer — communication infrastructure

Analysis Models#

นอกจาก data flow architecture, data architects ยังใช้ analysis models 3 แบบ:

• Context diagrams — outline major processes + external parties
• Activity / Swim lane diagrams — decompose business processes ทีละ step
• Entity Relationship diagrams (ERD) — depict data entities + relationships

มุม IS Auditor#

Auditor ดูอะไรใน BI/Data Architecture?

• Data quality controls — มี staging + validation layer มั้ย หรือ raw data flow เข้าทุกคน
• Metadata documentation — รู้มั้ยว่า data field ใน warehouse แต่ละตัวคืออะไร mean อะไร source จากไหน
• Access controls — ใครเข้า data warehouse ได้ ตาม classification + need-to-know
• Business sponsor involvement — data architecture ที่สร้างโดย IT คนเดียว ไม่มี business sponsor → ความเสี่ยงสูงที่ data ไม่ตรงกับ business need

Trap: “Data warehouse ที่ใหญ่ + เก็บข้อมูลเยอะ = governance ดี” ผิดครับ ถ้าไม่มี metadata + quality controls = “data swamp” ข้อมูลเยอะแต่ใช้ไม่ได้

EA คืออะไร?#

Enterprise Architecture = เอกสารที่ map ของ:

• ระบบ IT ทั้งหมดของบริษัท
• ความสัมพันธ์ระหว่างระบบ
• Data flow
• Business process ที่ใช้ระบบเหล่านั้น
• People + skills ที่ต้องการ

นึกง่าย ๆ คือ “แผนที่เมือง” ของ IT ในองค์กร

Framework ที่ต้องรู้จัก#

Zachman Framework

• กรอบที่บอกว่า EA ต้องมีหลายมุมมอง (จากระดับ strategic ลงไประดับ technical)
• แต่ละ stakeholder เห็นมุมต่างกัน
• เปรียบ — แบบของสถาปนิกที่มี structural drawing, electrical plan, conceptual sketch — อาคารเดียวกันแต่หลายเอกสาร
• 6 perspectives × 6 aspects = 36 cells (Why, How, What, Who, Where, When)

TOGAF + ADM (Architecture Development Method)

• Methodology สำหรับ สร้าง + maintain EA ไม่ใช่แค่ template เปล่า
• ADM = iterative process: vision → business architecture → IS architecture → technology architecture → opportunities → migration → governance → change management

ถ้าจะให้คำที่ติดหู:

• Zachman = layout ของแผนที่ (มุมมองอะไรบ้างต้องมี)
• TOGAF = กระบวนการสร้างแผนที่ (วาด ทบทวน อัปเดตยังไง)

ทำไม EA สำคัญสำหรับ Auditor?#

ถ้าไม่มี EA auditor ตรวจ control แบบ ไม่รู้ขอบเขต

ลองดู:

• บริษัทบอกว่า “เรามี firewall ป้องกัน traffic” auditor ถามต่อ “firewall ครอบคลุมระบบอะไรบ้าง?”
• ถ้าไม่มี EA → ตอบไม่ครบ → อาจมี shadow IT ที่ไม่ได้ผ่าน firewall เลย
• ถ้ามี EA → ดูแผนที่ → รู้ว่าระบบไหนผ่าน firewall ระบบไหนไม่ผ่าน ระบบไหนไม่อยู่ใน inventory เลย

Trap: EA ที่ไม่ update → ใช้แผนที่เก่า → auditor ตรวจตามแผนที่เก่า → finding หายไปทั้งหน้าใน landscape ที่เปลี่ยน

EA ต้องเป็น เอกสารที่มีชีวิต update ทุกครั้งที่ system landscape เปลี่ยน

เดี๋ยว Domain 4 จะลง IT operations + change management ที่ทำให้ EA ต้อง update เป็นระยะ ตอนนี้รู้ภาพรวมพอครับ

รวม Mental Model 16A + 16B#

อ่านครบทั้ง 16A + 16B จะมี mental model ของ Section 2.2 + 2.4 ครบ:

• 16A: ใครรับผิดชอบ — Corporate Governance → EGIT → Three Lines → ISG
• 16B: ทำงานยังไง — Strategy planning → committees → roles + SoD → BI/DA → EA

ทั้ง 2 ตอน = ครอบ Section 2.2 (ใหญ่ที่สุดของ D2) + 2.4 ของ CRM

จากนี้ governance framework + structure + mechanism ที่ board ใช้ govern IT ครบในหัว เหลือแค่ “สิ่งที่ governance ปกป้อง” ซึ่ง = Risk + Privacy + Data

ตอน 17A (และ ตอน 17B) จะลงเรื่องนั้นต่อ

อ้างอิง CRM (CISA Review Manual 28th Edition): Domain 2: Section 2.2.5-2.2.8 (IS Strategy, Strategic Planning, Business Intelligence + Data Architecture, Organizational Structure + SoD) + Section 2.4 Enterprise Architecture + Figure 2.4 IT Steering Committee Responsibilities