INFOCHIEF ACADEMY · ITIL 4 KNOWLEDGE SERIES

Hiểu đúng khái niệm giá trị dịch vụ: Vì sao dịch vụ IT không chỉ là sản phẩm công nghệ?

Sản phẩm tạo khả năng, còn dịch vụ cần các điều kiện để khả năng ấy được sử dụng và tạo kết quả. Phân biệt đầu ra, kết quả, chất lượng và trách nhiệm giúp doanh nghiệp hiểu giá trị vượt khỏi ngày bàn giao.

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

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

Quản lý nghiệp vụ và IT quan sát nhân viên sử dụng dịch vụ để hoàn thành công việc
Minh họa biên tập: quản lý nghiệp vụ và IT quan sát nhân viên sử dụng dịch vụ để hoàn thành công việc.

Doanh nghiệp mua một ứng dụng để nhân viên xử lý hồ sơ nhanh hơn. Phần mềm được bàn giao, tài khoản đã cấp, nhưng những bước kiểm tra và xin xác nhận vẫn diễn ra qua thư điện tử. Sản phẩm công nghệ đã có, còn giá trị mong đợi chưa xuất hiện đầy đủ.

Sự khác biệt giữa sản phẩm và dịch vụ giúp giải thích tình huống ấy. Sản phẩm tập hợp nguồn lực và khả năng, trong khi dịch vụ giúp bên sử dụng đạt kết quả với những điều kiện, trách nhiệm và mức đánh đổi phù hợp. Nhìn giá trị theo cách này làm rõ vì sao bàn giao công nghệ chưa phải điểm kết thúc.

Người dùng cần kết quả, không chỉ tài nguyên

Trong ITIL 4, dịch vụ hỗ trợ bên sử dụng đạt các kết quả mong muốn và giảm phần chi phí, rủi ro cụ thể mà họ phải tự quản lý. Điều đó không có nghĩa bên sử dụng không còn chi phí hoặc rủi ro. Dịch vụ thay đổi cách chúng được phân bổ và quản lý trong quan hệ giữa các bên.

Một nền tảng lưu trữ có thể giúp nhóm làm việc chia sẻ tài liệu mà không tự duy trì máy chủ. Nhưng họ vẫn cần tổ chức quyền, chất lượng nội dung và cách sử dụng. Nếu những điều kiện này không rõ, công nghệ có thể hoạt động đúng mà tài liệu vẫn khó tìm hoặc bị chia sẻ sai.

Sản phẩm công nghệ vì thế là một phần quan trọng của khả năng cung cấp. Dịch vụ còn gồm cách tiếp nhận nhu cầu, vận hành, hỗ trợ và phối hợp để khả năng ấy dùng được. Không nên coi dịch vụ chỉ là phần hỗ trợ thêm sau khi mua sản phẩm, vì nhiều điều kiện phải được thiết kế từ đầu.

Câu hỏi cần chuyển từ “đã cung cấp gì” sang “người nào có thể làm được điều gì”. Cách hỏi này không phủ nhận chất lượng kỹ thuật. Nó giúp xác định chất lượng nào thật sự cần và những điều kiện ngoài kỹ thuật nào phải được tổ chức để kết quả xuất hiện.

Phân biệt sản phẩm bàn giao với kết quả đạt được

Output là đầu ra được tạo bởi hoạt động; outcome là kết quả mà một bên đạt được hoặc được hỗ trợ đạt. Cấp một tài khoản là đầu ra. Người dùng có thể thực hiện công việc theo vai trò là kết quả. Hai nội dung liên quan nhưng không nên dùng thay nhau trong báo cáo.

Đầu ra có thể được xác nhận tương đối rõ bằng việc giao nhận, còn kết quả thường cần nhìn quá trình sử dụng và các điều kiện. Nếu người dùng chưa được phân công hoặc chưa có dữ liệu phù hợp, tài khoản mới không tự tạo khả năng làm việc. Người quản lý cần biết phần nào đã hoàn tất và phần nào còn phải thực hiện.

Giá trị còn phụ thuộc nhận thức và hoàn cảnh của các bên. Một cách làm giúp nhóm này nhanh hơn có thể tăng việc cho nhóm khác. Một dịch vụ có tính năng tốt nhưng không phù hợp thời điểm sử dụng có thể ít tác dụng. Cần xác định người nhận giá trị và điều kiện thay vì tuyên bố giá trị chung cho mọi người.

Nền tảng trong chương trình ITIL 4 Foundation là hướng tham khảo để thống nhất các khái niệm này. Trong áp dụng, nhóm nên viết kết quả bằng công việc cụ thể và xác nhận với người sử dụng, để các thuật ngữ trở thành căn cứ thiết kế thay vì chỉ xuất hiện trong tài liệu.

Một kiểm tra đơn giản là chọn một đầu ra đã bàn giao rồi truy người sử dụng, công việc và bằng chứng kết quả. Nếu đường nối còn thiếu, cần ghi điều kiện và chủ sở hữu. Không nên tự bù khoảng trống bằng việc khẳng định hệ thống có nhiều người dùng nên chắc chắn tạo hiệu quả.

Utility và warranty tạo hai câu hỏi chất lượng

Utility thường được hiểu là khả năng phù hợp với mục đích: dịch vụ hỗ trợ chức năng hoặc loại bỏ rào cản cần thiết. Warranty là sự bảo đảm phù hợp điều kiện sử dụng. Nó liên quan khả năng cung cấp như mức sẵn sàng, năng lực, tính liên tục và an toàn phù hợp với yêu cầu.

Một dịch vụ có thể làm đúng điều cần nhưng không dùng được vào thời điểm quan trọng. Ngược lại, hạ tầng rất ổn định vẫn không giúp ích nếu chức năng không hỗ trợ công việc. Hai góc nhìn cần được xem cùng nhau khi thiết kế và đo, không coi một phần đạt là toàn bộ chất lượng đã được xác nhận.

Tình huống giả định: nhân viên bán hàng cần tra cứu tồn kho khi gặp khách. Ứng dụng có thông tin cần thiết, nhưng độ trễ cập nhật khiến họ không thể đưa cam kết đáng tin. Vấn đề liên quan cả khả năng thông tin hỗ trợ quyết định và điều kiện cung cấp, không chỉ tốc độ tải màn hình.

Góc nhìn chất lượng đề xuấtCâu hỏi với dịch vụBằng chứng phù hợp
UtilityCông việc nào được hỗ trợ?Khả năng thực hiện các tình huống cần thiết
WarrantyKhả năng ấy dùng được trong điều kiện nào?Kết quả theo cam kết và thời điểm sử dụng
Kết quảNgười dùng đạt điều gì?Xác nhận công việc cùng dữ liệu nghiệp vụ
Trải nghiệmViệc sử dụng có thuận tiện và đáng tin?Quan sát, phản hồi và các điểm làm lại

Bảng là công cụ thiết kế đề xuất, không phải thang đánh giá chính thức của ITIL. Khi áp dụng, cần giữ định nghĩa và phạm vi rõ. Một phản hồi tích cực chưa thay cho kiểm tra chức năng, còn một chỉ số hạ tầng tốt chưa thay cho việc xác nhận khả năng hoàn thành công việc.

Năng lực tổ chức chất lượng theo dịch vụ có thể được phát triển qua chương trình Quản lý Dịch vụ IT – ITSM. Ở nơi áp dụng, chủ dịch vụ và chủ nghiệp vụ cần cùng thống nhất các điều kiện, để cam kết không chỉ phản ánh những gì công cụ kỹ thuật dễ đo.

Giá trị cần nhìn cả chi phí và rủi ro sử dụng

Một dịch vụ giúp giảm công việc tự quản lý của bên sử dụng, nhưng có thể tạo những yêu cầu mới. Dùng nền tảng chung giúp tránh duy trì công cụ riêng, đồng thời đòi hỏi cập nhật dữ liệu đúng cách và phối hợp khi thay đổi. Những điều kiện đó cần được giải thích để hai bên hiểu trách nhiệm.

Chi phí không chỉ là tiền mua hoặc thuê. Thời gian chờ, thao tác làm lại, hỗ trợ và phát triển năng lực đều ảnh hưởng khả năng sử dụng. Một giải pháp rẻ ở mức đầu tư nhưng khiến nhân viên phải xử lý thủ công nhiều hơn có thể không phải lựa chọn tốt cho kết quả chung.

Rủi ro cũng cần được đặt trong công việc. Tự động hóa một bước có thể giảm lỗi nhập liệu nhưng tạo phụ thuộc vào dữ liệu hoặc quyền mới. Cần đánh giá hệ quả và người chấp nhận theo thẩm quyền, thay vì xem tính năng tự động là bằng chứng mọi rủi ro đã giảm.

Người quản lý cần đưa các điều kiện vào kế hoạch và cách phục vụ. Chương trình Trưởng Phòng IT – IT Manager là hướng tham khảo để củng cố năng lực tổ chức trách nhiệm và nguồn lực. Điều quan trọng là các điều kiện được thực hiện, không chỉ được ghi ở phần giả định của đề xuất.

Thiết kế lại một dịch vụ từ hành trình thực

Tình huống giả định: doanh nghiệp có cổng nộp hồ sơ nhưng người dùng thường phải gọi để biết còn thiếu gì. Nhóm IT ban đầu đề xuất thêm thông báo tự động. Khi quan sát, họ phát hiện các bộ phận đang dùng tiêu chí hồ sơ khác nhau, nên cùng một trạng thái không có nghĩa thống nhất.

Nếu chỉ bổ sung thông báo, người dùng có thể nhận thông tin nhanh hơn nhưng vẫn không biết phải làm gì. Nhóm cần thống nhất tiêu chí, trách nhiệm xác nhận và cách diễn giải trạng thái. Công nghệ hỗ trợ chuyển thông tin, còn giá trị phụ thuộc việc thông tin có đủ rõ để người dùng tiếp tục công việc.

Nhóm chọn một loại hồ sơ để thử. Họ xác định đầu ra cần tạo, kết quả mong đợi và cách kiểm tra các điểm dừng. Phản hồi giúp nhìn trường hợp hướng dẫn không rõ hoặc tiêu chí còn mâu thuẫn, rồi sửa trước khi mở rộng. Việc dùng dịch vụ được theo dõi bên cạnh trạng thái hệ thống.

Kết quả tốt trong phạm vi thử cần được trình cùng các điều kiện. Nếu nhóm xử lý đặc biệt phải hỗ trợ liên tục, chưa thể coi cách làm đã sẵn sàng cho toàn doanh nghiệp. Cần tổ chức năng lực thường xuyên và xác nhận người sở hữu để giá trị không phụ thuộc hỗ trợ tạm thời.

Trình giá trị bằng một lập luận có thể kiểm tra

Một hồ sơ giá trị nên nêu người sử dụng, kết quả, khả năng cung cấp, điều kiện và bằng chứng. Nó giúp phân biệt phần đã được tạo với phần còn cần thực hiện. Không nên quy toàn bộ kết quả cho IT nếu quy trình, chính sách hoặc cách phân công cũng thay đổi.

Ở cấp lãnh đạo, thông tin cần dẫn tới lựa chọn về phạm vi, cam kết và nguồn lực. Khi lợi ích chưa xuất hiện, cần biết điều kiện nào đang cản và ai có quyền xử lý. Góc nhìn trong chương trình Lãnh đạo IT – CIO là hướng tham khảo để phát triển cách đối thoại này với nghiệp vụ và người bảo trợ.

Doanh nghiệp có thể bắt đầu bằng một sản phẩm đã bàn giao và hỏi dịch vụ bao quanh nó còn thiếu điều gì. Người dùng cần hướng dẫn, quyền, dữ liệu, hỗ trợ hay một cách làm khác? Câu trả lời sẽ giúp chọn biện pháp có tác dụng hơn việc mặc định bổ sung tính năng.

Giá trị dịch vụ được nhìn rõ khi khả năng công nghệ nối được với kết quả trong hoàn cảnh sử dụng thực. Khi đầu ra, điều kiện và trách nhiệm được phân biệt, tổ chức biết phần nào đã tạo, phần nào cần kiểm chứng và việc gì phải làm tiếp. Đó là căn cứ để quản lý dịch vụ vượt ra ngoài việc bàn giao sản phẩm.

Nguồn tham khảo

  1. PeopleCert — ITIL 4 Specialist: Drive Stakeholder Value
  2. PeopleCert — ITIL 4 Practitioner: Service Level Management
  3. PeopleCert Community — Avoiding Unnecessary IT Spending: An ITIL-Driven Approach