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

สมมติคุณเปิดร้านอาหาร และต้องเลือกตัวเลขมา 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 กำลังเพิ่มขึ้น

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

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 ตัว — แต่ละตัวตอบคำถามที่ผู้บริหารแต่ละระดับสนใจต่างกัน

PDCA คืออะไร#

PDCA = Plan → Do → Check → Act

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

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

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

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

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

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

ตัวอย่างที่ผมว่าเห็นภาพ — โรงงานที่เปลี่ยน 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 ครั้งเดียว

ปัญหาที่ 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

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 ไหน + ทำตามจริงมั้ย