ลองเปรียบเทียบกับโรงเรียนก่อน#

ถ้าผมถามว่า “คุณภาพการศึกษา” หมายถึงอะไร คำตอบขึ้นกับว่ามองจากมุมไหน

มุมหนึ่ง: ข้อสอบปลายภาค — วัดผลลัพธ์ที่นักเรียนได้ → นี่คือ Quality Control (QC)

มุมที่สอง: การออกแบบหลักสูตร การฝึกอบรมครู สภาพห้องเรียน ระบบ feedback — สิ่งที่ สร้างคุณภาพ ตั้งแต่ต้นทาง → นี่คือ Quality Assurance (QA)

โรงเรียนที่ focus แค่ข้อสอบปลายภาค (QC) แต่ไม่สนใจหลักสูตร + ครู + ห้องเรียน (QA) → จะได้คุณภาพไม่สม่ำเสมอ ขึ้นกับนักเรียนที่เก่งเอง ไม่ใช่ระบบ

ในทาง IT ก็เหมือนกันเลย

นิยามที่ออกข้อสอบ#

Quality Assurance (QA) = การกระทำที่มีระบบ ที่ทำให้มั่นใจว่า product จะ conform กับ requirements

ลักษณะสำคัญ:

• Proactive — สร้างคุณภาพไว้ใน process ตั้งแต่ต้น
• Process-focused — เน้นที่ how (กระบวนการที่ผลิต product)
• Preventive — ป้องกันไม่ให้ defect เกิด

Quality Control (QC) = การสังเกต + ทดสอบ ที่ verify ว่า output จริง match กับ specification

ลักษณะสำคัญ:

• Reactive — ตรวจหลัง product ทำเสร็จ
• Product-focused — เน้นที่ what (ตัว output)
• Detective — จับ defect หลังเกิด

ตัวอย่างใน IT Context#

ในกระบวนการ software development:

QA = ออกแบบ coding standard, peer review process, secure development training, design review checkpoint — สิ่งที่ทำให้ code “ดีตั้งแต่ตอนเขียน”

QC = unit test, integration test, UAT, security scan — สิ่งที่ test code “ทำงานถูกตามที่ design”

ทั้งสองต้องมีครับ ไม่ใช่แทนที่กัน

Trap: “เรามี testing team แสดงว่ามี QA”

ผิดครับ testing team = QC ไม่ใช่ QA QA คือ team ที่ดูแล process design + standard + training (อาจ overlap กับ testing team แต่ไม่ใช่สิ่งเดียวกัน)

QA + Version Control — Connection ที่หลายคนข้าม#

CRM Section 2.11.1 ระบุชัดเจน: QA personnel verify system changes ผ่าน:

• Source code management systems — version control (Git, SVN)
• Release management policies — ระบบที่ control deployment
• Configuration management — proper arrangement ของ libraries + repositories

นี่คือเหตุผลที่ QA function ใน software development ต้อง integrate กับ version control + release pipeline ไม่ใช่แยกเป็น manual review หลัง dev เสร็จ

Pattern ที่เห็นในวงการ:

• บริษัท mature: QA = tooling ใน CI/CD pipeline (auto-test, static code analysis, security scan) + human review ที่ critical decision points
• บริษัทที่ยัง legacy: QA = manual checklist ที่ทำหลัง dev → catch defects ช้า + cost สูง

เดี๋ยว Domain 3 จะลง SDLC + DevSecOps ลึกขึ้น ตอนนี้รู้ว่า QA function ใน Domain 2 = governance + structure ส่วน implementation อยู่ที่ Domain 3 ครับ

ทำไมต้องแยกในมุม Auditor#

IS auditor ที่ดี ตรวจทั้ง 2 มิติ:

• มี standard + procedure ที่เพียงพอมั้ย (QA)
• Output จริง test และ verify มั้ย (QC)

ถ้าตรวจแค่ output (มี test report) แล้วบอกว่า “QA ดี” = เป็นการ misclassify ที่ทำให้ recommendation ผิดเป้า

หลักการ#

QA function ต้อง organizationally independent จาก development management

ฟังคุ้นๆ ใช่มั้ยครับ เพราะมันคือ principle เดียวกัน กับ audit independence ที่เราเรียนใน Domain 1

หลักการคือ คนที่ตัดสินคุณภาพต้องไม่ใช่ใต้บังคับบัญชาของคนที่สร้าง product เพราะถ้าใต้บังคับบัญชา จะถูก pressure ให้ “ผ่าน” ตลอด

Trap คลาสสิก: นักเรียนตรวจข้อสอบตัวเอง#

ถ้าให้นักเรียนตรวจข้อสอบของตัวเอง — ไม่มีใครได้ 0 หรอกครับ ทุกคนจะเข้าข้างตัวเอง โดยที่อาจไม่ตั้งใจด้วยซ้ำ

หลักการเดียวกัน apply กับ:

• Developer review code ของตัวเอง
• DBA approve การ change ของตัวเองใน production
• IT manager sign off project ที่ตัวเองเป็น project sponsor

CRM ระบุชัดด้วยภาษา strong: “ไม่ว่ากรณีใด บุคคลไม่ควร review งานของตัวเอง”

ในบริษัทเล็ก — ทำยังไง?#

หลายบริษัทขนาดกลางบ่นว่า “ทีมไม่พอจะแยก” เหมือนกับ SoD ที่เราคุยใน ตอน 16B เลย

วิธีแก้:

• Compensating controls — review จากคนนอกแผนก, external review periodically
• Cross-team review — developer ทีม A review ทีม B
• Tool-based check — ใช้ automated security scan ที่ไม่ bias

QA Independence ที่ structural ทำไม่ได้ → ต้อง implement compensating mechanism ไม่ใช่ skip

Periodic Review ของ QA Function เอง#

อีก concept ที่น่าสนใจ — QA group เอง ต้องถูก review เป็นรายไตรมาส โดย QC group หรือ external

หลักการคือ ใครก็ตามที่ review งานคนอื่น ต้องถูก review โดยคนอื่นเช่นกัน ไม่มีใคร above review

ลองคิดถึงร้านเบเกอรี่#

ร้านเบเกอรี่ที่ขึ้นอยู่กับ “baker คนเดียวที่เก่ง” ขนมอร่อยทุกวัน ตราบใดที่ baker คนนั้นทำงาน

ถ้า baker ลาออก ร้านขายต่อไม่ได้เลย เพราะ recipe + technique อยู่ใน “หัว” ของ baker เท่านั้น ไม่มีใครเรียนรู้ได้

ตรงข้าม ร้านเบเกอรี่ chain ที่มี standardized recipe + procedure + training ขนมอาจไม่อร่อยเท่า baker เก่ง แต่ คุณภาพคงที่ ทุกสาขา + ขยายได้

นี่คือ Quality Management ทำให้คุณภาพไม่ขึ้นกับบุคคลครับ

องค์ประกอบของ Quality Management ที่ดี#

1. Documented processes — ทุกกระบวนการสำคัญถูกเขียน ไม่ใช่ tribal knowledge
2. Defined roles + responsibilities — ใครทำอะไร, ใครรับผิดชอบอะไร
3. Training programs — สอนพนักงานใหม่ให้ทำได้ตาม process
4. Performance measurement — KPI/KRI/KGI (ดู ตอน 20)
5. Improvement mechanism — PDCA หรือ similar
6. Audit trail — บันทึกว่า process ถูก follow

Quality Management ใน Domain ของ IT#

CRM ระบุว่า quality management ครอบคลุม:

• Software development
• Hardware acquisition + maintenance
• Day-to-day operations
• Service management
• Security management
• Resource management

ทุก IT function ครับ ไม่ใช่แค่ software development

Trap: “เรามี ISO certificate” = “เรามี quality”#

ISO certification เป็น signal ว่า process documented + audited

แต่ certificate ไม่ได้แปลว่าคุณภาพดี แปลว่าทำตาม procedure ที่ document ไว้ (ซึ่ง procedure อาจไม่ดีก็ได้)

ตัวอย่าง บริษัทที่ ISO 9001 certified แต่มี procedure ที่ “เขียน code โดยไม่ต้อง review” — ทำตาม procedure = comply ISO แต่ quality ของ code ก็ยังแย่อยู่ดี

→ Certificate ≠ quality auditor ตรวจ outcome ไม่ใช่แค่ certificate

Pattern คลาสสิคของวงการ#

ลอง scenario ที่เจอบ่อย — บริษัทบอกว่า “เรา improve ตลอด” พอถามว่า “ใครรับผิดชอบ improvement?” คำตอบคือ “ทุกคน”

ในทางปฏิบัติ “ทุกคน” รับผิดชอบ = ไม่มีใครรับผิดชอบครับ → improvement เกิดเป็น project ๆ ตอนมี crisis แล้วก็หยุด

Operational Excellence = ทำให้ improvement เป็น discipline ขององค์กร ไม่ใช่ project ๆ

องค์ประกอบ#

1. Dedicated team — ทีม OE ที่มีหน้าที่หลัก find + eliminate waste
2. Continuous improvement culture — ทุกคน contribute ปัญหา + idea
3. Data-driven decision — improvement based on metric ไม่ใช่ opinion
4. Cross-team collaboration — ปัญหามักอยู่ที่ interface ระหว่างทีม
5. Root cause analysis — แก้ที่ root ไม่ใช่ symptom

ROI ของ OE Team#

CRM ระบุว่า OE team ที่ดีมัก save cost ได้มากกว่าค่าจ้างทีม เพราะค้นพบ waste ที่ซ่อนอยู่

ตัวอย่าง waste ที่ OE team หา:

• Redundant process — ทำซ้ำใน 2 system ที่ไม่ sync กัน
• Manual workaround — process ที่ automate ได้แต่ยังทำมือ
• Unused capacity — server ที่ run ที่ 5% utilization
• Approval chain ที่ยาวเกินจำเป็น