Thiết lập hệ thống đo lường hiệu quả dịch vụ: SLA, Availability, MTTR và trải nghiệm người dùng.

Chọn đơn vị dịch vụ và câu hỏi trước khi chọn chỉ số

Xác định dịch vụ, chức năng, nhóm người dùng và thời điểm quan sát. Độ sẵn sàng của máy chủ khác khả năng thực hiện một giao dịch. Thời gian phục hồi của một sự cố khác thời gian hoàn tất một yêu cầu cấp mới. Nếu dùng chung một số trung bình cho các loại công việc, người đọc khó chọn hành động phù hợp.

Một từ điển chỉ số cần mục đích, công thức, nguồn, tập dữ liệu, lịch đo, điều kiện loại trừ và người sở hữu. Nêu rõ dữ liệu theo hồ sơ tạo trong kỳ, kết thúc trong kỳ hay sự kiện xảy ra trong kỳ. Hai báo cáo cùng tên nhưng khác tập quan sát có thể khác số mà không có bên nào tính sai.

Khi định nghĩa đổi, lưu phiên bản và mốc. Nếu có thể tính lại dữ liệu cũ thì làm theo cùng cơ sở; nếu không, đánh dấu phần không so sánh trực tiếp. Không nên nối biểu đồ liền mạch rồi coi thay đổi do công thức là thay đổi chất lượng của dịch vụ.

Các thực hành trong chương trình Quản lý Dịch vụ IT giúp nối phép đo với phạm vi và cam kết. Chủ dịch vụ cùng đại diện khách hàng cần hiểu điều đang được đo, không chỉ người cấu hình dashboard.

Bảng là bộ câu hỏi gợi ý, không phải các chỉ số bắt buộc cho mọi dịch vụ. Có thể bắt đầu với ít phép đo nhưng rõ mục đích. Một dữ liệu chưa dẫn đến câu hỏi hoặc quyết định cần được xem lại trước khi tăng công sức thu.

Availability cần phản ánh đúng chức năng và khoảng quan sát

Nếu đo theo thời gian, có thể tính phần thời gian dịch vụ khả dụng trên tổng thời gian trong phạm vi đã xác định. Phải nêu cách nhận diện không khả dụng, lịch quan sát và loại trừ. Nếu đo theo giao dịch, xác định giao dịch hợp lệ, thành công và mẫu số. Hai cách không nên được thay thế ngầm cho nhau trong báo cáo.

Ví dụ giả định, trong 1.000 phút thuộc phạm vi đo, một chức năng không khả dụng 10 phút và không có loại trừ, Availability theo thời gian là 99%. Kết quả này chỉ nói về chức năng và khoảng đã chọn. Nó không tự cho biết mọi nhóm đều dùng được, hay mọi giao dịch trong thời gian còn lại đều đúng.

Đo từ đâu cũng quan trọng. Kiểm từ trong trung tâm dữ liệu có thể không quan sát được trở ngại ở điểm làm việc của người dùng. Một kiểm tra mở trang chưa chắc kiểm được bước gửi giao dịch. Cần chọn tín hiệu phù hợp hành trình và ghi giới hạn, tránh coi một phép thử đơn giản là đại diện cho toàn dịch vụ.

Đọc sự gián đoạn một phần. Nếu chỉ một nhóm hoặc chức năng bị, một tỷ lệ tổng có thể che ảnh hưởng đáng kể. Có thể phân nhóm hoặc bổ sung chỉ số chức năng, nhưng phải giữ mẫu số rõ để không tạo nhiều tỷ lệ khó hiểu. Không nên gộp các tỷ lệ sẵn sàng bằng trung bình đơn giản khi phạm vi khác nhau mà không có lý do.

Năng lực giám sát và vận hành trong chương trình IT Administrator hỗ trợ thiết kế nguồn đo. Dữ liệu kỹ thuật phải được nối với dịch vụ, để một cảnh báo hoặc trạng thái bình thường có ý nghĩa đúng trong báo cáo chất lượng.

MTTR và SLA cần những đồng hồ không đánh tráo trải nghiệm

MTTR có thể được dùng với các nghĩa khác nhau, như thời gian khôi phục hoặc sửa chữa. Tổ chức phải viết rõ nghĩa đang chọn, điểm bắt đầu và kết thúc, lịch đo cùng phạm vi sự cố. Tên viết tắt giống nhau không bảo đảm hai nhóm đang đo cùng một khoảng.

Thời gian trung bình cần đọc cùng số ca và phân bố. Một vài sự cố kéo dài có thể làm số tăng; nhiều ca ngắn có thể che những ca hiếm nhưng tác động lớn. Có thể bổ sung trung vị hoặc phân vị khi tập dữ liệu đủ và cách tính rõ. Không nên suy diễn một phân vị từ mẫu quá nhỏ như một mức bảo đảm ổn định.

Các ca chưa phục hồi cần xuất hiện trong quản lý hiện trạng. Nếu chỉ tính những ca đã kết thúc, sự cố kéo dài đang mở có thể không góp vào chỉ số tốc độ. Báo cáo cần tuổi ca, trạng thái và người sở hữu để điều hành, thay vì đợi đóng mới thấy hậu quả.

SLA lại đo cam kết đã thỏa thuận, gồm phản hồi hoặc giải quyết theo định nghĩa. Chờ nhóm khác không tự cho phép tạm dừng. Các điều kiện dừng phải có căn cứ và cấu hình đúng. Bên cạnh đồng hồ cam kết, giữ tổng thời gian người dùng chờ để nhận ra độ trễ ngoài phần được tính.

Trải nghiệm cần cả kết quả, công sức và phản hồi có mẫu

Người dùng có thể nhận dịch vụ đúng thời gian nhưng phải gửi lại thông tin nhiều lần. Có thể họ được phục hồi kỹ thuật nhưng vẫn chưa thực hiện được việc vì dữ liệu hoặc quyền. Cần xem khả năng hoàn thành cùng số vòng liên hệ và các điểm chờ, không chỉ hỏi hài lòng sau khi ticket đóng.

Nếu dùng CSAT là tỷ lệ phản hồi tích cực, định nghĩa thang, mức tích cực và phản hồi hợp lệ. Báo cùng số phản hồi và tỷ lệ phản hồi trên đối tượng được khảo sát. Một tỷ lệ cao không tự đại diện người không trả lời; phản hồi theo kênh hoặc loại việc có thể khác nhau.

Thu nhận ý kiến theo câu hỏi cụ thể về hành trình, như có hiểu bước tiếp theo hoặc có hoàn thành được không. Phản hồi văn bản giúp chọn hồ sơ để kiểm tra cơ chế. Không nên xem một câu phàn nàn là bằng chứng mọi người đều gặp, nhưng cũng không bỏ qua chỉ vì nó nằm trong một mẫu nhỏ.

Các kỹ năng xác nhận và giao tiếp trong chương trình IT Helpdesk giúp giữ dữ liệu kết quả. Nhân viên cần ghi điều người dùng đã kiểm hoặc phần chưa xác nhận, tránh thay im lặng bằng một kết luận hài lòng.

Kết hợp chỉ số để đặt giả thuyết. SLA tốt nhưng phản hồi thấp có thể gợi vấn đề phạm vi, giao tiếp hoặc công sức; MTTR giảm cùng mở lại tăng cần xem điều kiện khôi phục. Những mẫu này chỉ hướng nơi điều tra. Phải đọc bằng chứng trước khi kết luận nguyên nhân hoặc đánh giá nhân viên.

Tổ chức nhịp đo để mỗi phát hiện có một quyết định

Người sở hữu dữ liệu cần kiểm sai lệch như thiếu thời điểm, trạng thái dùng không thống nhất hoặc nguồn giám sát mất đoạn. Nêu mức tin cậy và phần chưa đủ. Một dashboard cập nhật tự động vẫn có thể sai nếu quy ước nhập hoặc sự kiện nguồn không khớp định nghĩa.

Cuộc rà cần chọn câu hỏi, hồ sơ mẫu và hành động, với người nhận cùng mốc kiểm. Nếu thời gian chờ phê duyệt gây trở ngại, hành động có thể là sửa đầu vào hoặc quyền dự phòng. Nếu chức năng có sẵn nhưng dùng khó, có thể cần thiết kế lại hướng dẫn hoặc luồng. Không phải mọi số xấu đều giải bằng thêm hạ tầng.

Trưởng nhóm giữ việc rà và huấn luyện theo dữ liệu. Vai trò trong chương trình IT Supervisor hỗ trợ đọc chênh lệch mà không biến chỉ số thành áp lực đóng sớm. Mục tiêu cần cân bằng tốc độ, tính đúng và khả năng sử dụng, để hành vi tối ưu một tỷ lệ không làm chất lượng chung giảm.

Sau cải tiến, so sánh trong phạm vi phù hợp và ghi thay đổi nhu cầu hoặc điều kiện. Số sự cố giảm khi lượng dùng giảm chưa đủ chứng minh hành động thành công. Tỷ lệ tốt lên vì tập hồ sơ đổi cần được giải thích. Việc giữ cơ sở so sánh giúp tổ chức quyết định tiếp bằng bằng chứng.

Rà lại hệ đo khi dịch vụ đổi chức năng, khách hàng hoặc lịch. Không nên giữ một phép đo không còn phản ánh mục đích chỉ vì đã có biểu đồ lâu năm. Đồng thời, mỗi lần đổi cần bảo vệ khả năng đọc lịch sử và hiểu nguyên nhân biến động.

Bước khởi đầu là chọn một dịch vụ và một chỉ số đang ảnh hưởng quyết định, viết lại định nghĩa rồi đi qua một mẫu sự kiện. Bổ sung phần kết quả hoặc trải nghiệm đang thiếu trước khi thêm hàng loạt KPI. Hệ đo có giá trị khi tổ chức biết điều gì đã được bảo đảm, điều gì còn chưa quan sát và hành động nào sẽ cải thiện công việc của người dùng.

Bài viết liên quan

• Xây dựng mô hình quản lý sự cố nghiêm trọng – Major Incident Management.
• Quản lý chi phí dịch vụ IT: Xác định chi phí và mức độ tiêu thụ của từng dịch vụ.
• Triển khai Continual Improvement: Chuyển dữ liệu vận hành thành kế hoạch cải tiến.
• SLA đạt nhưng người dùng vẫn phàn nàn: Chỉ số nào chưa phản ánh trải nghiệm?

Nguồn tham khảo

1. Google SRE — Service Level Objectives
2. PeopleCert — ITIL 4 Practitioner: Service Level Management
3. Atlassian — Service Level Agreements