ลองนึกภาพตามสถานการณ์นี้: พนักงานฝ่ายบัญชีโทรมาแจ้งว่าระบบ ERP ไม่สามารถเปิดได้ในช่วงสิ้นเดือน ทีม IT รับแจ้งแล้ว แต่ไม่มีใครรู้ว่าต้องแก้ไขภายใน "กี่ชั่วโมง" และไม่มีใครแจ้งเตือนหัวหน้าเมื่อเวลาผ่านไปนานเกินไป ผลลัพธ์คือปิดงบไม่ทันกำหนด ผู้บริหารโกรธ และความเชื่อมั่นต่อทีม IT หายไปพร้อมกัน
ปัญหานี้เกิดขึ้นในหลายองค์กรไทย โดยเฉพาะ SME ที่ยังไม่มีการกำหนด SLA (Service Level Agreement) อย่างเป็นทางการ บทความนี้จะพาคุณทำความเข้าใจ SLA ตั้งแต่พื้นฐาน พร้อมแนะนำวิธีตั้ง Priority × Impact Matrix ที่ใช้ได้จริงในองค์กรขนาดกลาง
SLA คืออะไร?
SLA (Service Level Agreement) หรือ ข้อตกลงระดับการให้บริการ คือการกำหนดเป้าหมายอย่างชัดเจนว่า ทีม IT ต้องตอบสนองและแก้ไขปัญหาภายในระยะเวลาเท่าใด โดยปกติแบ่งออกเป็น 2 ส่วนหลัก:
- Response SLA — เวลาที่ทีม IT ต้องรับทราบ Ticket และเริ่มดำเนินการ (เช่น ตอบกลับภายใน 1 ชั่วโมง)
- Resolution SLA — เวลาที่ต้องแก้ไขปัญหาให้เสร็จสิ้น (เช่น ปิด Ticket ภายใน 8 ชั่วโมง)
สูตรที่นิยมใช้คือ Response SLA = Resolution SLA ÷ 4 ซึ่งหมายความว่าถ้าต้องแก้ปัญหาภายใน 8 ชั่วโมง ทีมต้องตอบรับและเริ่มลงมือภายใน 2 ชั่วโมง
ทำไม SLA ถึงสำคัญ? SLA ไม่ใช่แค่ตัวเลขสวยงาม แต่คือสัญญาที่ทีม IT มีต่อธุรกิจ เมื่อมี SLA ชัดเจน ทุกคนรู้ว่าต้องคาดหวังอะไร และทีม IT มีเป้าหมายที่วัดได้จริง
Priority คืออะไร?
Priority หรือ ระดับความเร่งด่วน คือการประเมินว่าปัญหานี้ "เร่งด่วนแค่ไหน" จากมุมมองของการดำเนินธุรกิจ มักแบ่งออกเป็น 4 ระดับ:
- Critical — ธุรกิจหยุดชะงักทันที ไม่มี Workaround (เช่น Server ล่ม, ระบบ Core ใช้ไม่ได้)
- High — กระทบงานหลักอย่างมาก มี Workaround บางส่วน (เช่น ระบบ ERP ช้ามาก, Email ส่งไม่ได้)
- Medium — กระทบงานแต่ยังทำได้ด้วยวิธีอื่น (เช่น Printer ไม่ทำงาน, VPN เชื่อมต่อไม่ได้)
- Low — ปัญหาเล็กน้อย ไม่รีบ (เช่น ขอติดตั้งโปรแกรมเพิ่ม, เปลี่ยนรหัสผ่าน)
Impact คืออะไร?
Impact หรือ ขนาดผลกระทบ คือการประเมินว่าปัญหานี้กระทบกับ "กี่คน" หรือ "กี่แผนก" ต่างจาก Priority ตรงที่ Impact วัดจากวงกว้างของปัญหา ไม่ใช่ความรีบเร่ง:
- Critical — กระทบทั้งองค์กรหรือลูกค้าภายนอก (ผู้ใช้งานมากกว่า 50 คน หรือทุกแผนก)
- High — กระทบหลายแผนกหรือกลุ่มงานสำคัญ (11–50 คน)
- Medium — กระทบแผนกเดียวหรือกลุ่มเล็ก (2–10 คน)
- Low — กระทบผู้ใช้คนเดียว (1 คน)
การแยก Priority กับ Impact ออกจากกันทำให้การจัดลำดับ Ticket มีความแม่นยำมากขึ้น เช่น ปัญหา Printer ของผู้บริหารอาจมี Priority สูง (เร่งด่วน) แต่ Impact ต่ำ (กระทบคนเดียว) ในขณะที่ระบบ Payroll ช้าอาจมี Priority Medium แต่ Impact Critical (กระทบพนักงานทั้งองค์กร)
Priority × Impact Matrix: หัวใจของ SLA IT Support
เมื่อนำ Priority และ Impact มาคูณกัน จะได้ SLA Matrix ที่บอกว่าแต่ละ Ticket ต้องแก้ภายในกี่ชั่วโมง ตารางด้านล่างนี้คือ Resolution SLA ที่แนะนำสำหรับ SME ไทย:
| Priority \ Impact | Low (1 คน) |
Medium (2–10 คน) |
High (11–50 คน) |
Critical (ทั้งองค์กร) |
|---|---|---|---|---|
| Low | 72 ชม. | 48 ชม. | 24 ชม. | 8 ชม. |
| Medium | 48 ชม. | 24 ชม. | 8 ชม. | 4 ชม. |
| High | 24 ชม. | 8 ชม. | 4 ชม. | 2 ชม. |
| Critical | 8 ชม. | 4 ชม. | 2 ชม. | 30 นาที |
* ตัวเลขด้านบนคือ Resolution SLA (เวลาแก้ไขเสร็จ) · Response SLA = Resolution ÷ 4
จะเห็นว่า Ticket ที่ Priority Critical และ Impact Critical เช่น Server หลักล่มทั้งบริษัท ต้องแก้ไขให้ได้ภายใน 30 นาที ซึ่งทีม IT ต้องระดมทรัพยากรทันที ในขณะที่ Ticket Priority Low / Impact Low เช่น ขอเพิ่มสิทธิ์ใช้งาน Folder สามารถรอได้ถึง 72 ชั่วโมง (3 วันทำการ)
SLA Breach คืออะไร และผลกระทบต่อองค์กร
SLA Breach หรือ การละเมิด SLA คือเหตุการณ์ที่ Ticket ไม่ได้รับการแก้ไขภายในเวลาที่กำหนด ผลกระทบไม่ได้จำกัดแค่ตัวเลขในรายงาน แต่กระทบต่อความเชื่อมั่นของผู้ใช้งาน ฝ่ายบริหาร และในกรณีของบริษัท Outsource IT Support อาจหมายถึงบทปรับตามสัญญา
ระบบ ITSM ที่ดีจะแจ้งเตือนล่วงหน้าเมื่อ Ticket ใช้เวลาไปแล้ว 80% ของ SLA (สถานะ "At Risk") เพื่อให้ทีมมีเวลาเร่งแก้ไขก่อนที่จะกลายเป็น Breach จริง
วิธีตั้ง SLA ที่เหมาะสมสำหรับ SME ไทย
หลายองค์กรกลัวว่าการตั้ง SLA จะซับซ้อนเหมือน ITIL เต็มรูปแบบ แต่ในความเป็นจริงสามารถเริ่มได้ง่ายๆ ดังนี้:
- เริ่มจาก Matrix มาตรฐาน — ใช้ตารางด้านบนเป็นจุดเริ่มต้น ไม่ต้องสร้างเองจากศูนย์
- ปรับให้เหมาะกับธุรกิจ — ถ้าบริษัทเปิดทำการ 24/7 ให้ใช้ Calendar Hours, ถ้าเปิดแค่วันทำการให้ใช้ Business Hours เช่น 08:00–18:00
- กำหนด Impact ตามจำนวนคน — ใช้ตัวเลขจริงขององค์กร เช่น บริษัท 100 คน: Low = 1, Medium = 2–10, High = 11–30, Critical = 31+
- สื่อสารให้ผู้ใช้งานเข้าใจ — เมื่อสร้าง Ticket แสดง SLA deadline ให้ผู้ใช้เห็นตั้งแต่ต้น จะลดการติดตามงานซ้ำซ้อน
- ทบทวนทุก Quarter — ดูว่า SLA ที่ตั้งไว้ทำได้จริงหรือไม่ ปรับตาม Capacity จริงของทีม
Escalation Rules: แจ้งเตือนก่อน Breach
กฎการ Escalate คือการตั้งค่าว่าเมื่อ Ticket ใกล้ Breach ให้ทำอะไรโดยอัตโนมัติ เช่น:
- ใช้เวลาไปแล้ว 80% → แจ้งเตือน Support ที่รับผิดชอบ Ticket นั้น
- ใช้เวลาไปแล้ว 100% (Breach) → แจ้ง Supervisor หรือ IT Manager ทาง Line OA หรืออีเมล
- Breach นาน +2 ชั่วโมง → แจ้ง Company Admin พร้อม Ticket ID และ Impact
Escalation ที่ดีทำให้ปัญหาไม่ "จม" อยู่ในระบบโดยไม่มีใครสนใจ และช่วยให้ผู้บริหารเห็นภาพรวมได้โดยไม่ต้องถามเอง
ตัวชี้วัด SLA ที่ IT Manager ควรติดตาม
นอกจากตัวเลข Breach Rate แล้ว ยังมีตัวชี้วัดสำคัญอีกหลายตัวที่ควรดูในรายงานรายเดือน:
- MTTR (Mean Time to Resolution) — เวลาเฉลี่ยในการแก้ไข Ticket คำนวณจากทุก Ticket ที่ปิดแล้วในช่วงเวลานั้น
- MTBF (Mean Time Between Failures) — เวลาเฉลี่ยระหว่างเหตุการณ์ที่เกิดซ้ำ ใช้ดูว่าปัญหาเดิมกลับมาบ่อยแค่ไหน
- Resolution Rate — สัดส่วน Ticket ที่ปิดได้ทันตาม SLA เช่น 92% ของ High-Priority Ticket แก้ได้ทันเวลา
- Reopen Rate — สัดส่วน Ticket ที่ถูกเปิดใหม่ภายใน 7 วันหลังปิด บ่งบอกว่าแก้ได้จริงหรือแค่ปิดชั่วคราว
- Satisfaction Score — คะแนนความพึงพอใจของผู้ใช้หลังปิด Ticket (1–5 ดาว)
สรุป: SLA ไม่ใช่ Overhead แต่คือ Foundation ของ IT ที่ดี
การตั้ง SLA ด้วย Priority × Impact Matrix ช่วยให้ทีม IT จัดลำดับความสำคัญได้ถูกต้อง ไม่ใช้เวลากับปัญหาเล็กน้อยในขณะที่ปัญหาใหญ่รอคิว และยังสร้างความโปร่งใสให้กับผู้ใช้งาน เพราะทุกคนรู้ว่าปัญหาของตัวเองจะได้รับการแก้ไขเมื่อใด
สำหรับองค์กรที่เพิ่งเริ่มต้น แนะนำให้ใช้ Matrix มาตรฐานก่อน แล้วค่อยๆ ปรับตามความเป็นจริงของทีม สิ่งสำคัญกว่าตัวเลขที่สมบูรณ์แบบคือ ความสม่ำเสมอในการปฏิบัติตาม SLA ที่ตั้งไว้
หากคุณกำลังมองหาระบบ ITSM ที่คำนวณ SLA อัตโนมัติจาก Priority × Impact พร้อม Escalation แจ้ง Line OA ก่อน Breach ลองดู 1StopService ทดลองฟรี 30 วัน ได้เลยโดยไม่ต้องผูกบัตรเครดิต