CISA Series ตอนที่ 30 : D3 - Postimplementation Review + ปิด Domain 3 + เกริ่น Domain 4

ระบบขึ้น production แล้ว user ใช้แล้ว project manager ปิดโปรเจ็คเลื่อนไปอันถัดไปแล้ว — แต่ในมุม governance ยังเหลืออีก 1 เรื่อง

คำถามที่ business case ตั้งไว้ตั้งแต่วันแรก: “ระบบนี้คุ้มค่าไหม”

คำตอบ — รู้ได้เมื่อระบบ run ในสภาพแวดล้อมจริงมาแล้วระยะหนึ่ง

นี่คือเรื่องของ Section 3.8 — Postimplementation Review (PIR) — รีวิวที่ปิด governance loop ที่เปิดไว้ตั้งแต่ business case ตอน 24

ตอนนี้คือตอนสุดท้ายของ Domain 3 — รวม PIR + recap ทั้ง domain + เกริ่น Domain 4

ทำไม PIR สำคัญที่สุดในมุม governance#

ลองนึกถึงร้านอาหารใหม่ที่เปิด 6 เดือนที่แล้ว

วันเปิดร้าน — ลูกค้าแน่น chef ภูมิใจ เจ้าของยินดี ทุกคนบอก “สำเร็จ”

แต่คำถามจริงๆ ที่ตอบได้หลัง 6 เดือนคือ:

ลูกค้ามาซ้ำไหม
กำไรตามที่คาดในแผนธุรกิจไหม
พนักงานยังอยากทำงานที่นี่ไหม
ต้นทุนที่ใช้จริงเทียบกับที่ project ไว้
มีปัญหาอะไรที่ตอนทำแผนไม่ได้คาดถึงไหม

ระบบ IT ก็เหมือนกันครับ — วันที่ go-live สำเร็จ ≠ โปรเจ็คสำเร็จ

PIR ทำเพื่อตอบคำถามที่ business case วางไว้ตั้งแต่ตอน 24 — และเพื่อเรียนรู้สำหรับโปรเจ็คถัดไป

ทำไมต้องรอ 6-12 เดือน#

กับดัก ⚠️: PIR = audit ทันทีหลัง go-live

ผิด — PIR ที่ทำเร็วเกินไปจะตอบคำถามไม่ได้

ระยะเวลาที่ “ดี” คือ 6-12 เดือนหลัง go-live เพราะ:

ระบบยังอยู่ในช่วง “จูนเครื่อง” ใน 1-2 เดือนแรก — bug, performance issue, integration problem ทยอยเกิด
User ยังไม่คุ้นชิน — ปัญหา usability บางส่วนหายไปเมื่อ user เก่งขึ้น
Benefit ไม่ปรากฏทันที — ต้นทุนเพิ่มก่อน (training, parallel run, debugging) → benefit เกิดทีหลัง
ต้องผ่าน business cycle ครบหนึ่งรอบ — ระบบบัญชีต้องผ่านการปิดเดือน + ไตรมาส + ภาษีกลางปี → จึงเห็นภาพครบ
Hidden problem ที่ไม่โผล่ในช่วงแรก จะโผล่ใน peak load หรือ edge case ที่เกิดไม่บ่อย

มุมที่ผู้บริหารต้องเข้าใจ: PIR ที่ทำเร็วเกินไปจะ optimistic เกินจริง — ต้นทุนยังไม่เห็นครบ benefit ยังไม่เกิด หลายบริษัท claim ว่า “PIR ผ่าน” หลัง go-live 1 เดือน — ไม่ใช่ PIR จริงครับ

PIR ตรวจอะไรบ้าง — 2 มิติคู่ขนาน#

PIR ที่สมบูรณ์ครอบคลุม 2 มิติ ที่ทำงานคู่กัน:

มิติที่ 1: System Quality#

ระบบเอง — deliver value ตามที่ promise ไหม

คำถามที่ PIR ตอบ:

Functional: ระบบทำงานครบตาม requirement ที่ตั้งไว้ไหม
Performance: ตอบสนองในเวลาที่ acceptable ไหม
Security: มี incident เกิดในช่วง 6-12 เดือนแรกไหม
Reliability: uptime % เป็นไปตาม SLA ไหม
User adoption: user จริง ใช้ feature ที่สำคัญไหม หรือยังกลับไปใช้วิธีเก่า
Benefits realization: benefit ที่ business case promise (ลด cycle time, ประหยัดต้นทุน, เพิ่มยอดขาย) เกิดจริงและวัดได้ไหม
Total Cost of Ownership: ต้นทุนจริงเทียบกับที่ project ไว้

เรื่อง benefits realization ผูกกลับไป Domain 2 ตอน 14 — benefit management เป็น governance topic ในระดับองค์กร PIR คือจุดที่ governance loop ของระบบเดียว ปิดวง

มิติที่ 2: Process Quality#

กระบวนการพัฒนาเอง — ทำได้ดีไหม

คำถามที่ PIR ตอบ:

Methodology: methodology ที่เลือก (waterfall, agile, prototype) เหมาะสมไหม
Project management: schedule + budget เป็นไปตามแผนไหม variance อยู่ที่ไหน
Stakeholder management: การสื่อสารกับ stakeholder ทำได้ดีไหม มีปัญหาที่ไหน
Risk management: risk ที่ project register บันทึก — เกิดจริงกี่อัน mitigation มีประสิทธิภาพไหม
Change management: scope change ที่เกิดในระหว่างโปรเจ็ค — ผ่าน formal process ไหม
Lessons learned: อะไรที่ทำได้ดี อะไรที่ทำได้แย่ จะเอาไปใช้กับโปรเจ็คถัดไปยังไง

มุมที่ผู้บริหารต้องเข้าใจ: มิติที่ 2 มีค่ากับองค์กรในระยะยาวมากกว่าที่หลายคนคิด — เพราะ lessons learned ที่ document แล้วนำไปใช้จริง = ทำให้โปรเจ็คถัดไปดีขึ้น แต่ถ้าเขียน lessons learned แล้วเก็บใน folder ไม่มีใครอ่าน = waste of effort

Independence — เรื่องที่ห้ามต่อรอง#

ตอน ตอน 23 ผมเตือนแล้วว่าตลอด Domain 3 จะมีความตึงเครียดของ auditor’s role — advisor vs auditor

PIR คือจุดที่ความตึงเครียดนั้น ห้ามคลุมเครือ

กฎเหล็ก: Auditor ที่เคยเป็น consultant / advisor ในโปรเจ็คนี้ — ทำ PIR ของระบบนี้ไม่ได้

ทำไม?

ลองนึกง่ายๆ — ถ้า auditor ที่ช่วย design control เป็นคนตรวจ control เดียวกัน — เขาจะตรวจอย่างเป็นกลางได้ไหม?

คำตอบ: ในทางทฤษฎีอาจจะได้ ในทางปฏิบัติ — เกือบเป็นไปไม่ได้ เพราะ:

Cognitive bias — คนที่ออกแบบสิ่งใดก็ตามจะเห็นข้อดีของสิ่งนั้นชัดกว่าข้อเสีย
Sunk cost fallacy — เคยลงเวลากับ design นี้ → ยากที่จะ admit ว่ามันมีปัญหา
Reputation risk — ถ้าตรวจแล้วเจอปัญหาที่เกิดจาก design ของตัวเอง = ยอมรับว่าตัวเองทำผิด

นี่คือเหตุผลที่ ISACA Standards ระบุชัดว่า independence ของ PIR ไม่ใช่ optional

ผูกกลับไป Domain 1 ตอน 02 และ ตอน 04 — independence ที่คุยตั้งแต่ Domain 1 = หลักการที่ทดสอบจริงใน Domain 3

มุมปฏิบัติของ Independence#

ในบริษัทที่มีทีม internal audit ทีมเดียว — ถ้า auditor A ช่วย design system X → auditor B ต้องเป็นคนทำ PIR ของ system X (ในขณะที่ A ก็ทำ PIR ของ system อื่นที่ A ไม่เกี่ยวข้อง)

ในบริษัทเล็ก auditor team เล็ก — อาจต้องจ้าง external auditor มาทำ PIR เพื่อให้ independence ครบ

เรื่องนี้ผูกกลับไป Domain 2 ตอน 18 (HR Resource) + outsourcing options ที่อยู่ใน Domain 2 ตอน 19

Project Closure — 5 ขั้นตอนปิดโปรเจ็คอย่างเป็นทางการ#

PIR เป็นส่วนหนึ่งของ project closure — กระบวนการปิดโปรเจ็คอย่างเป็นทางการ ไม่ใช่แค่ “เดินออกจากห้องประชุม”

ขั้นตอนที่ผม distill จากที่อ่าน:

1. ปิด outstanding issues

ระบุปัญหาที่ยังเปิดอยู่ — bug ที่ยังไม่แก้, feature ที่ defer ไว้, integration ที่ยังไม่สมบูรณ์ → assign owner ที่จะรับช่วงต่อ + deadline

2. Closure ของสัญญา

สัญญากับ vendor, contractor, consultant — ปิดอย่างเป็นทางการ verify ว่า deliverable ครบตามสัญญา ค่าจ้างจ่ายครบ warranty ของ vendor ที่ยังไม่หมดอายุ — บันทึกไว้

3. Postproject review (PIR)

นี่คือเรื่องที่บทนี้คุยทั้งบท

4. Risk register update

Risk ที่เปิดในช่วงโปรเจ็ค — ปิดอันที่ปิดได้, ย้ายอันที่ยังเปิดไปอยู่ใน operational risk register สำหรับการ run system ต่อ

5. ROI / Benefits measurement

วัดผลทางการเงิน — ROI, payback period, NPV ที่ระบุใน business case → จริงไหม

กับดัก: project closure = เลี้ยงปิดโปรเจ็ค

ผิด — closure คือ formal governance process ทุกขั้นตอนต้อง document และ approve โดย steering committee อย่างเป็นทางการ — ลายเซ็นปิดโปรเจ็คอย่างเป็นทางการ ไม่ใช่ pizza party

ทำไมเรื่องนี้สำคัญกับ exam#

ผมเห็น 5 trap pattern ของ Section 3.8:

PIR = audit ทันทีหลัง go-live — ผิด รอ 6-12 เดือน
Auditor ที่ help build = ทำ PIR ได้ — ผิด independence ห้ามต่อรอง
PIR = technical review — ผิด ครอบคลุมทั้ง system quality + process quality
Project closure = informal — ผิด เป็น formal governance process
Benefits = วัดวันแรก — ผิด ต้องรอให้ระบบ run ครบ business cycle

จำ 5 ข้อนี้ + รู้ว่า PIR ปิด governance loop ที่ business case เปิดไว้ — Section 3.8 ผ่านระดับแนวคิดไปแล้ว

Recap: Domain 3 ทั้ง 8 ตอน#

ผมได้เดินทางผ่าน lifecycle ของระบบใหม่ครบรอบหนึ่งแล้ว — มาดูรวมกันว่าผ่านอะไรมาบ้าง

ตอน	เนื้อหา	สิ่งที่ได้
23	เปิด D3 storyboard	Map ทั้ง domain — lifecycle ของระบบจาก idea ถึง PIR
24	Project governance + business case + feasibility	ด่านแรกของ governance ก่อนตอกเสาเข็ม
25	SDLC waterfall + build vs buy + acquisition	กระบวนการคลาสสิคและการซื้อระบบ
26	Alternative methodologies	Agile, Scrum, RAD, DevOps, OOSD — risk profile คนละแบบ
27	Application controls	3 ด่านควบคุมข้อมูล: Input → Processing → Output
28	Testing + IS auditor tools	Quality gate ก่อน go-live + CAATs ใน SDLC
29	Go-live: config + release + migration	วันที่ความเสี่ยงสูงสุด — รวม technique transition + rollback
30	Postimplementation review + close	ปิด governance loop ที่เปิดไว้ตอน business case

5 บทเรียนใหญ่ที่ผมเก็บจาก Domain 3#

บทเรียน 1 — IS auditor ใน project = ความตึงเครียดของบทบาท#

Auditor ในโปรเจ็คเข้าได้สอง บทบาท — advisor (consultant) หรือ reviewer (independent auditor) — แต่ห้ามทั้งสองพร้อมกัน ลึกใน design phase แค่ไหน → ความเป็นอิสระในการ audit ระบบเดียวกันหลัง go-live หายไปตามนั้น

PIR คือจุดทดสอบ independence ที่หนักที่สุด — ห้ามต่อรอง

บทเรียน 2 — Methodology ใหม่ไม่ใช่ silver bullet#

Agile ไม่ใช่ no documentation, Prototype ไม่ใช่ production after approval, RAD ไม่ใช่ shortened waterfall, DevOps ไม่ใช่ no change control, BPR ไม่ใช่ลด risk โดยอัตโนมัติ

ทุก methodology มี risk profile คนละแบบ auditor ที่ดีต้องเข้าใจ methodology ที่ใช้ก่อนเริ่ม audit — ไม่ใช่บังคับให้ทุกโปรเจ็คทำเหมือน waterfall เพื่อให้ audit ง่าย

บทเรียน 3 — Application controls + database controls = both required#

ตอน 27 ย้ำเรื่องนี้ — application controls แข็งแค่ไหน ก็ไม่มีความหมายถ้า DBA bypass ตรงไปยังฐานข้อมูลได้

Auditor ตรวจทั้ง 2 layer — application + database

บทเรียน 4 — Vendor relationship = control accountability ไม่หาย#

ในการ acquisition — buyer ไม่ได้แค่ “ซื้อระบบ” buyer ยัง own accountability ของ control ที่ระบบนั้น implement Right-to-audit clause + UAT ที่ buyer ทำเอง + source code escrow + acceptance testing ที่ไม่ delegate ให้ vendor — เป็นเครื่องมือที่ทำให้ accountability ไม่หาย

ผูกกลับ Domain 2 ตอน 19 — outsourcing ใน D2 vs acquisition ใน D3 = แสดง 2 มิติของ vendor relationship ที่ accountability อยู่กับ buyer เสมอ

บทเรียน 5 — Governance loop ต้องปิดวง#

Business case (ตอน 24) เปิด loop ด้วยคำถาม “ระบบนี้คุ้มค่าไหม” PIR (ตอน 30) ปิด loop ด้วยคำตอบ “เกิดขึ้นจริงไหม”

ระหว่างนั้น — kill points ระหว่าง phase เป็น mid-way checkpoints

โปรเจ็คที่ “เปิด loop ไม่ปิด” — business case เคย approve ตอนเริ่ม แต่ไม่เคย review หลัง go-live — คือโปรเจ็คที่ governance ถูกข้าม

เกริ่น Domain 4 — ระบบที่ build เสร็จแล้ว ดูแลให้ทำงานยังไง#

ทั้ง Domain 3 เราคุยเรื่อง build / acquire / deploy ระบบ — โฟกัสที่การให้ระบบ “ขึ้นไปทำงาน”

แต่ในความเป็นจริง — ระบบที่ขึ้น production เป็นแค่จุดเริ่มต้นของการ own มัน

หลัง go-live ระบบต้อง:

ทำงานทุกวัน — แม้ตอน peak load, แม้ตอน user ทำผิด, แม้ตอน infrastructure มีปัญหา
อัปเดตเรื่อยๆ — patch security, แก้ bug, เพิ่ม feature ใหม่ — โดยไม่พังของเก่า
รอดเมื่อเกิดเหตุไม่คาดฝัน — ไฟดับ, ภัยพิบัติ, cyber attack, ransomware

นี่คือเรื่องของ Domain 4 — IS Operations and Business Resilience ที่:

Section 4.1-4.11 — operations รายวัน (asset management, capacity, incident, problem, change, configuration, patch, log management, SLA, database)
Section 4.12-4.16 — resilience (BIA → BCP → DRP → RPO/RTO → backup)

Domain 4 = หน้าที่ของ IT operations team — และ control ใหม่ที่ auditor ต้องตรวจในโลกของ “ระบบที่ live”

ข้อสอบให้น้ำหนัก D4 = 26% — มากที่สุดร่วมกับ D5 — เพราะธุรกิจส่วนใหญ่ “operate ระบบ” มากกว่า “build ระบบ”

ก่อนปิดท้าย — ผมขอขอบคุณคนที่อ่านมาถึงตอน 30 ของซีรีส์ครับ Domain 3 มี 8 ตอนที่ผมเขียนยากที่สุดในซีรีส์เพราะ section 3.3 เนื้อหาเยอะมาก กับดักก็เยอะ — ต้องเลือกว่าอันไหนสำคัญพอจะใส่ อันไหน skip

ที่อยากให้เห็นจาก Domain 3 คือ — lifecycle ของระบบ ≠ ตำราเทคนิค มันคือเรื่องของ governance ที่ฝังในทุก phase — ตั้งแต่วันที่ idea เกิด จนถึงวันที่ระบบ deliver value ตามที่ promise

Domain 4 จะเปลี่ยน mindset อีกครั้ง — จาก “build the system” เป็น “run + survive”

อ้างอิง CRM (CISA Review Manual 28th Edition): Domain 3: Section 3.8 Postimplementation Review + Domain 3 Close