ทำไมต้องมีบทแบบนี้ก่อน#

ผมอ่าน Section 3.1 ตามลำดับ CRM เหมือนเดิมตอนแรก — เปิดมาก็เจอ project governance, organizational structure, WBS, Gantt, PERT, EVA — รัวเข้ามาเป็นชุด ตามด้วย 3.2 (business case + feasibility) แล้ว 3.3 (SDLC ทั้งดุ้น 993 บรรทัด) ตามด้วย 3.4 (application controls), 3.5 (testing), 3.6 (config), 3.7 (migration), 3.8 (postimplementation review)

อ่านไปประมาณ 200 บรรทัดของ 3.1 ผมก็รู้สึกอีกแล้วครับ — เหมือนตอนอ่าน Domain 1 ที่ 1.2 ตามด้วย 1.3 ตามด้วย 1.4 มันรัวจนสมองรับไม่ทัน

ปัญหาคือ Domain 3 ไม่ใช่เรื่องของ “ทฤษฎี project management” แต่เป็นเรื่องของ lifecycle ของระบบหนึ่งระบบ ตั้งแต่ยังเป็นแค่ความคิดในหัวเถ้าแก่ ไปจนถึงวันที่ระบบทำงานได้ครบรอบหนึ่งแล้ว

ถ้าไม่เห็น lifecycle ก่อน WBS, PERT, Agile, Scrum, parallel testing, abrupt cutover, postimplementation review — มันลอยหมด

บทนี้คือ map ที่ผมวาดให้ตัวเองดู ก่อนจะเข้าไปเจาะแต่ละ phase

คนสองกลุ่มในเรื่องนี้#

ก่อนเริ่ม map ผมขอแยกตัวละครก่อน เพราะ Domain 3 มี 2 มุมมองที่ต้องสลับไปสลับมา ตลอดเวลา

กลุ่มที่ 1: คนที่สร้างระบบ

• Project sponsor — เจ้าของไอเดีย เถ้าแก่หรือ executive ที่อยากได้ระบบใหม่
• Steering Committee — กรรมการที่ดูแลทิศทางโปรเจ็ค
• Project Manager (PM) — คนรันโปรเจ็ครายวัน
• Business analysts, developers, testers, vendor (ถ้าซื้อ)
• End users — คนที่จะใช้ระบบจริงหลัง go-live

กลุ่มที่ 2: คนที่ตรวจระบบ

• IS auditor — เราเอง ที่อาจเข้ามาในบทบาท advisor (ที่ปรึกษา) หรือ reviewer (ผู้ตรวจอิสระ) — แต่ไม่ใช่ทั้งสองอย่างพร้อมกัน

ความตึงเครียดของ Domain 3 อยู่ตรงนี้ครับ — IS auditor ที่เข้าไปช่วย design control ระหว่างที่ระบบถูกสร้างให้คุณค่าได้สูงมาก แนะนำได้ ตรวจ test plan ได้ ดู WBS ได้ แต่ทันทีที่ลงไปลึก — ความเป็นอิสระในการ audit ระบบนี้หลัง go-live จะค่อยๆ หายไป

กับดักข้อแรกของ Domain 3: auditor ที่เป็นสมาชิกทีมโปรเจ็ค ไม่ได้กำลังทำ audit — เขาเป็น consultant คำว่า independence ที่เคยคุยใน ตอน 02 ของ Domain 1 จะถูกท้าทายตลอด Domain 3

จำไว้ก่อนครับ จะกลับมาเรื่องนี้อีกหลายรอบ

ฉาก 1 — ก่อนจะเป็นโปรเจ็ค#

ทุกระบบเริ่มจาก “ความรู้สึก” บางอย่างก่อน

เถ้าแก่บอกในที่ประชุมว่า “ระบบบัญชีตอนนี้ช้าเกินไป ปิดเดือนแต่ละครั้งใช้เวลา 10 วัน” หรือ CIO ยกมือใน town hall ว่า “ระบบ HR ของเราเก่ามาก ผู้ขายจะหยุด support ปีหน้า” หรือฝ่ายขายโวยว่า “ระบบ CRM ที่ใช้อยู่ไม่ track lead ได้ตามที่ต้องการ”

นี่ยังไม่ใช่โปรเจ็ค — เป็นแค่สัญญาณว่าอาจจะมีโปรเจ็คเกิดขึ้น

ก่อนจะลงเงินสร้างหรือซื้อ ต้องมีคนถามคำถามต่อไปนี้ก่อน:

• ปัญหานี้คุ้มที่จะแก้ด้วยการลงทุนระบบใหม่ไหม?
• ทางเลือกที่มีคืออะไรบ้าง — ซื้อสำเร็จรูป สร้างเอง หรือปรับระบบเดิม?
• ถ้าทำแล้วจะวัดยังไงว่า “สำเร็จ”?
• ถ้าไม่ทำเลยจะเป็นอย่างไร?

คำถามเหล่านี้คือ business case + feasibility study — และเป็น “ด่านแรก” ของ governance ที่บอกว่าโปรเจ็คนี้ควรเกิดหรือไม่ควรเกิด

→ นี่คือเรื่องของ Section 3.1 + 3.2 ที่จะเล่าใน ตอนถัดไป

ฉาก 2 — ตัดสินใจแล้วว่าทำ ก็ต้องเลือก “วิธีทำ”#

สมมติคำตอบจาก feasibility study คือ “คุ้ม ทำเลย” — คำถามถัดไปไม่ใช่ “ใครจะเขียนโค้ด” แต่เป็น “จะใช้ methodology อะไร”

ทำไมเรื่องนี้สำคัญ? เพราะแต่ละ methodology มี risk profile คนละแบบ และ IS auditor ต้องตรวจคนละจุด

• Waterfall — แบ่ง phase ชัดเจน feasibility → requirements → design → development → testing → deployment ทุก phase มีเอกสารครบ ตรวจง่าย แต่ช้าและไม่ยืดหยุ่น
• Agile / Scrum — ทำเป็น sprint สั้นๆ ทดสอบ feedback แล้วปรับ เร็ว ยืดหยุ่น แต่เอกสารน้อย controls อาจไม่ถูก design อย่างเป็นทางการต่อ feature
• Prototyping — สร้างต้นแบบให้ user ลองก่อน ดีตรง user buy-in แต่อันตรายมาก ถ้า prototype ที่ยังไม่ครบ control โผล่ไป production
• RAD — เร็วเหมือน agile แต่มีโครง 4 stages
• DevOps / DevSecOps — รวม dev + ops + security เข้าด้วยกัน deploy ถี่มาก ต้อง automated controls
• OOSD — programming paradigm ที่มอง entity เป็น object ใช้กับ methodology ไหนก็ได้

→ Section 3.3 จะเล่าทั้ง waterfall ลึกๆ + acquisition (RFP, vendor evaluation, escrow) ใน ตอน 25 และ alternative methodologies ทั้งหลายใน ตอน 26

ฉาก 3 — ระบบเริ่มมีรูปร่าง แต่ data ที่ไหลผ่านล่ะ?#

ถ้าโปรเจ็คเดินมาถึงจุดที่ระบบเริ่มทำงานได้ คำถามถัดไปไม่ใช่ “feature ครบไหม” แต่คือ “ข้อมูลที่ไหลผ่านระบบนี้ — เชื่อถือได้แค่ไหน?”

ทุก application ที่จับข้อมูลธุรกิจต้องมี control 3 ด่าน:

1. Input controls — ห้ามข้อมูลผิดเข้ามาตั้งแต่แรก (edit checks, batch totals, source document authorization)
2. Processing controls — ระหว่างประมวลผล ข้อมูลไม่ถูกเปลี่ยนแปลงโดยไม่มีหลักฐาน (run-to-run totals, exception reports, reasonableness verification)
3. Output controls — ผลลัพธ์ไปถึงคนที่ควรได้ ในรูปแบบที่ปลอดภัย (distribution, encryption, retention)

นี่คือเรื่องที่ทดสอบบ่อยที่สุดในข้อสอบ เพราะ controls พวกนี้ auditor ทดสอบได้จริง ไม่ใช่แค่ดูว่ามีในนโยบาย — ส่ง test transaction เข้าไปแล้วดูว่าระบบ reject ถูกไหม

→ ตอน 27 จะเจาะ application controls ทั้ง 3 ด่าน

คำเตือนเล็กๆ: application controls แข็งแรงแค่ไหน ก็ไม่มีความหมายถ้า DBA เข้าไปแก้ฐานข้อมูลตรงๆ ได้ — เรื่องนี้ Domain 5 จะลง IAM ลึกขึ้น เดี๋ยวเจอกันตอน Domain 5

ฉาก 4 — สร้างเสร็จแล้ว แต่ยังไม่ผ่านด่านสุดท้าย#

ระบบเขียนเสร็จไม่ได้แปลว่าพร้อม go-live ครับ — ต้องผ่าน testing ก่อน และ testing ไม่ใช่กิจกรรมเดียว

แต่ละแบบของ testing ตอบคำถามคนละข้อ:

• Unit testing — module นี้ทำงานถูกไหม
• Integration testing — module ต่างๆ ทำงานร่วมกันได้ไหม
• System testing — ระบบทั้งระบบทำงานตรงตาม spec ไหม
• Recovery / security / performance / load / stress testing — ระบบทนสภาวะผิดปกติได้ไหม
• QAT (Quality Assurance Testing) — ระบบตรงตาม technical spec ไหม (IT ทดสอบ)
• UAT (User Acceptance Testing) — ระบบทำงานตรงกับ business process ไหม (end user ทดสอบ)

กับดักที่ต้องระวัง: UAT ของระบบที่ซื้อมา ห้าม delegate ให้ vendor เด็ดขาด — เพราะ vendor มีแรงจูงใจให้ตัวเองผ่าน buyer ต้องทดสอบเอง

นอกจากนี้ IS auditor ยังมีเครื่องมือทดสอบของตัวเอง เช่น GAS, ITF, SCARF, parallel simulation — เป็น CAATs ที่เคยพูดถึงใน ตอน 11 ของ Domain 1 มาแล้ว

→ ตอน 28 จะเจาะ testing + audit tools

ฉาก 5 — Go-Live: วันที่ความเสี่ยงสูงสุดของโปรเจ็คทั้งหมด#

ผ่าน UAT แล้วก็ยังไม่จบครับ — เพราะระหว่าง testing environment กับ production environment ยังต้อง transition

ก่อน go-live ต้องเรียงให้ครบ:

• Configuration management — version ของ code/config ที่ขึ้น production ต้องเป็น version ที่ผ่าน test แล้ว ไม่ใช่ version อื่น และ developer ต้องไม่ใช่คน promote เอง (SoD)
• Release management — รอบการ release ที่มีโครง ไม่ใช่ใครอยากปล่อยก็ปล่อย
• Data migration — ย้ายข้อมูลจากระบบเก่ามาระบบใหม่ ต้องตรวจ completeness, accuracy, integrity ทุก field
• Changeover technique — เลือกได้ 3 แบบ: parallel (ใช้ทั้ง 2 ระบบพร้อมกัน), phased (ทีละ module), abrupt (ตัดทันที)
• Rollback plan — ถ้า migration ล้มเหลวกลับไปสภาพเดิมได้ไหม และ ทดสอบ rollback แล้วหรือยัง?
• End-user training — ระบบดีแค่ไหน ถ้า user ไม่รู้จะใช้ก็ไม่มีประโยชน์

กับดัก: abrupt cutover คือทางเลือกที่เสี่ยงที่สุด — ไม่มี safety net ถ้าพังคือพัง parallel ปลอดภัยที่สุดแต่กิน resource เพราะ user ต้องทำงาน 2 ระบบพร้อมกัน

→ ตอน 29 จะเล่า config + release + migration + data conversion ครบชุด

ฉาก 6 — Go-Live แล้ว — แต่ยังไม่จบ#

วันที่ระบบขึ้น production แล้วทุกคนเฉลิมฉลอง — IS auditor มีงานใหม่รออยู่ครับ

Postimplementation review (PIR) — รีวิวที่ทำหลัง go-live 6-12 เดือน เพื่อตอบคำถามที่ business case ตั้งไว้ตั้งแต่ฉากที่ 1:

• ระบบ deliver benefits ตามที่อ้างใน business case ไหม?
• Controls ที่ design ไว้ทำงานจริงไหม?
• Process การพัฒนา (methodology, schedule, cost) ที่ใช้เหมาะสมไหม?
• Lessons learned จากโปรเจ็คนี้คืออะไร?

PIR ปิด governance loop ที่เปิดไว้ตอน feasibility study — และเป็นจุดที่ independence ของ IS auditor สำคัญที่สุด ถ้า auditor ที่ทำ PIR เคยเป็น consultant ของโปรเจ็คนี้มาก่อน — เขาทำ PIR ไม่ได้

→ ตอน 30 จะเล่า PIR + ปิด Domain 3 + เกริ่น Domain 4

Map ทั้ง Domain 3 ในรูปเดียว#

1
ความรู้สึกว่าต้องการระบบใหม่
2
    ↓
3
Business Case + Feasibility Study  ← ตอน 24
4
    ↓ (ผ่านด่านแรก)
5
เลือก methodology + structure ของโปรเจ็ค
6
    ↓
7
SDLC (Waterfall) + Build vs Buy + Acquisition  ← ตอน 25
8
    ↓ หรือ ↓
9
Alternative methodologies (Agile, Scrum, RAD, DevOps, ...)  ← ตอน 26
10
    ↓
11
ระบบเริ่มมีรูปร่าง — design Application Controls
12
    ↓
13
Application Controls: Input / Processing / Output  ← ตอน 27
14
    ↓
15
Testing (Unit → Integration → System → UAT)
16
+ IS auditor's own testing tools (CAATs)  ← ตอน 28
17
    ↓
18
Go-Live: Config + Release + Migration + Data Conversion  ← ตอน 29
19
    ↓
20
Postimplementation Review (6-12 เดือนต่อมา)  ← ตอน 30
21
    ↓
22
ปิดวง — เริ่มเป็น "ระบบที่ต้อง operate"
23
    ↓
24
Domain 4 (Operations + Resilience)

ทุกศัพท์ที่จะเจอใน 7 บทถัดไป — WBS, PERT, EVA, RFP, source code escrow, sprint, prototype, edit control, hash total, before/after image, ITF, SCARF, baseline, parallel cutover, rollback, benefits realization — มันมีที่อยู่ในแผนภาพข้างบนนี้แล้วครับ

ก่อนจะลงรายละเอียดบทถัดไป — สามคำเตือนที่ฝังไว้ทั้ง Domain#

คำเตือนที่ 1: บทบาท advisor vs auditor ของ IS auditor

IS auditor ที่ embedded ใน project team ให้คุณค่าได้สูงมาก — แต่ เขาไม่ได้กำลังทำ audit เขาเป็น consultant ความเป็นอิสระในการ audit ระบบนี้หลัง go-live จะหายไปตามระดับการมีส่วนร่วม

คำเตือนที่ 2: methodology ใหม่ไม่ได้ลด risk แค่เปลี่ยน risk

Agile ไม่ได้แปลว่าไม่ต้องมีเอกสาร Prototype ไม่ได้แปลว่าผ่าน user แล้วเอาขึ้น production ได้ BPR ไม่ได้แปลว่า process ใหม่ปลอดภัยกว่าเดิม — ทุก methodology มี control gap ที่ต่างกัน

คำเตือนที่ 3: governance ของโปรเจ็ค ≠ project management ของโปรเจ็ค

Steering Committee ดูทิศทาง Project Manager รันรายวัน คนละเรื่อง คนละบทบาท ห้ามสับสน

ตอนนี้พร้อมแล้ว#

7 บทที่เหลือของ Domain 3 จะลง map ที่เพิ่งวาดให้ดู ทีละ phase — ตั้งแต่ business case (ตอน 24) ไปจนถึง postimplementation review (ตอน 30)

ลำดับที่ผมจัดไม่ตรงกับ section number ใน CRM ทุกอันเป๊ะๆ เพราะ CRM มีเนื้อหาที่ทับซ้อนกันบ้าง (3.1.4 พูด portfolio 2 ครั้ง, 3.1.5 พูด PMO 2 ครั้ง, BPR ปรากฏ 2 ครั้งใน 3.3, phase 5 กับ phase 6 เนื้อหาคล้ายกัน) — ผมเลือกใช้ ลำดับเรื่อง แทนลำดับเลขครับ

ที่อยากให้เห็นจากบทนี้คือ — ไม่มีศัพท์ไหนใน Domain 3 ที่ลอยมาจากฟ้า ทุกอย่างมีที่อยู่ใน lifecycle ของระบบที่เพิ่งวาดให้ดู

อ้างอิง CRM (CISA Review Manual 28th Edition): Domain 3: Section 3.1-3.8 (synthesis post — ไม่ตรงกับ section ใด section หนึ่งใน CRM)