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

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

อ่านไปสักพัก เริ่มรู้สึกแบบเดิมอีกแล้ว เหมือนตอนอ่าน Domain 1 ที่ section ตามมาเป็นชุดจนสมองรับไม่ทัน

ปัญหาคือ 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 เราเก่ามาก vendor จะหยุด 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)