Khi thuê phần mềm doanh nghiệp, SLA là thỏa thuận xác định mức dịch vụ nhà cung cấp cam kết, cách đo và trách nhiệm khi không đáp ứng. Để đánh giá SLA, hãy kiểm tra cả phạm vi bảo đảm, thời gian hỗ trợ và cơ chế khắc phục, thay vì chỉ nhìn vào tỷ lệ uptime.
Theo bài giải thích về SLA của Vietnix, thỏa thuận này thường bao gồm chỉ tiêu hiệu suất, giám sát, quy trình xử lý sự cố và hậu quả khi vi phạm. Với người mua phần mềm, điều quan trọng là chuyển các cam kết đó thành câu hỏi có thể kiểm chứng.
1. Xác định phần nào được bảo đảm
Một nền tảng vẫn có thể truy cập được nhưng chức năng quan trọng lại không hoạt động. Vì vậy, hãy hỏi SLA áp dụng cho toàn bộ dịch vụ hay chỉ một số thành phần.
Chẳng hạn, nếu triển khai CRM để quản lý khách hàng và bán hàng, doanh nghiệp nên kiểm tra việc tạo khách hàng, cập nhật cơ hội và đồng bộ dữ liệu có nằm trong phạm vi cam kết không.
Ghi rõ những quy trình không thể gián đoạn trước khi so sánh nhà cung cấp. Một mức uptime cao chưa chắc phù hợp nếu chức năng thiết yếu bị loại trừ.
2. Phân biệt các loại thời gian
“Phản hồi nhanh” không đồng nghĩa với “khắc phục nhanh”. Khi đọc hợp đồng, cần tách biệt:
Chỉ tiêu | Ý nghĩa cần làm rõ |
|---|---|
Thời gian phản hồi | Bao lâu trước khi nhân sự hỗ trợ tiếp nhận và trả lời? |
Thời gian khôi phục | Bao lâu trước khi dịch vụ hoạt động trở lại, kể cả bằng giải pháp tạm thời? |
Thời gian giải quyết | Bao lâu trước khi nguyên nhân sự cố được xử lý? |
Tần suất cập nhật | Trong lúc chờ, khách hàng được thông báo tiến độ thế nào? |
Kiểm tra thêm hỗ trợ có hoạt động ngoài giờ hay không. Đồng hồ tính thời gian có bắt đầu khi gửi yêu cầu, khi yêu cầu được xác nhận, hay chỉ trong giờ làm việc?
3. Đọc cách tính uptime và ngoại lệ
Uptime là tỷ lệ thời gian dịch vụ sẵn sàng trong kỳ đo. Ví dụ minh họa, nếu tính trên toàn bộ tháng 30 ngày và không loại trừ thời gian nào, uptime 99,9% tương ứng khoảng 43,2 phút không sẵn sàng.
Tuy nhiên, hợp đồng có thể quy định cách tính khác. Hãy kiểm tra:
Kỳ đo là tháng hay năm?
Bảo trì theo lịch có bị loại khỏi phép tính không?
Mất kết nối từ phía khách hàng được xác định thế nào?
Công cụ nào ghi nhận sự cố, và khách hàng có được xem báo cáo không?
Với ERP kết nối quy trình giữa các bộ phận, thời điểm gián đoạn cũng đáng cân nhắc: sự cố vào lúc chốt đơn hoặc xử lý kho có thể gây ảnh hưởng lớn hơn ngoài giờ.
4. Kiểm tra quyền lợi khi vi phạm
Đừng mặc định vi phạm SLA sẽ được hoàn tiền. Biện pháp khắc phục có thể là tín dụng dịch vụ, tức khoản bù trừ cho phí sử dụng, tùy hợp đồng.
Cần đọc điều kiện yêu cầu bù trừ, hạn gửi yêu cầu, bằng chứng cần nộp và mức tối đa. Đồng thời kiểm tra quyền chấm dứt hợp đồng nếu vi phạm lặp lại. Khoản bù trừ phí không nhất thiết bù đắp thiệt hại kinh doanh.
5. Chốt quy trình xử lý trước khi ký
Thống nhất đầu mối liên hệ, cấp độ nghiêm trọng và đường chuyển cấp khi sự cố chưa được xử lý. Nội bộ doanh nghiệp cũng cần người ghi nhận ảnh hưởng và lưu thời điểm phát sinh.
Nếu còn cân nhắc giữa ERP và CRM, hãy xác định hệ thống phục vụ quy trình nào trước. Yêu cầu SLA nên xuất phát từ mức độ phụ thuộc thực tế, không từ một mẫu hợp đồng chung.
Kết luận
SLA hữu ích phải trả lời được ba câu hỏi: điều gì được bảo đảm, đo bằng cách nào và xử lý ra sao khi vi phạm. Làm rõ những điểm này trước khi ký giúp doanh nghiệp đánh giá cam kết dịch vụ sát với nhu cầu vận hành.
Câu hỏi thường gặp
SLA có giống KPI không?
Không. KPI là chỉ số đánh giá hiệu quả hoạt động, còn SLA là thỏa thuận về mức dịch vụ và trách nhiệm của các bên. Một chỉ số có thể được dùng trong cả hai, nhưng việc đưa vào SLA cần kèm cách đo, phạm vi áp dụng và điều kiện xử lý khi không đạt.
Uptime 99,9% có đủ cho mọi doanh nghiệp không?
Không có mức phù hợp cho tất cả. Cần xét tác động của gián đoạn, thời điểm sử dụng, khả năng làm việc tạm thời và chi phí của mức cam kết cao hơn. Đồng thời phải kiểm tra các ngoại lệ trong cách tính uptime.
Nếu nhà cung cấp không cam kết thời gian giải quyết thì nên hỏi gì?
Hãy hỏi về mục tiêu khôi phục dịch vụ, phương án tạm thời, tần suất cập nhật và cơ chế chuyển cấp. Những điều này giúp doanh nghiệp có kế hoạch ứng phó ngay cả khi chưa thể xác định thời điểm sửa lỗi hoàn toàn.