Phase 1 — Feasibility Study#

ตอน 24 คุยไปแล้ว — ตอบคำถาม “ระบบนี้ควรสร้างไหม” + “build vs buy”

เนื้อหาส่วนนี้ทับกับ Section 3.2 มาก — ผมเลือกใช้ตอน 24 เป็น primary treatment ไม่อธิบายซ้ำ

Phase 2 — Requirements Definition#

ระบบจะทำอะไรได้บ้าง — ละเอียดระดับที่ developer/vendor เอาไปสร้างได้

Requirements ที่ดีต้องมีคุณสมบัติ:

• Testable — เขียนในรูปที่ทดสอบได้ ไม่ใช่ “ระบบต้องเร็ว” แต่เป็น “ระบบต้องตอบสนอง 95% ของ transaction ภายใน 2 วินาที”
• Traceable — ทุก requirement ต้อง trace กลับไป business need ใน business case ได้ (requirement traceability matrix)
• Complete — ครอบคลุม functional + non-functional (security, performance, usability, compliance) + control requirements

มุม IS auditor: ขอดู requirement traceability matrix ถ้าไม่มี = red flag เพราะหมายความว่าอาจจะมี requirement ที่ใส่เข้ามาภายหลังโดยไม่มี business justification หรือมี business need ที่หายไประหว่างทาง

Phase 3a — Software Selection & Acquisition (ถ้าเลือก buy)#

ถ้า feasibility study ตอบว่า “ซื้อ” แทนที่จะ “สร้าง” — เข้าสู่กระบวนการ acquisition ที่จะคุยลึกข้างล่างนี้

Phase 3b — Design#

ถ้าเลือก build เอง — ออกแบบระบบในระดับ technical

Design phase เกิด artifact หลายอย่าง:

• ERD (Entity Relationship Diagram) — โครงสร้างข้อมูล
• DFD (Data Flow Diagram) — การไหลของข้อมูลในระบบ
• System architecture — components ของระบบและ interface ระหว่างกัน
• Software baseline — version ของ design ที่ approved แล้ว
• Design freeze — จุดที่ design ถูก lock ทุกการเปลี่ยนแปลงหลังจุดนี้ต้องผ่าน change control

กับดัก: organization ที่ “ขอเปลี่ยน requirement” หลัง design freeze โดยไม่ผ่าน change control = control gap ใหญ่ developer มักยอมแก้ “เพราะแก้นิดเดียว” — ไม่ใช่หน้าที่ของ developer ที่จะตัดสิน

Phase 4a — Configuration (ถ้าซื้อระบบสำเร็จรูป)#

ระบบ COTS / ERP ที่ซื้อมาต้อง configure ให้เข้ากับ process ของบริษัท — ตั้งค่า workflow, master data, role permissions, reports

กับดัก: การ configure ไม่ใช่หน้าที่ของ vendor เพียงฝ่ายเดียว — buyer ต้องอนุมัติ configuration ก่อน production และ configuration changes ทั้งหมดต้องผ่าน change control เหมือน custom code

Phase 4b — Development (ถ้า build เอง)#

เขียนโค้ดตาม design — ใช้ programming standard, peer review, IDE, debugger

ขั้นตอนระดับโค้ดที่ auditor ต้องตรวจ:

• Coding standard ถูก enforce ผ่าน automated tool หรือ peer review
• Source code repository มี version control ครบและไม่อนุญาตให้ commit ตรงไปยัง production branch
• Code review ก่อน merge — ป้องกัน developer commit ไปแล้วไม่มีใครเห็น

Phase 5/6 — Testing + Implementation#

ทดสอบว่าระบบทำงานถูกตามที่ design ก่อน go-live — เรื่องนี้ลึกพอที่จะเป็นบทแยกใน ตอน 28

ในบทนี้รู้แค่ว่า: ก่อน go-live ต้องผ่าน UAT ที่ทำโดย end users (ไม่ใช่ vendor และไม่ใช่ IT) — และต้องมี certification + accreditation อย่างเป็นทางการ

ฝั่ง Build (สร้างเอง)#

ข้อดี

• ระบบตรงกับ process ของบริษัท 100%
• ควบคุม source code, IP, roadmap ได้เอง
• เปลี่ยนแปลงในอนาคตทำได้ตามต้องการ

ข้อเสีย

• เวลาและต้นทุนสูง
• ต้องมีทีม dev ที่มีความสามารถจริง
• ต้องบำรุงรักษาเอง
• Time-to-market ช้า

ฝั่ง Buy (ซื้อสำเร็จรูป / COTS)#

ข้อดี

• เร็วกว่า — vendor มี product ที่ใช้กับลูกค้าหลายเจ้าแล้ว
• ราคาต่อ feature ถูกกว่า เพราะ vendor amortize cost
• Best practice ฝังใน process ของระบบ
• Vendor รับผิดชอบ patching, security update

ข้อเสีย

• Process ของบริษัทอาจต้องปรับให้เข้ากับระบบ ไม่ใช่ระบบปรับให้เข้ากับ process
• Customization มี limit
• ขึ้นอยู่กับ vendor — vendor lock-in, vendor financial stability เป็น risk
• Source code ไม่ได้
• Right-to-audit ต้อง negotiate ในสัญญา

มุม IS auditor: การตัดสินใจ build vs buy ต้องอ้าง gap analysis ที่เปรียบเทียบ requirement ของบริษัทกับ feature ของ COTS option ที่พิจารณา — ถ้า gap น้อย → buy ทำให้ ROI สูง ถ้า gap ใหญ่ + customization แพง → ใกล้เคียงกับ build อยู่ดี

ขั้นที่ 1 — เขียน RFP / ITT#

RFP (Request for Proposal) หรือ ITT (Invitation to Tender) = เอกสารที่บริษัทส่งไปยัง vendor หลายราย ระบุ:

• ระบบที่ต้องการ — functional + non-functional requirements
• เกณฑ์การประเมิน — vendor จะถูกวัดด้วยอะไร
• เงื่อนไขสัญญาที่ไม่ negotiate — เช่น right-to-audit, source code escrow, SLA
• Timeline ของ procurement

กับดัก: “เลือก vendor ก่อนแล้วค่อยทำ RFP เพื่อให้กระบวนการดูถูกต้อง” — นี่คือสิ่งที่ auditor จะ flag ทันที RFP ต้องส่งให้ vendor หลายรายและ vendor ที่ชนะต้องชนะตามเกณฑ์ที่ตั้งไว้ล่วงหน้า

ขั้นที่ 2 — ประเมิน Vendor#

เกณฑ์การประเมินที่ดี ตั้งไว้ก่อน เปิดซองและมี น้ำหนัก ที่ approve โดย steering committee แล้ว — ครอบคลุม:

• Functional fit — ระบบของ vendor ตอบ requirement ได้กี่เปอร์เซ็นต์
• Vendor financial stability — vendor จะอยู่กับเราอีกกี่ปี ดู financial statement, customer references
• Technical compatibility — เข้ากับ infrastructure ปัจจุบันได้ไหม
• Support model — มี support ระดับไหน timezone ไหน SLA แบบใด
• Total cost of ownership — ไม่ใช่แค่ license แต่รวม customization, training, maintenance, integration
• Security posture — vendor มี SOC report ไหม certifications อะไร

กับดัก: vendor ที่ราคาถูกที่สุดไม่ใช่ vendor ที่ดีที่สุด — และ vendor ที่ทำ presentation สวยที่สุดก็ไม่ใช่ vendor ที่ดีที่สุด การประเมินต้องตามเกณฑ์ที่ตั้งไว้ก่อน

ขั้นที่ 3 — Proof of Concept (PoC)#

ก่อนเซ็นสัญญา vendor หลักๆ ควรทำ PoC — ลองให้ระบบทำ scenario สำคัญในสภาพแวดล้อมที่ใกล้เคียง production ให้ดู

PoC ตรวจ:

• ระบบทำงานได้จริงตามที่ presentation บอกไหม
• Performance พอไหม
• Integration กับระบบเดิมเป็นอย่างไร
• User experience จริง

ขั้นที่ 4 — สัญญา + Right-to-Audit Clause#

สัญญากับ vendor ต้องมี clause ที่สำคัญ — และนี่คือเรื่องที่ผูกกลับไป ตอน 19 ของ Domain 2 (Vendor Management)

• Right-to-audit — ลูกค้ามีสิทธิ์ตรวจ vendor หรือ require ให้ vendor ส่ง SOC report ที่ระดับเหมาะสม
• SLA (Service Level Agreement) — ระบุ availability, response time, resolution time + ค่าปรับเมื่อไม่ถึง
• Source code escrow — โค้ดถูกฝากไว้ที่บุคคลที่สาม (escrow agent) ถ้า vendor เจ๊ง / หยุด support → ลูกค้าได้โค้ดมา maintain ต่อ
• Data ownership — ข้อมูลที่อยู่ในระบบเป็นของลูกค้า ไม่ใช่ vendor
• Exit clause — ขั้นตอนการย้ายออกถ้าจะเลิกสัญญา ต้องส่งคืนข้อมูลในรูปแบบที่ใช้ต่อได้

มุม IS auditor: สัญญาที่ไม่มี right-to-audit = auditor ทำ assurance ไม่ได้ บริษัทที่เซ็นสัญญาแบบนี้กำลังโยน control assurance ออกไปให้ vendor

ขั้นที่ 5 — Acceptance Testing#

นี่คือกับดักที่อันตรายที่สุดของกระบวนการ acquisition และเป็นเรื่องที่ทดสอบบ่อยที่สุดในข้อสอบ

กับดัก ⚠️: Vendor ทำ acceptance testing แทน buyer

หลายบริษัททำให้ vendor “ทดสอบ” ระบบของตัวเอง แล้วส่ง test report มาให้ buyer อนุมัติ — ผิดครับ

เหตุผลคือ vendor มี incentive ให้ test ผ่าน:

• Vendor ได้เงินตอน acceptance
• Vendor รู้จุดอ่อนของระบบดีที่สุด — และมีเหตุผลที่จะไม่ทดสอบส่วนที่จะพัง
• Vendor อาจจะเปลี่ยนเวอร์ชันของระบบหลังจากผ่าน test

หลักของ acceptance testing สำหรับ acquired software:

• Buyer ทดสอบเอง ในสภาพแวดล้อมที่ buyer ควบคุม
• ใช้ test cases ที่ buyer เขียน ไม่ใช่ test cases ที่ vendor ส่งมา
• ทดสอบ edge cases + negative scenarios ที่ vendor มัก skip
• Sign-off เป็นทางการก่อนเริ่มใช้งานจริง

นี่คือเหตุผลที่ trap pattern “vendor does the testing for acquired software” ถูกแอบมาใน CISA exam บ่อยมาก — ตอบคำถามนี้ผิดเพราะคิดว่า “vendor เป็นผู้เชี่ยวชาญน่าจะทดสอบดีกว่า”