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

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

มุมหนึ่ง: ข้อสอบปลายภาค — วัดผลลัพธ์ที่นักเรียนได้ → นี่คือ 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 แต่ไม่ใช่สิ่งเดียวกัน)

ทำไมต้องแยกในมุม 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 ที่เราคุยใน ตอน 16

วิธีแก้:

• 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 ที่เจอในบริษัทไทย#

หลายบริษัทบอกว่า “เรา 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 ที่ยาวเกินจำเป็น