สารบัญ
ระบบทดสอบผ่าน UAT ผ่าน certification แล้ว approval แล้ว — แต่จริงๆ แล้วโปรเจ็คยังไม่จบ และ วันที่จะ go-live คือวันที่ความเสี่ยงสูงสุดของทั้งโปรเจ็ค
ฟังดูแปลก — ทดสอบมาทุกอย่างแล้ว ทำไมยังเสี่ยง?
เพราะ go-live ไม่ใช่แค่ “กดปุ่มเปิดระบบ” — เป็นการ transition ที่ครอบคลุม:
- Configuration ของระบบใหม่ตรงกับ environment ที่ทดสอบไหม
- Data จากระบบเก่าย้ายมาระบบใหม่ครบ + ถูกไหม
- กลยุทธ์ในการสลับระบบ (changeover) เลือกอย่างไร
- ถ้าพังกลับสภาพเดิมได้ไหม
- User รู้ใช้ระบบไหม
ทุกข้อข้างต้น ถ้าพลาดข้อเดียว — โปรเจ็คที่สำเร็จมา 6 เดือน 12 เดือน อาจล้มในวันเดียว
บทนี้รวม Section 3.6 (Configuration + Release Management) กับ 3.7 (Migration + Data Conversion + Training) เพราะมันคือ 2 หน้าของเหรียญเดียวกัน — governance ของวัน go-live
Configuration Management — ระบบไม่ใช่แค่ code
หลายคนคิดว่า config management = version control ของ code — ผิดครับ
Configuration ครอบคลุมทุกอย่างที่ทำให้ระบบทำงาน:
- Source code + binary
- Database schema + reference data
- Server configuration (OS, middleware, runtime version)
- Network configuration (firewall rules, load balancer config)
- Documentation + procedures
- Test plans + test data
ทั้งหมดนี้ถูก track ใน CMDB (Configuration Management Database)
CMDB ≠ Hardware Asset List
กับดัก: CMDB = spreadsheet รายการ hardware
ผิดครับ — CMDB ที่ดีบันทึก:
- แต่ละ component มี version อะไร
- เชื่อมต่อกับ component ไหนบ้าง (relationships)
- Config ปัจจุบันคืออะไร
- เปลี่ยนแปลงครั้งล่าสุดเมื่อไหร่ โดยใคร
นี่คือสิ่งที่ทำให้ incident investigation ทำได้เร็ว เมื่อระบบล่ม operations team ดู CMDB เพื่อระบุว่า “เพิ่ง patch อะไรเมื่อวาน” ในเวลาไม่กี่นาที
Check-out / Check-in Process
วิธีควบคุมการเปลี่ยนแปลง configuration:
- คนที่จะแก้ → check-out จาก CMDB (ผูก lock)
- แก้ + ทดสอบ
- ขอ change approval ผ่าน change advisory board (ถ้าจำเป็น)
- Check-in กลับเข้า CMDB เป็น version ใหม่
ระหว่างที่ check-out — คนอื่นแก้ component นี้ไม่ได้ ป้องกัน “การแก้ที่ทับกัน”
ในระบบ DevOps สมัยใหม่ — process นี้ implement ผ่าน Git + pull request + branch protection — concept เดียวกัน รูปแบบเปลี่ยน
Baselines
กับดัก: Baseline = final version
ผิด — baseline คือ “สภาพที่ verified แล้วและใช้เป็น reference point” ในระบบหนึ่งมีหลาย baseline:
- Design baseline — design ที่ approved หลัง design review
- Pre-test baseline — ก่อนเริ่ม UAT
- Production baseline — version ที่ขึ้น production
- Security baseline (เช่น CIS benchmarks) — config ขั้นต่ำของ security ที่ทุก server ต้องผ่าน
Baseline ทำให้:
- Rollback กลับมา known-good state ได้
- เปรียบเทียบ “ปัจจุบัน vs baseline” → หา drift
- กระบวนการ audit มีจุดอ้างอิงร่วม
SoD ใน Configuration Management
กับดักใหญ่: developer = คน promote โค้ดไป production
ในบริษัทเล็ก developer เป็นทุกอย่าง — เขียนโค้ด ทดสอบ deploy เอง
นี่คือ control gap ที่ IS auditor จะ flag ทันทีเพราะ:
- Developer มีแรงจูงใจให้โค้ดของตัวเองผ่าน — แม้จะมี bug ที่ตัวเองรู้
- ไม่มีใคร independent ตรวจก่อน production
- Bypass change control ทำได้ง่าย — เพราะ developer ก็คือคนที่ approve
หลัก SoD: developer commit code → reviewer approve → release manager promote (3 บทบาท ห้ามคนเดียวกันทั้งหมด)
ในระบบ DevOps ที่ทำให้กระบวนการ automated — SoD ฝังใน pipeline:
- Developer commit ได้ แต่ approve PR ของตัวเองไม่ได้
- Auto-deploy production ต้องผ่าน peer review + automated test pass + security scan pass
- Audit trail ครบใน Git + CI/CD logs
Release Management — รอบการ release ที่มีโครง
Configuration management = ควบคุม what จะ deploy Release management = ควบคุม when + how จะ deploy
Release ที่ดีมี:
- Release schedule — กำหนดล่วงหน้า ไม่ใช่ deploy เมื่อ developer พร้อม
- Release content — รวมอะไรบ้าง (features, bug fixes, security patches)
- Communication — แจ้ง user ล่วงหน้า โดยเฉพาะถ้ามี downtime
- Rollback plan — ถ้า release พัง กลับสภาพเดิมยังไง
- Post-release verification — หลัง deploy ตรวจอะไรบ้างก่อนปิด ticket
Emergency release มีกระบวนการแยก — เร็วกว่า แต่ยังต้องมี audit trail
เรื่อง change management ในบริบท operations (เมื่อระบบ live แล้วต้อง patch / update ตลอดเวลา) — เดี๋ยว Domain 4 จะลง change/release management ในมุมการ run system
Data Migration — ย้ายข้อมูลไม่ใช่แค่กด copy
กับดักหลัก: data conversion = รัน migration script
ผิด — data conversion เป็นกระบวนการครบที่ต้องวางแผน ทดสอบ และ verify อย่างเป็นทางการ ก่อน-ระหว่าง-หลัง
Migration Architecture: 4 Components
ทุก migration project มี 4 ขั้นตอนหลัก:
1. Unload — ดึงข้อมูลจากระบบเก่าออก
- format ที่จะดึง (CSV, JSON, direct DB export)
- partial หรือ full extract
- locking strategy เพื่อไม่กระทบ production
2. Cleanse — ทำความสะอาดข้อมูล
- ลบ duplicate
- แก้ format ที่ผิด
- เติม missing field ที่บังคับ
- ตัดสิน “data ที่บกพร่อง” — ลบ / แก้ / เก็บไว้แล้ว flag
3. Transfer — ส่งข้อมูลไประบบใหม่
- Encryption ระหว่าง transfer (ถ้า sensitive)
- Field-level mapping — field “customer_name” ของระบบเก่า = ฟิลด์ไหนของระบบใหม่
- Format conversion (DD-MM-YYYY → YYYY-MM-DD)
4. Load — โหลดข้อมูลเข้าระบบใหม่
- Validate ทุก record ผ่าน edit checks ของระบบใหม่
- Handle exception (record ที่ load ไม่ได้)
- Reconcile — count ข้อมูลที่ load สำเร็จ vs count ที่ unload
Data Cleansing — ขั้นตอนที่ห้าม skip
กับดัก: ระบบใหม่ดี ข้อมูลที่ migrate มาก็ดีไปเอง
ผิด — ถ้าข้อมูลในระบบเก่ามีปัญหา (ซ้ำซ้อน, ขาดหายร่วม, format ผิด) ระบบใหม่จะรับมรดกปัญหา
ตัวอย่างที่เห็นบ่อย:
- ระบบเก่าไม่มี constraint บน phone number → มี record ที่เก็บ “ไม่มี”, “0”, “9999999999”, “082-xxx-xxxx” — migrate ไประบบใหม่ที่ require phone format → load fail หลายร้อยรายการ
- ระบบเก่ามี customer ซ้ำ 3-4 record/คน เพราะไม่มี dedup logic → migrate ตรงๆ → ระบบใหม่ก็มี customer ซ้ำเหมือนเดิม
- ระบบเก่ามี master data ที่ inactive แต่ยังอยู่ในระบบ → migrate มาทำให้ master data ระบบใหม่รก
มุม IS auditor: ก่อน migration ขอดู data profiling report + data cleansing plan ถ้าไม่มี = red flag ใหญ่
Field-Level Mapping
ทุก field ของระบบเก่าต้อง map ไปยัง field ของระบบใหม่ — และต้องมีคน sign-off ว่า mapping นี้ถูก
ระบบใหญ่ๆ มี mapping document หลายร้อยถึงหลายพัน field — งานที่ tedious แต่สำคัญ
Changeover Techniques: 3 ทางเลือก กับ Trade-off
ถึงตรงนี้ data ย้ายมาแล้ว ระบบใหม่พร้อมทำงาน — แต่ เปลี่ยนจากระบบเก่าเป็นระบบใหม่ยังไง?
มี 3 กลยุทธ์ แต่ละแบบ trade-off คนละด้าน:
1. Parallel Changeover
ใช้ ทั้ง 2 ระบบพร้อมกัน ในช่วงหนึ่ง — เปรียบเทียบ output ทุกวัน เมื่อมั่นใจว่าระบบใหม่ output ตรงกับระบบเก่า → decommission ระบบเก่า
ข้อดี:
- ความเสี่ยงต่ำสุด — มี safety net เสมอ
- เห็น problem ของระบบใหม่ก่อนที่จะรับ load 100%
ข้อเสีย:
- User ทำงานซ้อน 2 ระบบ — เหนื่อยมาก
- ต้นทุน operations 2 เท่าในช่วงนั้น
- Reconciliation effort สูง
เหมาะกับ: ระบบที่ critical สูง (banking core, healthcare records) — ที่ลูกค้าหายไม่ได้
2. Phased Changeover
เปลี่ยน module ทีละ module หรือ business unit ทีละหน่วย
ตัวอย่าง: ระบบ ERP ใหม่ — เริ่มที่ฝ่ายบัญชีก่อน → 3 เดือนให้ฝ่ายขาย → 3 เดือนต่อให้ฝ่ายผลิต
ข้อดี:
- Risk distributed — ถ้าพัง พังเฉพาะส่วน
- เรียนรู้จาก phase แรก ปรับปรุงก่อน phase ถัดไป
ข้อเสีย:
- ระบบเก่ากับใหม่ต้อง integrate กันชั่วคราว — งานเพิ่ม
- Change management ซับซ้อน — บางคนใช้ระบบเก่า บางคนใช้ใหม่
- Data inconsistency ระหว่าง modules ที่ migrated แล้วยังไม่ migrate
เหมาะกับ: ระบบใหญ่ที่ครอบคลุมหลายหน่วย — ที่ไม่จำเป็นต้องเปลี่ยนพร้อมกัน
3. Abrupt / Direct Cutover
วันนึง — ปิดระบบเก่า เปิดระบบใหม่ ใช้งานทันที
ข้อดี:
- เร็วที่สุด
- ต้นทุน operations ต่ำสุด — ไม่ต้องรัน 2 ระบบ
- บังคับให้ user ใช้ระบบใหม่จริง — ไม่มีทางเลือกกลับ
ข้อเสีย:
- ความเสี่ยงสูงสุด — ไม่มี safety net
- ถ้าพังกลางวัน = ธุรกิจหยุดทันที
- Rollback plan ต้องทดสอบมาแล้วจริงๆ
เหมาะกับ: ระบบที่เล็กและไม่ critical, หรือระบบที่ technical ไม่อนุญาตให้ run parallel ได้
มุม IS auditor: ดูว่าบริษัทเลือก changeover technique ที่เหมาะกับ risk profile ของระบบหรือไม่ — และมี risk-based justification สำหรับการเลือกหรือไม่ บริษัทที่เลือก abrupt cutover เพราะ “ประหยัดเงิน” โดยไม่มี rollback plan ที่ทดสอบ = control gap ระดับ governance
Rollback Plan — แผน B ที่ห้ามมีแค่บนกระดาษ
กับดักร้ายแรง: มี rollback plan = ปลอดภัย
ไม่จริงครับ — Rollback plan ที่ไม่เคยทดสอบ = ไม่รู้ว่าใช้งานได้จริงไหม
ตัวอย่างที่เห็นบ่อย: บริษัทเขียน rollback plan ว่า “ถ้าระบบใหม่พัง — restore ระบบเก่าจาก backup” → วัน go-live ระบบใหม่พัง → ลอง restore → backup ของระบบเก่าใช้กับ infrastructure ใหม่ไม่ได้ → infrastructure ที่ใช้รัน migration ลบทับของเก่าไปแล้ว → ฉุกเฉิน
Rollback plan ที่ดีต้องมี:
- Pre-cutover snapshot ของระบบเก่า + ของ data ที่ปิดท้ายก่อน migrate
- Tested rollback procedure — เคยรัน end-to-end ใน staging environment
- Decision criteria — เกณฑ์ที่บอกว่า “ถึงจุดนี้ต้อง rollback” (เช่น ถ้า error rate > 5% ใน 4 ชั่วโมงแรก)
- Decision authority — ใครเป็นคนตัดสินใจ rollback (มักเป็น project sponsor + technical lead)
- Maximum rollback window — หลังจาก go-live กี่ชั่วโมง / วัน rollback ยังเป็นทางเลือก
มุมที่ผู้บริหารต้องเข้าใจ: rollback plan ที่ดีไม่ได้ทำให้โปรเจ็ค “ดูไม่มั่นใจ” — มัน demonstrate professional risk management ทีมที่ไม่มี rollback plan ไม่ใช่ทีมที่กล้าหาญ — เป็นทีมที่ประมาท
End-User Training — ไม่ใช่กิจกรรมท้ายสุด
กับดัก: training = สัปดาห์ก่อน go-live
ผิด — Training ที่ดีมี timing ที่เป็นส่วนหนึ่งของ control:
- เริ่มเร็วเกินไป → user ลืมก่อน go-live
- เริ่มช้าเกินไป → user ไม่มั่นใจ go-live ผ่านไปด้วยปัญหา
Training ที่ดีต้องมี:
- Training plan ที่ design ตั้งแต่ early phase ของโปรเจ็ค ไม่ใช่ afterthought
- Tailored by role — ฝ่ายบัญชีกับฝ่ายขายต้องเรียนคนละเรื่อง
- Hands-on practice ในสภาพแวดล้อม training (ไม่ใช่ production)
- Train-the-trainer สำหรับองค์กรใหญ่ — ฝึก super user / champion ในแต่ละทีมก่อน → ให้เขาไปฝึกทีมตัวเอง
- Reference material ที่ user เปิดดูได้หลัง training (cheat sheet, video, FAQ)
- Post-go-live support — มี help desk ที่พร้อมช่วยใน first 30 days
มุม IS auditor: Training ที่ขาด = ระบบที่ดีก็ deliver benefit ไม่เต็มที่ — ผูกกลับไป business case ที่ promise benefit ไว้ ถ้า training ไม่พอ → benefit ไม่เกิด → PIR (ตอนหน้า) จะ flag ระบบนี้ “ล้มเหลว”
ทำไมเรื่องนี้สำคัญกับ exam
ผมเห็น 6 trap pattern หลักของ Section 3.6 + 3.7:
- Configuration management = version control ของ code — ผิด ครอบคลุม IT-wide
- CMDB = hardware list — ผิด ต้องมี relationships + history
- Baseline = final version — ผิด เป็น stable reference point
- Parallel changeover = run 2 ระบบตลอดไป — ผิด ชั่วคราว
- Data conversion = รัน migration script — ผิด เป็นกระบวนการครบ
- Rollback plan บนกระดาษ = ปลอดภัย — ผิด ต้องทดสอบจริง
จำ 6 ข้อนี้ + flow ของ Unload-Cleanse-Transfer-Load + 3 changeover techniques + พื้นฐาน config management — Section 3.6 + 3.7 ผ่านแล้วเกินครึ่ง
ระบบขึ้น production แล้ว — user ใช้แล้ว ทุกคนเฉลิมฉลอง project manager เลื่อนไปโปรเจ็คถัดไป
แต่สำหรับ IS auditor — งานยังไม่จบ
อีก 6-12 เดือนข้างหน้ามี postimplementation review ที่จะตอบคำถามที่ business case เคยตั้งไว้ — “ระบบนี้ deliver benefit ตามที่ promise ไหม”
นี่คือเรื่องของตอนสุดท้ายของ Domain 3
อ้างอิง CRM (CISA Review Manual 28th Edition): Domain 3: Section 3.6 Implementation Configuration and Release Management + Section 3.7 System Migration, Infrastructure Deployment and Data Conversion
