INFOCHIEF ACADEMY · ITSM KNOWLEDGE SERIES

Hạ tầng ổn định nhưng dịch vụ kém: Vì sao bộ phận IT cần tư duy ITSM?

Một hệ thống có thể hoạt động đúng mà người dùng vẫn không hoàn thành công việc. Tư duy ITSM nối hạ tầng, con người và quy trình với kết quả dịch vụ, giúp bộ phận IT quản lý cả hành trình thay vì chỉ từng thành phần.

Biên soạn: Infochief Academy · Chuyên đề: Quản lý dịch vụ IT

← Trở về thư viện bài viết

Quản lý dịch vụ IT và đại diện nghiệp vụ thảo luận trải nghiệm người dùng
Minh họa biên tập: quản lý dịch vụ IT và đại diện nghiệp vụ thảo luận trải nghiệm người dùng.

Máy chủ vẫn chạy, mạng không mất kết nối, bảng giám sát chưa phát cảnh báo. Nhưng phòng kinh doanh phải chờ cả buổi để được cấp quyền cho một nhân viên mới, còn kế toán không biết ai chịu trách nhiệm với lỗi báo cáo. Nhìn từ hạ tầng, IT đang ổn định. Nhìn từ công việc, dịch vụ đang có khoảng trống.

Tình huống giả định này giải thích vì sao chất lượng kỹ thuật chưa đủ để tạo chất lượng dịch vụ. Người dùng cần hoàn thành việc, không chỉ cần từng thiết bị hoạt động. ITSM giúp quản lý mối nối giữa nhu cầu, năng lực cung cấp và trách nhiệm xuyên suốt, để một kết quả không bị thất lạc giữa các nhóm chuyên môn.

Chuyển sang tư duy dịch vụ không làm giảm vai trò kỹ thuật. Nó đặt năng lực kỹ thuật trong một hệ thống ra quyết định rõ hơn: ai cần gì, điều kiện nào phải giữ và thế nào mới được xem là đã phục vụ thành công.

Đo thành phần đang chạy chưa trả lời được người dùng làm được gì

Tính sẵn sàng của máy chủ cho biết một điều quan trọng nhưng có phạm vi. Một giao dịch còn phụ thuộc ứng dụng, dữ liệu, quyền truy cập và cách vận hành. Nếu từng nhóm chỉ kiểm tra phần mình quản lý, kết quả bình thường của từng thành phần có thể không giải thích được một bước mà người dùng vẫn bị chặn.

Ngay cả khi công nghệ không lỗi, dịch vụ có thể kém vì yêu cầu đi sai nơi, thiếu thông tin hoặc chờ quyết định. Một nhân viên mới có thiết bị hoạt động nhưng chưa có quyền phù hợp vẫn chưa thể bắt đầu công việc. Khoảng chờ ấy cần được quản lý như một phần hành trình cung cấp, thay vì xem là việc hành chính nằm ngoài chất lượng IT.

Vì vậy, hỏi thêm câu về kết quả: người dùng đã làm được chức năng nào, ở thời điểm nào và trong điều kiện nào? Câu hỏi này nối chỉ số hạ tầng với bằng chứng sử dụng. Không nên thay mọi chỉ số kỹ thuật bằng khảo sát hài lòng; cần cả hai để biết vấn đề nằm ở thành phần hay ở cách tổ chức dịch vụ.

ITSM là quản lý dịch vụ IT theo nhu cầu và giá trị mà tổ chức cần nhận. Các khung thực hành như ITIL có thể cung cấp hướng tham khảo, nhưng doanh nghiệp phải chuyển thành trách nhiệm và cách làm phù hợp. Việc gọi tên một khung không tự giúp yêu cầu đi qua đúng nhóm hoặc tạo thêm nguồn lực xử lý.

Gọi tên dịch vụ bằng kết quả, rồi nối với năng lực kỹ thuật

Bắt đầu từ những công việc được IT hỗ trợ: trao đổi thông tin, xử lý đơn hàng, đối soát hoặc làm việc từ xa. Từ đó xác định dịch vụ và phạm vi sử dụng. Danh sách máy chủ, đường truyền và phần mềm là dữ liệu phía sau, chưa phải toàn bộ cách khách hàng nhận biết dịch vụ.

Một dịch vụ cần khách hàng hoặc nhóm nhận giá trị, người dùng, chủ dịch vụ và những nhóm cùng cung cấp. Khách hàng có thể quyết định yêu cầu và nguồn lực; người dùng trực tiếp sử dụng; chủ dịch vụ giữ trách nhiệm phối hợp theo quyền được giao. Trong tổ chức nhỏ, một người có thể giữ nhiều vai, nhưng các quyết định vẫn cần được phân biệt.

Ví dụ giả định, dịch vụ làm việc từ xa có thể bao gồm kết nối, xác thực và hỗ trợ truy cập các chức năng được phép. Người dùng cần biết điều kiện sử dụng và nơi gửi yêu cầu. Nhóm kỹ thuật cần biết phụ thuộc và quyền. Chủ dịch vụ cần thấy cả kết quả sử dụng lẫn điểm chờ trong cung cấp để xử lý khoảng trống giữa hai góc nhìn.

Góc nhìn quản lýCâu hỏi cần trả lờiBằng chứng phù hợp
Hạ tầngThành phần có hoạt động đúng?Chỉ số và kết quả kiểm tra kỹ thuật
Cung cấpYêu cầu có đi qua đúng người và điều kiện?Thời gian chờ, phê duyệt và giao nhận
Sử dụngNgười dùng có hoàn thành công việc?Kiểm tra chức năng và phản hồi có bối cảnh
Điều hànhAi quyết định khi các bên chưa thống nhất?Chủ dịch vụ, quyền và cơ chế chuyển cấp

Cách nhìn này giúp chọn phạm vi cải tiến. Nếu hạ tầng tốt nhưng cấp quyền chậm, đầu tư thêm máy chủ khó giải quyết điểm nghẽn. Nếu giao nhận rõ nhưng ứng dụng liên tục lỗi, cần năng lực kỹ thuật và điều tra. Tư duy dịch vụ giúp chọn đúng loại hành động thay vì quy mọi phàn nàn về một nguyên nhân quen thuộc.

Nội dung trong chương trình Quản lý Dịch vụ IT có thể được đối chiếu với cách tổ chức đang gọi tên dịch vụ. Khoảng trống cần củng cố thường nằm ở mối nối giữa phạm vi, trách nhiệm và kết quả, trước khi nằm ở việc thêm biểu mẫu.

Giữ trách nhiệm qua những đoạn khách hàng không nhìn thấy

Người dùng thường không biết một yêu cầu cần đi qua bao nhiêu nhóm. Họ cần một đầu mối và thông tin về bước tiếp theo. Khi ticket chuyển từ Service Desk sang ứng dụng rồi đến nhà cung cấp, trách nhiệm cập nhật và theo dõi phải được giữ hoặc chuyển rõ, tránh để mọi bên chỉ chịu trách nhiệm với thao tác của mình.

Một điểm giao nhận tốt xác định thông tin tối thiểu, người chấp nhận và đầu ra cần trả về. Chuyển nhóm trên phần mềm chưa đủ chứng minh công việc đã được nhận. Nếu nhóm đích không đủ khả năng, phải có đường điều phối hoặc xin quyết định, thay vì chuyển vòng đến khi một cá nhân tự đứng ra xử lý.

Tách người xử lý kỹ thuật khỏi người giữ tiến trình khi cần. Chủ dịch vụ không nhất thiết tự sửa mọi lỗi, nhưng phải có khả năng huy động và xin quyết định trong phạm vi trách nhiệm. Nếu chỉ có danh hiệu mà thiếu quyền hoặc đường chuyển cấp, tổ chức vẫn phụ thuộc vào quan hệ cá nhân lúc có sự cố.

Năng lực hỏi, ghi nhận và cập nhật của tuyến đầu trong chương trình IT Helpdesk hỗ trợ mối nối này. Một đầu mối tốt giúp người dùng không phải trở thành người điều phối giữa các chuyên gia, đồng thời giúp chuyên gia nhận được dữ kiện đủ để bắt đầu.

Cam kết dịch vụ cũng cần đi qua toàn chuỗi. Nếu khách hàng được hứa một thời gian hoàn tất nhưng nhóm phê duyệt và nhà cung cấp chưa có cam kết phù hợp, lời hứa có thể thiếu cơ sở. Phải rà phạm vi, lịch hỗ trợ và các khoảng chờ trước khi đưa con số vào SLA.

Tổ chức các thực hành quanh quyết định, tránh tạo thủ tục riêng lẻ

Incident Management hướng tới khôi phục dịch vụ khi bị gián đoạn; Problem Management điều tra và quản lý nguyên nhân để giảm tác động hoặc nguy cơ lặp. Service Request Management cung cấp nhu cầu theo điều kiện đã xác định. Quản lý thay đổi giúp đưa sửa đổi vào dịch vụ với rủi ro được đánh giá và quyền quyết định phù hợp.

Các phần này liên quan qua hồ sơ và quyết định thực. Một Incident được khôi phục bằng cách tạm có thể cần Problem tiếp tục điều tra. Một yêu cầu cấp quyền có thể đòi phê duyệt; một sửa lỗi lâu dài có thể cần Change. Nếu mỗi quy trình chỉ tối ưu trạng thái riêng, công việc vẫn có thể đứt ở điểm chuyển giữa chúng.

Không cần triển khai mọi thực hành cùng lúc. Chọn luồng đang gây tác động rõ, xác định quyết định cần làm và dữ liệu phục vụ quyết định ấy. Với tổ chức có nhiều chờ phê duyệt, cải thiện Service Request có thể hữu ích trước một dự án cấu hình rất rộng. Với sự cố lặp, cần nối khôi phục với điều tra và thay đổi.

Trưởng nhóm cần phân công, huấn luyện và giữ những điểm giao nhận trong công việc hằng ngày. Các năng lực trong chương trình IT Supervisor phù hợp khi thay đổi cách phối hợp giữa ca trực và nhóm kỹ thuật, nơi quy trình chỉ hiệu quả nếu nhân viên thực sự dùng được.

Đọc chất lượng bằng những chỉ số có phạm vi rõ

SLA đạt cao chưa tự chứng minh người dùng hài lòng; CSAT cao với ít phản hồi chưa phản ánh toàn bộ người dùng. Thời gian xử lý trung bình cũng có thể che các ca chờ rất lâu. Cần định nghĩa tập hồ sơ, điểm bắt đầu và kết thúc, lịch đo và điều kiện loại trừ, rồi đọc cùng số lượng cùng bối cảnh.

Có thể xem tỷ lệ hoàn thành đúng điều kiện, thời gian chờ theo bước, mở lại và khả năng tiếp tục công việc. Chỉ số kỹ thuật vẫn cần để chẩn đoán và dự báo, nhưng phải nối được với dịch vụ. Một cảnh báo về tài nguyên trở nên hữu ích hơn khi biết nó ảnh hưởng chức năng nào và ai cần được thông báo.

Tránh đặt mục tiêu khiến nhân viên đóng sớm hoặc né ca khó. Nếu tốc độ tăng cùng liên hệ lại tăng, cần đọc hồ sơ trước khi gọi là tiến bộ. Nếu nhu cầu tăng sau triển khai, cần xem năng lực và chất lượng đầu vào. Chỉ số nên dẫn đến một câu hỏi điều hành, không chỉ thành màu xanh trên dashboard.

Báo cáo cần có người sở hữu hành động. Khi phát hiện điểm chờ giữa hai nhóm, chỉ định người làm rõ giao nhận và thời điểm kiểm tra kết quả. Nếu nguyên nhân nằm ở phạm vi hoặc nguồn lực, cần xin quyết định cấp phù hợp thay vì yêu cầu tuyến đầu làm nhanh hơn trong điều kiện không đổi.

Bắt đầu từ một dịch vụ và chứng minh cách làm mới

Một bước khởi đầu có thể là dịch vụ tiếp nhận nhân viên mới. Làm rõ người yêu cầu, điều kiện đầu vào, phần IT cung cấp và các bước phụ thuộc. Chỉ định đầu mối theo dõi và kiểm tra khi người dùng bắt đầu được công việc. Đây là phạm vi đủ cụ thể để nhìn thấy cải tiến mà không cần tái thiết toàn bộ bộ phận.

Vai trò cấp quản lý trong chương trình IT Manager liên hệ với quyết định ưu tiên và quyền của chủ dịch vụ. Người lãnh đạo cần tạo điều kiện cho phối hợp, không chỉ giao thêm trách nhiệm rồi giữ nguyên những ranh giới khiến trách nhiệm ấy không thực hiện được.

Sau thử nghiệm, ghi kết quả cùng giới hạn và đưa phần đã hiệu quả vào cách làm thường lệ. Tư duy ITSM được chứng minh khi người dùng nhận được một dịch vụ có đầu mối, điều kiện và kết quả rõ. Hạ tầng ổn định vẫn là nền tảng; năng lực quản lý toàn hành trình mới giúp nền tảng ấy trở thành giá trị mà doanh nghiệp sử dụng được.

Nguồn tham khảo

  1. PeopleCert — ITIL: Digital Product and Service Management
  2. PeopleCert — ITIL 4 Practitioner: Service Desk
  3. PeopleCert — ITIL 4 Practitioner: Service Level Management