- 4
- เมษายน
SLA คืออะไร — ข้อตกลงระดับบริการที่ต้องกำหนดก่อนเซ็นสัญญา ERP
SLA (Service Level Agreement) หรือ ข้อตกลงระดับบริการ คือเอกสารที่กำหนดมาตรฐานการให้บริการระหว่างผู้ให้บริการ ERP กับองค์กรผู้ใช้งาน ครอบคลุมตั้งแต่ความพร้อมใช้งานของระบบ (Uptime) เวลาตอบสนอง (Response Time) เวลาแก้ไขปัญหา (Resolution Time) ไปจนถึงบทลงโทษเมื่อไม่เป็นไปตามข้อตกลง บทความนี้จะอธิบายทุกมิติของ SLA ที่ผู้บริหารต้องรู้ก่อนเซ็นสัญญา ERP
สรุปสั้น: SLA คือ "สัญญาย่อย" ในสัญญา ERP ที่กำหนดว่า Vendor ต้องให้บริการระดับไหน ถ้าทำไม่ได้จะเกิดอะไรขึ้น
องค์กรที่ไม่มี SLA ชัดเจน = ไม่มีอำนาจต่อรองเมื่อระบบล่ม
ทำไม SLA ถึงสำคัญสำหรับโปรเจกต์ ERP?
ระบบ ERP เป็นหัวใจของการดำเนินธุรกิจ หากระบบล่มแม้เพียง 1 ชั่วโมง อาจหมายถึงการสูญเสียรายได้ ความล่าช้าในการปิดบัญชี หรือการจัดซื้อหยุดชะงัก SLA จึงเป็นเครื่องมือที่ช่วยให้:
- ลดความเสี่ยง — กำหนดมาตรฐานขั้นต่ำที่ Vendor ต้องทำได้ ไม่ปล่อยให้เป็นดุลยพินิจ
- สร้างความรับผิดชอบ (Accountability) — Vendor มีตัวเลขที่ต้องรักษา มีบทลงโทษเมื่อทำไม่ได้
- วางแผนธุรกิจได้ — รู้ว่าระบบจะพร้อมใช้งานเท่าไร สามารถวางแผน การบริหารความเสี่ยง ได้ชัดเจน
- เปรียบเทียบ Vendor — ใช้ SLA เป็นเกณฑ์เปรียบเทียบข้อเสนอจาก Vendor หลายราย
- ปกป้องงบประมาณ — มีกลไก Penalty/Credit เมื่อบริการต่ำกว่ามาตรฐาน
5 ตัวชี้วัด SLA ที่ต้องระบุในสัญญา ERP
| # | ตัวชี้วัด | คำอธิบาย | ค่ามาตรฐาน |
|---|---|---|---|
| 1 | Uptime / Availability | เปอร์เซ็นต์เวลาที่ระบบพร้อมใช้งาน (ไม่รวม Planned Maintenance) | 99.5% - 99.99% |
| 2 | Response Time | เวลาตั้งแต่แจ้งปัญหาจนถึง Vendor ตอบรับ (Acknowledge) | 15 นาที - 4 ชั่วโมง |
| 3 | Resolution Time | เวลาตั้งแต่แจ้งปัญหาจนถึงแก้ไขเสร็จสมบูรณ์ | 1 ชั่วโมง - 5 วันทำการ |
| 4 | Data Backup & Recovery (RPO/RTO) | RPO = ข้อมูลสูญหายได้สูงสุดกี่ชั่วโมง, RTO = กู้คืนระบบภายในกี่ชั่วโมง | RPO ≤ 1 ชม., RTO ≤ 4 ชม. |
| 5 | Patch & Security Update | ระยะเวลาในการอัปเดตแพตช์ความปลอดภัย | Critical: 24 ชม., Normal: 7 วัน |
Uptime เปรียบเทียบ: ต่างกัน 0.4% แต่ผลต่างมหาศาล
| Uptime | Downtime ต่อเดือน | Downtime ต่อปี | เหมาะกับ |
|---|---|---|---|
| 99.5% | ~3.6 ชั่วโมง | ~43.8 ชั่วโมง | องค์กรทั่วไป ทำงานวันจันทร์-ศุกร์ |
| 99.9% | ~43 นาที | ~8.7 ชั่วโมง | องค์กรที่ต้องการความต่อเนื่องสูง |
| 99.99% | ~4.3 นาที | ~52 นาที | ระบบ Mission-critical, การเงิน |
อ่านเพิ่มเติมเกี่ยวกับ Disaster Recovery สำหรับระบบ ERP เพื่อเข้าใจแนวทางการกู้คืนระบบเมื่อเกิดเหตุฉุกเฉิน
SLA ตามระดับความรุนแรง (Priority Tiers)
SLA ที่ดีต้องแบ่งระดับความรุนแรงของปัญหาเป็นชั้นๆ เพราะไม่ใช่ทุกปัญหาจะต้องได้รับการแก้ไขภายในเวลาเท่ากัน:
| ระดับ | คำอธิบาย | ตัวอย่าง | Response Time | Resolution Time |
|---|---|---|---|---|
| P1 - Critical | ระบบใช้งานไม่ได้ทั้งหมด มีผลกระทบต่อธุรกิจวงกว้าง | ระบบ ERP ล่มทั้งหมด, ฐานข้อมูลเสียหาย | ≤ 15 นาที | ≤ 4 ชั่วโมง |
| P2 - High | ฟังก์ชันหลักใช้งานไม่ได้ แต่ระบบอื่นยังทำงาน | โมดูลบัญชีล่ม, ออกใบแจ้งหนี้ไม่ได้ | ≤ 30 นาที | ≤ 8 ชั่วโมง |
| P3 - Medium | ฟังก์ชันรองมีปัญหา มี Workaround ได้ | รายงานแสดงผลผิด, พิมพ์เอกสารไม่ได้ | ≤ 2 ชั่วโมง | ≤ 2 วันทำการ |
| P4 - Low | ปัญหาเล็กน้อย ไม่กระทบการทำงานหลัก | ข้อความแสดงผิด, UI ไม่สวย, คำขอปรับปรุง | ≤ 4 ชั่วโมง | ≤ 5 วันทำการ |
Penalty & Escalation: ข้อกำหนดบทลงโทษและการยกระดับ
SLA ที่ไม่มี Penalty ก็เหมือนกฎหมายที่ไม่มีบทลงโทษ — ไม่มีผลบังคับใช้จริง สิ่งที่ต้องระบุในสัญญา:
- Service Credit: เมื่อ Uptime ต่ำกว่าที่กำหนด เช่น Uptime < 99.5% = ได้ Credit 10% ของค่าบริการเดือนนั้น, < 99.0% = Credit 25%, < 98.0% = Credit 50%
- ค่าปรับรายวัน: เมื่อ Resolution Time เกินกำหนด เช่น ปรับ 0.1% ของมูลค่าสัญญาต่อวันที่ล่าช้า (สูงสุดไม่เกิน 10%)
- สิทธิ์ยกเลิกสัญญา: หาก SLA ไม่ผ่านเกณฑ์ติดต่อกัน 3 เดือน ผู้ว่าจ้างมีสิทธิ์ยกเลิกสัญญาโดยไม่เสียค่าปรับ
- Escalation Path: กำหนดชัดเจนว่า ถ้าปัญหาไม่ได้รับการแก้ไขตามเวลา จะยกระดับไปหาใคร (เช่น P1 เกิน 2 ชม. → แจ้ง VP of Engineering)
ตัวอย่าง Escalation Matrix
| เวลาที่ผ่านไป | ยกระดับไปยัง |
| 0 - 1 ชั่วโมง | ทีม Support L1 (Help Desk) |
| 1 - 2 ชั่วโมง | ทีม Support L2 (Senior Engineer) |
| 2 - 4 ชั่วโมง | ผู้จัดการฝ่าย Support + แจ้ง PM ของลูกค้า |
| > 4 ชั่วโมง | ผู้บริหารระดับสูงทั้งสองฝ่าย |
SLA สำหรับภาครัฐ: สิ่งที่ TOR ต้องระบุ
สำหรับหน่วยงานภาครัฐที่จัดซื้อระบบ ERP ตาม ข้อกำหนดการจัดทำ TOR ควรกำหนด SLA ในเอกสาร TOR อย่างชัดเจน โดยเฉพาะ:
- Uptime ขั้นต่ำ — ระบุเป็นตัวเลขเปอร์เซ็นต์ชัดเจน (เช่น ไม่ต่ำกว่า 99.5% ในช่วงเวลาราชการ)
- ระยะเวลาแก้ไขปัญหา — แยกตาม Priority Level ตามตารางข้างต้น
- ระยะเวลารับประกัน — ตาม พ.ร.บ.การจัดซื้อจัดจ้างและการบริหารพัสดุภาครัฐ พ.ศ. 2560 กำหนดไม่น้อยกว่า 1 ปี
- การสำรองข้อมูล — ต้องระบุ RPO/RTO และจำนวนสำเนาสำรอง (อย่างน้อย 2 สำเนา แยกสถานที่)
- รายงาน SLA — Vendor ต้องส่งรายงานผลการให้บริการเทียบกับ SLA ทุกเดือน
- ค่าปรับ — ระบุอัตราค่าปรับตามระเบียบกระทรวงการคลังว่าด้วยการจัดซื้อจัดจ้างฯ
Checklist 10 ข้อที่ต้องมีใน SLA ก่อนเซ็นสัญญา ERP
- Uptime Guarantee — ระบุเปอร์เซ็นต์ Uptime ขั้นต่ำ พร้อมวิธีวัดและเครื่องมือ Monitoring
- Priority Classification — แบ่งระดับปัญหา P1-P4 พร้อมคำนิยามชัดเจน
- Response & Resolution Time — ระบุเวลาตอบรับและเวลาแก้ไขแยกตาม Priority
- Service Hours — ระบุชั่วโมงบริการ (8x5, 12x6, 24x7) และเงื่อนไข On-call นอกเวลา
- Backup & Recovery (RPO/RTO) — ระบุความถี่สำรองข้อมูล ระยะเวลากู้คืน และขั้นตอนทดสอบ DR
- Patch & Security Update — กำหนดระยะเวลาอัปเดต Critical Patch และตารางอัปเดตปกติ
- Penalty & Service Credit — ระบุค่าปรับหรือ Credit เมื่อ SLA ไม่ผ่านเกณฑ์
- Escalation Procedure — ระบุ Escalation Matrix พร้อมชื่อและช่องทางติดต่อ
- Monthly SLA Report — Vendor ต้องส่งรายงาน SLA ทุกเดือน พร้อมสถิติ Uptime, Ticket, Resolution Time
- Review & Renewal — กำหนดรอบทบทวน SLA (เช่น ทุก 12 เดือน) และเงื่อนไขการปรับปรุง
ข้อผิดพลาดที่พบบ่อยใน SLA (Common Pitfalls)
| ข้อผิดพลาด | ปัญหาที่เกิด | วิธีป้องกัน |
|---|---|---|
| ภาษาคลุมเครือ | "จะแก้ไขโดยเร็ว" ไม่มีตัวเลข ตีความต่างกันได้ | ระบุเป็นชั่วโมง/วันทำการชัดเจน |
| ไม่มี Penalty | Vendor ไม่มีแรงจูงใจในการรักษามาตรฐาน | กำหนด Service Credit / ค่าปรับเป็นลายลักษณ์อักษร |
| ไม่ระบุวิธีวัด | เถียงกันว่า Uptime 99.5% วัดอย่างไร นับ Planned Maintenance หรือไม่ | ระบุเครื่องมือ Monitoring และสูตรคำนวณ |
| ไม่แยก Priority | ปัญหาเล็ก-ใหญ่ใช้เวลาแก้ไขเท่ากัน ทรัพยากรไม่เพียงพอ | แบ่ง P1-P4 พร้อมเงื่อนไขที่ชัดเจน |
| ไม่กำหนด Exclusion | Vendor อ้าง Force Majeure ทุกครั้ง | ระบุ Exclusion ที่ยอมรับได้ และขอบเขตที่ชัดเจน |
วิธีติดตามและตรวจสอบผล SLA
SLA จะมีคุณค่าก็ต่อเมื่อมีการติดตามผลอย่างสม่ำเสมอ แนวทางที่แนะนำ:
- ใช้ Monitoring Tool — ติดตั้งระบบ Uptime Monitoring (เช่น Zabbix, Nagios, UptimeRobot) เพื่อวัด Uptime อัตโนมัติ
- ระบบ Ticket — ใช้ระบบ Ticket (เช่น Helpdesk, ITSM) เพื่อบันทึกเวลาแจ้งปัญหา ตอบรับ และแก้ไขเสร็จ
- รายงาน SLA รายเดือน — กำหนดให้ Vendor ส่งรายงานทุกเดือน เปรียบเทียบกับเป้า SLA
- ประชุมทบทวนรายไตรมาส — ประชุม SLA Review ทุก 3 เดือน เพื่อหารือปัญหาและปรับปรุง
- Dashboard สำหรับผู้บริหาร — สรุป SLA เป็น Dashboard ที่ผู้บริหารเห็นได้ทันที
การมี แผน Disaster Recovery ที่ดีจะช่วยให้องค์กรบรรลุเป้าหมาย RPO/RTO ที่กำหนดไว้ใน SLA ได้อย่างมั่นใจ
สรุป
SLA ไม่ใช่แค่เอกสารแนบท้ายสัญญา แต่เป็น เครื่องมือบริหารความเสี่ยงที่สำคัญที่สุด ในโปรเจกต์ ERP ผู้บริหารต้องให้ความสำคัญกับ SLA ตั้งแต่ขั้นตอนการคัดเลือก Vendor — กำหนดตัวชี้วัดชัดเจน แบ่ง Priority เป็นชั้นๆ มี Penalty ที่บังคับใช้จริง และติดตามผลอย่างสม่ำเสมอ องค์กรที่มี SLA ที่ดี จะมั่นใจได้ว่าระบบ ERP จะทำงานได้ตามมาตรฐานที่คาดหวัง
"SLA ที่ดีไม่ใช่เอกสารที่ต้องหยิบมาดูเมื่อมีปัญหา แต่เป็นมาตรฐานที่ทั้งสองฝ่ายรักษาร่วมกันทุกวัน"
บทความที่เกี่ยวข้องจากศูนย์ความรู้
- ROI ของระบบ ERP — วัดผลอย่างไรให้ชัดเจน ผู้บริหาร
- Checklist เตรียมตัวก่อนเริ่มโปรเจกต์ ERP ทีม Implement
- พื้นฐานความปลอดภัยระบบ ERP ที่ผู้ใช้งานต้องรู้ ผู้ใช้งาน
