ISO 29110 EP3: เตรียมตัวสอบใบรับรองยังไง

14
พฤษภาคม

หลังจากบทความ ISO/IEC 29110 คืออะไร และ EP2: ขั้นตอน Certification และ Audit Process มีคำถามตามมาว่า — แล้ว ทีมเราต้องเตรียมตัวยังไง, ใครต้องสอบบ้าง, ต้องรู้อะไรก่อน, และ ทำอะไรก่อนวันสอบจริง

EP3 นี้คือ Playbook เตรียมตัว ตั้งแต่วันที่ตัดสินใจขอ certification จนถึงวัน Stage 2 Audit — เขียนจากประสบการณ์ที่ทีม Grand Linux Solution ผ่าน Audit จริงต่อเนื่อง 10 ปี ตั้งแต่ปี 2558 (4 ใบรับรอง) และผ่าน Surveillance ทุกรอบ

เหมาะกับ:

ทีมพัฒนาซอฟต์แวร์ขนาดเล็ก-กลาง (VSE) ที่จะขอ ISO 29110 ครั้งแรก
หัวหน้าทีม / PM ที่ต้องวาง roadmap เตรียมสอบ
Developer ที่ถูกมอบหมายเป็นเจ้าของเอกสาร / process owner
ผู้บริหารที่ต้องอนุมัติ budget และ resource สำหรับเตรียม certification

สรุปสั้น: เตรียมตัวสอบ ISO 29110 Basic Profile ใช้เวลา 4-6 เดือน สำหรับทีมที่ยังไม่มี process เป็นทางการ — ต้องมี (1) คน: PM, Process Owner, Internal Auditor, ผู้บริหารสนับสนุน (2) เอกสาร: Work Products ครบทั้ง 2 process (PM + SI) (3) ระบบ: version control, issue tracker, document repo (4) หลักฐาน: traceability + review trail ที่ใช้งานจริงในโครงการปัจจุบัน

ใครต้องสอบ ISO 29110 บ้าง

ISO/IEC 29110 ออกแบบมาสำหรับ VSE (Very Small Entity) — องค์กร / โครงการ / ทีม ที่มีคนทำงานพัฒนาซอฟต์แวร์ ไม่เกิน 25 คน (ตามนิยามของ ISO/IEC TR 29110-1) แต่ในทางปฏิบัติ มีบริษัทขนาดใหญ่หลายแห่งใช้กับ ทีมย่อย / business unit ที่ขนาดเข้านิยาม VSE ก็ได้

กลุ่มที่ควรสอบ

กลุ่ม	เหตุผลที่ต้องสอบ
บริษัทพัฒนาซอฟต์แวร์ที่ขายภาครัฐ	TOR หลายโครงการระบุ ISO 29110 เป็นคุณสมบัติเบื้องต้น
Software vendor / SI ที่ทำโครงการ Enterprise	ลูกค้าใหญ่ใช้เป็น filter ในการ vendor screening
ทีม in-house dev ของบริษัทใหญ่	ใช้พิสูจน์ว่าทีมพัฒนาภายในมีมาตรฐานเทียบเท่า vendor ภายนอก
Startup / SME ซอฟต์แวร์ ที่อยากเข้า Enterprise market	ใบรับรองช่วยลด barrier การเข้าหา enterprise customer
หน่วยงานราชการที่ทำซอฟต์แวร์เอง	ปฏิบัติตามนโยบาย รัฐบาลดิจิทัล และยกระดับคุณภาพ ระบบราชการ

คนที่ "ต้องเข้าสอบ" ไม่ใช่บุคคลคนเดียว — แต่เป็น ทีม ทั้งทีม Auditor จะสัมภาษณ์ตำแหน่งจริงในโครงการ ไม่ใช่แค่ผู้บริหาร — ดูรายละเอียดในหัวข้อ Role Matrix

4 สิ่งที่ต้องรู้ก่อนเริ่มเตรียมตัว

1. มี 4 Profile ของ ISO 29110 — เลือกอันที่เหมาะกับทีม

Profile	เหมาะกับ	หมายเหตุ
Entry	ทีมเริ่มต้น ไม่กี่คน 1 โครงการ	เป็น stepping stone ก่อนขึ้น Basic
Basic	ทีม ≤25 คน หลายโครงการ — นิยมสุด	มาตรฐาน ISO/IEC 29110-4-1 (อิงเป็นหลักในตลาดไทย)
Intermediate	ทีมหลายโครงการพร้อมกัน + ต้องการ portfolio management	ส่วนนี้ยังอยู่ระหว่างพัฒนา/ใช้น้อย
Advanced	ทีมระดับโตที่อยากต่อยอดสู่ ISO/IEC 12207 หรือ CMMI	ส่วนนี้ยังอยู่ระหว่างพัฒนา/ใช้น้อย

ส่วนใหญ่ที่บริษัทไทยและภาครัฐยอมรับคือ Basic Profile — ใบรับรองที่ Grand Linux Solution ถืออยู่ก็คือ Basic Profile ตามมาตรฐาน ISO/IEC 29110-4-1:2018

2. มี 2 Process Group หลักที่ต้อง implement

Process	โฟกัส	ใครเป็นเจ้าของ
Project Management (PM)	วางแผน, ติดตาม, ปิดโครงการ, จัดการ risk + change	Project Manager
Software Implementation (SI)	วิเคราะห์ requirement, ออกแบบ, เขียน code, test, ส่งมอบ, maintenance	Tech Lead / Software Engineer

3. มาตรฐานที่ต้องอ่าน (อย่างน้อย 3 เล่ม)

ISO/IEC 29110-4-1:2018 — Profile specifications (สอบตามเล่มนี้)
ISO/IEC TR 29110-5-1-2 — Management and engineering guide (เล่มที่บอกว่าให้ทำอะไรในแต่ละ activity — เล่มหลักที่ทีมใช้ทำงาน)
ISO/IEC TR 29110-3-1 — Assessment guide (เล่มที่ auditor ใช้)

มาตรฐานหลักซื้อจาก ISO Store ส่วน Technical Report (TR) เล่ม 5-1-2 ดาวน์โหลดได้ฟรีจาก ISO Online Browsing Platform

4. คำศัพท์ที่ทีมต้องรู้

คำ	ความหมาย
VSE	Very Small Entity — ทีมพัฒนาซอฟต์แวร์ ≤25 คน
Work Product	เอกสาร/output ที่กระบวนการสร้างขึ้น เช่น Project Plan, Test Report
CB	Certification Body — องค์กรที่ออกใบรับรอง เช่น TÜV NORD, SGS, BV
NC	Non-Conformity — สิ่งที่ไม่ตรงกับมาตรฐาน (Major/Minor)
OFI	Opportunity For Improvement — คำแนะนำที่ไม่ใช่ NC
Surveillance	Mini-audit ปีละครั้งระหว่าง 3 ปีของอายุใบรับรอง
Traceability	ความเชื่อมโยงระหว่าง Requirement → Design → Code → Test

Timeline เตรียมตัว 6 เดือน (ตัวอย่างจริง)

เดือน	งานหลัก	ผลลัพธ์ที่ต้องเห็น
เดือนที่ 1	Kickoff + ตั้งทีมเตรียมสอบ + Gap Analysis	Gap report + action plan
เดือนที่ 2	เขียน Process Manual + เลือก CB + ขอใบเสนอราคา	Process Manual v1 + เลือก CB
เดือนที่ 3	นำ process ลงโครงการนำร่อง + เริ่มสร้าง Work Product จริง	โครงการนำร่องเริ่มใช้ process
เดือนที่ 4	ขยายไปทุกโครงการ active + Training ทั้งทีม	ทุกโครงการมี Work Product ครบ
เดือนที่ 5	Internal Audit รอบที่ 1 + ปิด NC + Management Review	Internal audit report + corrective actions
เดือนที่ 6	Stage 1 Audit (Document Review) → Stage 2 Audit (On-site)	ใบรับรอง

หมายเหตุ: ถ้าทีมมี process เป็นทางการอยู่แล้ว (เช่นใช้ risk management + approval flow แบบเป็นระบบ) อาจย่อ timeline ลงเหลือ 3-4 เดือน — แต่ถ้าเริ่มจากศูนย์ อย่ายัด timeline เข้า 3 เดือน เพราะจะทำเอกสารแบบ "ทำเพื่อสอบ" ซึ่ง auditor มืออาชีพจับได้

Role Matrix — ใครในทีมต้องเข้าร่วม

บทบาท	ความรับผิดชอบหลัก	วันสอบจริงต้องตอบอะไร
Executive Sponsor (MD / ผู้บริหาร)	อนุมัติ resource + budget + Management Review	"ใช้ผลของ Management Review อย่างไรในการตัดสินใจ"
Quality Manager / Process Owner	ดูแล QMS, schedule internal audit, ติดตาม NC	"แสดง process document + revision history"
Project Manager	เจ้าของ Project Plan, Status Report, Risk Register	"แสดง project plan ของโครงการที่ active + change request log"
Tech Lead / Software Architect	เจ้าของ Software Design, Architecture Decision	"แสดง design document + trace กลับไปที่ requirement"
Developer	เขียน code ตาม process, commit ตาม convention, review	"อธิบาย code review process + แสดง pull request"
QA / Tester	เจ้าของ Test Cases, Test Report, defect log	"แสดง test report + defect ที่ trace กลับ requirement"
Internal Auditor	ตรวจ process ภายในก่อน external audit	"แสดง internal audit report + NC ที่ปิดแล้ว"
Document / Configuration Owner	ดูแล document repository + version control	"แสดง versioning + backup policy ของเอกสาร"

คน 1 คนรับได้หลายบทบาท ถ้าทีมเล็ก — แต่ Internal Auditor ห้ามเป็นเจ้าของ process ที่ตัวเองตรวจ (conflict of interest)

เอกสาร Work Product ที่ต้องเตรียม

Basic Profile กำหนด Work Product ขั้นต่ำสำหรับ 2 process — เป็นรายการที่ auditor จะขอดูจริง:

Process	Work Products หลัก	ผู้รับผิดชอบ
Project Management (PM)	Statement of Work	PM + Customer
	Project Plan (timeline, resource, milestone)	PM
	Risk Register + Mitigation Plan	PM
	Change Request Log + Approval Trail	PM + Customer
	Progress / Status Report	PM
	Acceptance Record (UAT Sign-off)	PM + Customer
Software Implementation (SI)	Requirements Specification	BA / Tech Lead
	Software Design (Architecture + Component)	Tech Lead
	Source Code (controlled in VCS)	Developer
	Traceability Matrix (Req ↔ Design ↔ Code ↔ Test)	BA + QA
	Test Cases + Test Report	QA
	Defect Log + Resolution	QA + Developer
	User Manual + Installation Guide	Tech Writer / Dev
	Maintenance Plan	PM + Tech Lead

กฎทอง 3 ข้อของ Work Product

"Show me the evidence" — เอกสารต้องเป็นของจริง ใช้จริง ในโครงการจริง ไม่ใช่ template ว่าง
Reviewed + Approved — เอกสารสำคัญต้องมีหลักฐานการ review + approval (ลายเซ็น, comment, pull request review)
Versioned — ทุกเอกสารต้องมี version history หรือ revision date

ระบบและเครื่องมือที่ต้องมี

Version Control System — Git (GitHub, GitLab, Gitea, Bitbucket) สำหรับ source code + เอกสารที่เป็น text
Issue Tracker — Jira, Redmine, GitHub Issues, Azure DevOps — เก็บ requirement, defect, change request
Document Repository — SharePoint, Confluence, Google Drive — ต้องมี access control + version history
CI/CD Pipeline — Jenkins, GitLab CI, GitHub Actions — เป็นหลักฐานว่า build + test เป็นอัตโนมัติ + repeatable
Communication Log — Slack/Teams ที่ archive ได้ + อีเมลที่เก็บไว้ — เป็นหลักฐาน change request + approval
Backup + DR plan — ระบบเหล่านี้ต้อง backup + กู้คืนได้ ดูแนวทาง Disaster Recovery

ไม่จำเป็นต้องใช้ tool แพง — Open source / free tier ใช้ได้ทั้งหมด แต่ต้อง ใช้จริงและสม่ำเสมอ

Pre-audit Checklist (4 สัปดาห์ก่อนวันสอบ)

ก่อน Stage 2 Audit 1 เดือน ทีมต้องผ่าน checklist นี้:

รายการ	เกณฑ์ผ่าน
Process Manual	เผยแพร่ + signed-off + ทีมรู้ที่อยู่ไฟล์
Work Product ของโครงการตัวอย่าง	ครบทุกประเภท อย่างน้อย 1 โครงการที่ active
Traceability Matrix	Req → Design → Code → Test ครบ ไม่มี orphan
Internal Audit Report	ทำแล้วอย่างน้อย 1 รอบ — NC ปิดหมด
Management Review Minutes	มีอย่างน้อย 1 ครั้ง พร้อม decision log
Training Record	ทุกคนในทีมเคยถูก onboarding process แล้ว
Change Request ของโครงการตัวอย่าง	มี approval trail ครบ
Test Report ของ release ล่าสุด	trace กลับ requirement ได้
Document version control	เปิดประวัติเอกสารแสดงได้ในทันที
Mock Audit (Dry-run)	ซ้อมตอบ auditor 1 รอบ — เช็คว่าทีมตอบสอดคล้องกัน

วันสอบจริง — Mindset และวิธีตอบ Auditor

Mindset 3 ข้อ

Auditor มาช่วย ไม่ได้มาจับผิด — เขาทำหน้าที่ verify ว่ามาตรฐานถูก implement จริง
"ไม่ทราบ ขออนุญาตเช็ค" ดีกว่าเดา — เดาแล้วผิด จะ trigger คำถามต่อเนื่อง
โชว์ระบบที่ใช้จริง อย่าโชว์เอกสารที่ทำมาเฉพาะตอบ audit — auditor มืออาชีพจับ pattern ได้

การเตรียมตัววันสอบ

เตรียม Project ตัวอย่างที่ active 1-2 โครงการ ที่ Work Product ครบและสด
ทุกคนเข้าใจ scope ของ audit + รู้บทบาทตัวเอง
เปิด screen + ระบบจริง ระหว่างสัมภาษณ์ — โชว์ live ดีกว่า PDF
เตรียม เครื่องสำรอง + อินเทอร์เน็ตสำรอง — เหตุการณ์เน็ตล่มกลาง audit เป็น red flag
มี note-taker 1 คน บันทึก findings ทันที

ตัวอย่างคำถาม + วิธีตอบที่ดี

คำถาม Auditor	วิธีตอบที่ดี
"แสดง requirement ของโครงการ X"	เปิด issue tracker / SharePoint ที่เก็บไฟล์จริง + แสดง revision history
"Defect นี้ trace กลับไปที่ requirement ไหน"	เปิด traceability matrix + คลิกตาม link จริง
"Change Request นี้ใครอนุมัติ"	เปิด CR log + แสดง approval (อีเมล/ticket comment/pull request review)
"Internal audit รอบล่าสุดเจออะไร"	เปิด internal audit report + corrective action plan + evidence ว่าปิด NC แล้ว
"ทีมรู้ process นี้ได้ยังไง"	แสดง training record + ลิงก์ที่ทีมเข้าไปอ่าน process จริง

7 ข้อผิดพลาดที่พบบ่อยตอนเตรียมตัว

เริ่มเตรียม 1 เดือนก่อนสอบ — ไม่พอ ขั้นต่ำ 4 เดือนสำหรับทีมที่เริ่มจากศูนย์
คนเดียวทำเอกสารทั้งหมด — auditor สัมภาษณ์หลายคน เอกสารที่ "เจ้าของไม่ใช่คนใช้" จะถูกจับได้ในการสัมภาษณ์
ลอก template มาเปล่า — Process Manual ที่ค้นด้วย Google ได้ ไม่สะท้อนงานจริง — เขียนเอง
ข้าม Internal Audit — เป็น mandatory requirement ของมาตรฐาน + ลด surprise ตอน Stage 2
เอกสารทำขึ้นเฉพาะตอน audit — auditor จับได้จาก revision date ที่กระจุกอยู่ในช่วงเดียวกัน หรือ filename pattern ที่ดูเป็น batch เดียวกัน — ดูเพิ่มใน EP2: 5 สาเหตุที่ทีมตก Audit บ่อยที่สุด
ใช้ external consultant ทำแทน — consultant ช่วยได้ แต่ process ต้องเป็นของทีม ไม่งั้นจะตอบคำถามไม่ตรงกัน
ผู้บริหารไม่เข้า Management Review — Management Review เป็น mandatory + ต้องมี evidence ว่าผู้บริหารตัดสินใจจากผลตรวจ

🚩 Red flag: เคยมีทีมที่จ้าง consultant ทำเอกสารให้ทั้งหมด แล้วทีมไม่เคยอ่าน — ตอน Stage 2 auditor ถาม developer ว่า "code review process ของคุณทำงานยังไง" ตอบไม่ได้ → Major NC ทันที

เกี่ยวกับ Saeree ERP — 10 ปี ISO 29110 ติดต่อกัน

บริษัท แกรนด์ลีนุกซ์ โซลูชั่น จำกัด ผ่าน ISO/IEC 29110 Basic Profile ตั้งแต่ปี 2558 และต่ออายุต่อเนื่อง 10 ปีติดต่อกัน (4 ใบรับรอง: 2558-2561, 2561-2564, 2564-2567, 2567-2570) ใบรับรองปัจจุบันออกโดย TÜV NORD ตามมาตรฐาน ISO/IEC 29110-4-1:2018 มีผล 13 พ.ย. 2567 - 12 พ.ย. 2570 และผ่าน Surveillance ทุกปีไม่หลุดเลย

ทุกโครงการ Saeree ERP ที่ส่งมอบให้ลูกค้าใช้ process ตามมาตรฐาน ไม่ใช่แค่ในวันสอบ — Project Management Plan, Requirements Specification, Test Report, User Manual, Maintenance Plan ของทุก deployment trace กันได้ครบ พร้อมส่งให้ลูกค้า audit เองได้ตลอดเวลา

ดูเพิ่ม เหตุการณ์การได้รับ ISO 29110 และ ทำไมต้อง Saeree ERP

สรุป — 3 ประโยคที่อยากให้จำ

เตรียมตัวสอบ ISO 29110 = เปลี่ยน process จริง ไม่ใช่เขียนเอกสารใหม่
คนเข้าสอบไม่ใช่ผู้บริหารคนเดียว — auditor สัมภาษณ์ทีมจริงทั้งทีม
ใบรับรองอยู่ได้ 3 ปี + Surveillance ทุกปี — ทีมที่ "ทำเพื่อสอบครั้งเดียว" จะหลุดในรอบ Surveillance แรก

เตรียมตัวสอบ ISO 29110 ไม่ได้ยากเพราะมาตรฐานยาก — แต่ยากเพราะต้องเปลี่ยนวิธีทำงานจริงให้สม่ำเสมอ พอทำได้แล้ว ใบรับรองคือผลพลอยได้ — สิ่งที่ได้จริงคือทีมที่ส่งมอบงานคุณภาพเหมือนกันทุกครั้ง 10 ปีติดต่อกัน
— Grand Linux Solution

บทความที่เกี่ยวข้อง:

แหล่งอ้างอิง

บทความนี้เขียนจากประสบการณ์จริงของทีม Grand Linux Solution ที่ผ่าน ISO 29110 Audit ต่อเนื่อง 10 ปี ตั้งแต่ปี 2558 — ติดต่อ sale@grandlinux.com หรือ 02-347-7730