ลองคิดถึงร้านอาหารก่อน#

สมมติเปิดร้านอาหาร แล้วต้องเลือกตัวเลขมา monitor ผ่าน dashboard:

• ยอดขายต่อเดือน — บอกว่ากำลังขายดีมั้ย → ใกล้กับ KPI
• จำนวนลูกค้าที่ร้องเรียนเรื่องอาหาร — สัญญาณว่าคุณภาพอาจตก → ใกล้กับ KRI
• % รายการอาหารที่ทำตาม recipe มาตรฐาน — บอกว่า process ทำงานจริงรึเปล่า → ใกล้กับ KGI

ทั้ง 3 ตัววัดร้านเดียวกันแต่บอกคนละเรื่องเลย ขาด 1 ตัวคือมองภาพร้านไม่ครบ

ลองมาดูทีละตัวในบริบท IT:

KPI — Key Performance Indicator#

KPI = สัญญาณนำหน้าว่า “เป้าหมาย strategic จะบรรลุมั้ย”

ลักษณะสำคัญ: leading indicator — ดูแล้วบอก future direction (ไม่ใช่ lagging ที่บอก past)

ตัวอย่างใน IT:

• % uptime ของระบบหลัก (เป้า 99.9%)
• Average response time ของระบบ
• จำนวน change request ที่ deploy สำเร็จในไตรมาส
• Customer satisfaction score ของ IT service

Trap: confuse KPI กับ activity metric — “จำนวน tickets ที่ปิด” ไม่ใช่ KPI ที่ดีนะครับ เพราะวัด activity ไม่ใช่ outcome (ปิด ticket เยอะไม่ได้แปลว่าลูกค้า happy)

KPI ที่ดีตอบคำถามว่า “เรากำลังจะบรรลุเป้าหมายมั้ย” ไม่ใช่ “เราทำอะไรไปบ้าง”

KRI — Key Risk Indicator#

KRI = สัญญาณ เตือนล่วงหน้า ว่า risk กำลังเพิ่มขึ้น

ลองนึกถึงเข็มน้ำมันรถ — บอกว่าน้ำมันใกล้หมดก่อนที่รถจะดับ ถ้าไม่มีเข็มน้ำมัน → รู้ตัวอีกทีรถดับกลางทาง 555+

KRI ทำหน้าที่เดียวกันกับ risk:

ตัวอย่าง:

• จำนวน phishing attempt ที่จับได้ในเดือน — เพิ่มขึ้น = signal threat landscape เปลี่ยน
• จำนวน failed login attempt ของ admin account — เพิ่มขึ้น = signal brute force attack
• % ของ asset ที่ patching เกินกำหนด — เพิ่มขึ้น = signal vulnerability เพิ่ม
• Number of policy exceptions granted — เพิ่มขึ้น = governance erosion

ความต่าง KPI vs KRI:

• KPI ตอบ: “เรากำลังจะบรรลุเป้ามั้ย” (ผลทางบวก)
• KRI ตอบ: “risk กำลังเพิ่มขึ้นมั้ย” (สัญญาณเตือน)

dashboard ที่มีแต่ KPI = บริษัทเห็นว่า “ทุกอย่าง green” แต่อาจกำลังเดินเข้า risk ที่ใหญ่ขึ้นโดยไม่รู้ตัว

KGI — Key Goal Indicator#

KGI = วัดว่า control ทำงานจริงรึเปล่า

ลองนึกถึงเข็มขัดนิรภัยในรถ — เราติดเข็มขัดนิรภัย (control) แต่ KGI คือ ”% ของอุบัติเหตุที่จบโดยไม่มีคนตาย” วัดว่า control นั้นลด impact ได้จริงมั้ย

ตัวอย่างใน IT:

• % ของ asset ที่ comply กับ security policy
• จำนวน security incident ที่ถูก contain ภายใน RTO
• % ของ change ที่ tested ก่อน deploy
• Mean time to recovery (MTTR) หลัง incident

ความต่าง KPI vs KGI:

• KPI วัด achievement ของ goal (“99% uptime achieved”)
• KGI วัด effectiveness ของ control (“100% of changes were tested before deploy”)

KGI ปิดวงระหว่าง “เรา implement control ครบมั้ย” กับ “control ที่ implement ไป ทำงานจริงมั้ย”

สรุป 3 ตัว#

dashboard ที่ดี = มีทั้ง 3 ตัวครับ แต่ละตัวตอบคำถามที่ผู้บริหารแต่ละระดับสนใจต่างกัน

Critical Success Factors (CSF) — ที่ Indicator วัดถึง#

ก่อนตั้ง KPI/KRI/KGI ต้องระบุ Critical Success Factors ก่อนครับ

CSF = สิ่งสำคัญที่ “ต้องสำเร็จ” เพื่อให้ business goal บรรลุ ไม่ใช่ทุกอย่างเป็น CSF

ตัวอย่าง: บริษัท e-commerce ที่ goal = “เพิ่ม revenue 20%”

• CSF 1: Customer satisfaction ระดับสูง (รักษาลูกค้าเก่า + ดึงลูกค้าใหม่)
• CSF 2: Order fulfillment time ภายใน 24 ชั่วโมง
• CSF 3: Website uptime 99.9%
• ไม่ใช่ CSF: สีของ logo, จำนวน social media post, การจัด office party

CSF จากนั้นถูก measure ผ่าน:

• KPI สำหรับวัด goal achievement
• KRI สำหรับ early warning
• KGI สำหรับ control effectiveness

Trap: บริษัทที่ตั้ง KPI โดยไม่ define CSF ก่อน → KPI วัดสิ่งที่วัดได้ ไม่ใช่สิ่งที่สำคัญ

PDCA คืออะไร#

PDCA = Plan → Do → Check → Act

วงจรปรับปรุงที่ออกแบบโดย Dr. W. Edwards Deming ใช้ใน manufacturing ก่อน แล้วแพร่เข้า IT operations

Plan — วางแผน: ระบุปัญหา, วิเคราะห์สาเหตุ, ออกแบบแก้ไข, ตั้งเป้าหมาย

Do — ลงมือ: implement แผนใน scope เล็กๆ ก่อน (pilot)

Check — ตรวจ: วัดผล, เทียบกับเป้า, เรียนรู้

Act — ปรับปรุง: ถ้าได้ผล standardize + scale up — ถ้าไม่ได้ผล กลับไป Plan ใหม่

ทำไมต้องเป็นวงจร#

ลองนึก scenario — โรงงานที่เปลี่ยน supplier วัตถุดิบเพราะต้นทุนถูกกว่า (Plan + Do)

ถ้าหยุดที่ Do ต้นทุนต่อชิ้นถูกลงจริง แต่:

• คุณภาพต่ำกว่าเดิม → ลูกค้าร้องเรียน
• เครื่องจักรพังบ่อยขึ้นเพราะ tolerance วัตถุดิบไม่ตรง

ถ้าทำ Check + Act — เห็นปัญหาก่อนใหญ่ → กลับไป Plan: ใช้ supplier เก่ากับ critical part / supplier ใหม่กับ non-critical

PDCA ที่ขาด Check + Act = แก้ปัญหาที่หนึ่ง แต่สร้างปัญหาที่สองตามมา

Trap: PDCA ที่ทำเป็น “Project”#

หลายบริษัท “ทำ PDCA” เป็น project — เริ่ม–จบ แล้วประกาศว่า “เราทำ PDCA เสร็จแล้ว”

ผิดครับ PDCA คือ culture ไม่ใช่ project ระบบที่ดีคือทุก process มี PDCA ที่ทำต่อเนื่อง ไม่ใช่ event ครั้งเดียว

Six Sigma — Methodology สำหรับ Process Quality#

Six Sigma = methodology ที่เน้น reducing defects + improving consistency ในกระบวนการ

หลักการ:

• เป้าหมาย = 3.4 defects per million opportunities (DPMO) — เกือบ perfect
• ใช้ DMAIC framework: Define → Measure → Analyze → Improve → Control
• Data-driven decision making
• บทบาท: Black Belts (project leads), Green Belts (team members), Master Black Belts (strategic)

ใน IT context:

• ลด defect ใน software development
• Improve incident response time consistency
• Reduce variance ของ system uptime

Trap: Six Sigma ไม่เหมาะกับ context ที่ต้องการ creativity / innovation เพราะมัน focus reducing variance startup ที่ใช้ Six Sigma แทน Lean = อาจ kill agility ได้

ในมุม auditor Six Sigma certification ของบริษัท = signal ของ mature process management แต่ ไม่ guarantee outcome auditor ดู actual results มากกว่า certification

ปัญหาที่ BSC มาแก้#

board ส่วนใหญ่เห็น IT ผ่าน financial lens อย่างเดียว — IT cost vs budget แต่ IT มี dimension อื่นที่สำคัญพอๆ กันที่ financial metric วัดไม่ได้

Balanced Scorecard ออกแบบโดย Kaplan + Norton มาขยายภาพให้ครบ ในบริบท IT ใช้ 4 perspective:

4 มุมของ IT BSC#

ทำไมเรียก “Balanced”#

เพราะถ้าวัดมุมเดียว มักได้ผลที่เสีย dimension อื่นไปเลย

ตัวอย่าง:

• ถ้าวัด financial อย่างเดียว IT department อาจ cut cost จนระบบช้า → user unhappy → business contribution ลด
• ถ้าวัด operational excellence อย่างเดียว IT ปรับ uptime สูงสุด แต่ไม่ลงทุนใน new tech → future orientation ต่ำ → ปีหน้า outdated

BSC ทำให้ตัดสินใจอย่างสมดุล ไม่ optimize มุมเดียวจนเสียมุมอื่น

Trap: BSC ที่ใช้เพื่อ Accountability ส่วนตัว#

CRM ระบุชัดเลยว่า BSC ไม่ใช่ เครื่องมือสำหรับ assigning accountability ของแต่ละบุคคล หรือ compliance reporting

มันคือ strategic management tool ที่ใช้ดูภาพ IT ในมุมของ board

ถ้าเอา BSC มาใช้ประเมิน performance ของ CIO เป็นรายตัว → BSC จะกลายเป็น dysfunctional เลยครับ เพราะ CIO จะเล่น metric แทนที่จะ improve outcome

IT Portfolio Management vs Balanced Scorecard#

คู่นี้ exam ออกถามให้แยกครับ:

ทั้งคู่ใช้ใน governance แต่ตอบคำถามคนละข้อ:

• Portfolio Management ตอบ “เราลงทุนถูกที่ไหม”
• Balanced Scorecard ตอบ “IT ของเราสมดุลทุกมิติมั้ย”

Trap: บริษัทที่ใช้ BSC แทน Portfolio Management → ตอบไม่ได้ว่า “ทำไมเลือก project A ไม่ใช่ project B” / ใช้ Portfolio แทน BSC → ไม่เห็น user satisfaction หรือ future readiness

COBIT#

COBIT (จาก ISACA) = framework สำหรับ governance + management ของ IT

• ครอบคลุม: governance objectives + management practices
• Goal cascade: enterprise goals → IT goals → IT processes → IT activities
• Maturity model: ประเมินว่า process อยู่ระดับใด (initial → optimizing)

ใน CISA exam COBIT คือ framework ที่ ISACA “บ้าน” ออกข้อสอบเรื่อง COBIT บ่อยครับ

Trap: confuse COBIT กับ ISACA Standards ที่เราเรียนใน ตอน 01

• COBIT = doer’s framework (สำหรับ organization ที่บริหาร IT)
• ISACA Standards = auditor’s framework (สำหรับ IS auditor ที่ตรวจ IT)

IS auditor follow ISACA Standards ในการตรวจ ไม่ใช่ COBIT (แต่อาจตรวจ organization ที่ใช้ COBIT)

ITIL#

ITIL (Information Technology Infrastructure Library) = best practice สำหรับ IT Service Management

• ครอบคลุม: incident, problem, change, configuration, capacity, availability, service continuity
• ใช้แพร่หลายในองค์กรใหญ่ที่ run IT operations เป็น service

Domain 4 จะลงรายละเอียด ITIL processes (incident, problem, change) — ตอนนี้รู้แค่ว่า ITIL = service management ก็พอครับ

ISO 27001 / ISO 31000#

• ISO 27001 = Information Security Management System (ISMS)
• ISO 31000 = Risk Management Guidelines

แต่ละ framework เน้น dimension ต่างกัน IS auditor ดูว่า organization ใช้ framework ไหน + ทำตามจริงมั้ย