INFOCHIEF ACADEMY · IT MANAGER KNOWLEDGE SERIES

Xây dựng danh mục dịch vụ IT để các phòng ban hiểu rõ trách nhiệm và cam kết phục vụ.

Khi người dùng không biết IT chịu trách nhiệm đến đâu, mọi yêu cầu đều trở thành “việc của IT”. Khi IT không biết dịch vụ mình đang cung cấp gồm những gì, SLA dễ trở thành con số rời rạc và trách nhiệm bị tranh cãi sau sự cố. Một danh mục dịch vụ tốt không phải brochure kỹ thuật; nó là hợp đồng vận hành ở mức đủ rõ để hai bên hiểu cách yêu cầu, cách phục vụ và giới hạn của cam kết.

Biên soạn: Infochief Academy · Chuyên đề: Trưởng Phòng IT Chuyên Nghiệp – IT Manager

← Trở về danh mục IT Manager

Minh họa biên tập: danh mục dịch vụ biến hoạt động kỹ thuật thành cam kết phục vụ mà các phòng ban có thể hiểu và sử dụng.

Tại sao “danh sách hệ thống” không phải danh mục dịch vụ?

Một danh sách gồm ERP, firewall, email, Wi‑Fi và server phản ánh tài sản hoặc thành phần công nghệ. Người dùng doanh nghiệp lại nghĩ theo nhu cầu: làm việc từ xa, cấp quyền nhân viên mới, bán hàng, xử lý đơn, truy cập dữ liệu, hỗ trợ điểm bán. Service catalog cần mô tả giá trị mà người dùng nhận, không chỉ tên công nghệ đứng phía sau.

Ví dụ “Microsoft 365” là nền tảng; “Dịch vụ cộng tác và email doanh nghiệp” mới gần với cách người dùng hiểu. “Active Directory” là thành phần; “Dịch vụ danh tính và truy cập” mô tả mục đích. Khi dịch vụ được đặt theo kết quả, các phòng ban dễ biết nên yêu cầu gì và IT dễ xác định owner, SLA, support model.

Đây cũng là tinh thần của Quản Lý Dịch Vụ IT – ITSM: quản lý IT như các dịch vụ tạo giá trị thay vì tập hợp hạ tầng kỹ thuật độc lập.

Một entry trong Service Catalog cần tối thiểu những gì?

Mỗi dịch vụ nên có tên dễ hiểu, mô tả giá trị/phạm vi, đối tượng sử dụng, service owner, giờ phục vụ, kênh yêu cầu, thời gian đáp ứng/khôi phục hoặc cam kết phù hợp, các phụ thuộc chính và trách nhiệm của người dùng. Nếu dịch vụ có nhiều option, nêu rõ tiêu chuẩn và ngoại lệ.

Không cần viết tài liệu dài. Catalog cho người dùng nên gọn; tài liệu kỹ thuật phía sau có thể chi tiết hơn. Mục tiêu là để một trưởng phòng kinh doanh đọc entry và biết: khi nào dùng dịch vụ, phải cung cấp thông tin gì, IT cam kết điều gì, và điều gì nằm ngoài phạm vi.

Trường thông tin	Câu hỏi cần trả lời	Ví dụ
Tên & giá trị	Dịch vụ giúp người dùng làm gì?	Onboarding nhân viên mới
Phạm vi	Bao gồm/không bao gồm gì?	Tài khoản, email, thiết bị chuẩn
Owner	Ai chịu trách nhiệm end-to-end?	IT Operations Manager
Cam kết	Thời gian/điều kiện phục vụ?	Hoàn tất trước ngày nhận việc nếu yêu cầu đủ trước X ngày
Kênh yêu cầu	Người dùng gửi ở đâu?	Service portal

Phân biệt Service Owner và đội kỹ thuật thực hiện

Dịch vụ thường đi qua nhiều nhóm: Service Desk tiếp nhận, Infrastructure cấp thiết bị, Security cấp quyền, Application cấu hình hệ thống. Nếu mỗi nhóm chỉ chịu phần việc của mình mà không ai chịu trách nhiệm end-to-end, người dùng sẽ bị chuyển qua lại. Service Owner cần chịu trách nhiệm về thiết kế, chất lượng, đo lường và cải tiến tổng thể, dù họ không trực tiếp thực hiện mọi task.

Vai trò này không có nghĩa owner được quyền ra mọi quyết định. RACI hoặc cơ chế trách nhiệm vẫn cần cho từng activity. Bài áp dụng RACI trong bộ phận IT có thể dùng để làm rõ giao diện giữa các nhóm, trong khi catalog giữ góc nhìn hướng ra khách hàng.

IT Manager nên tránh tạo một service owner “trên giấy” nhưng không có dữ liệu, quyền phối hợp hoặc thời gian review. Ownership chỉ có ý nghĩa khi gắn với cadence quản lý: review SLA, sự cố, nhu cầu thay đổi, rủi ro và trải nghiệm.

Cam kết dịch vụ phải dựa trên nhu cầu kinh doanh và khả năng thực tế

Không nên copy SLA từ mẫu hoặc đặt thời gian thật ngắn để làm đẹp dịch vụ. Cam kết phải cân bằng độ quan trọng của quy trình, thời gian người dùng cần và năng lực thực thi. Một yêu cầu truy cập hệ thống tài chính trước kỳ đóng sổ có độ nhạy khác yêu cầu cài phần mềm tiện ích. Phân loại dịch vụ và mức ưu tiên giúp SLA phản ánh tác động.

Đồng thời, SLA cần điều kiện đầu vào. Nếu onboarding nhân viên mới chỉ có thể hoàn tất đúng hạn khi HR gửi thông tin trước ba ngày, điều kiện này phải xuất hiện trong catalog. Khi hai bên cùng có trách nhiệm, cam kết trở thành công cụ phối hợp thay vì công cụ “phạt IT”.

Với các tổ chức muốn hệ thống hóa service level và service experience, ITIL 4 Foundation và Quản Lý Dịch Vụ IT – ITSM là các internal link phù hợp.

Thiết kế kênh yêu cầu để catalog thực sự được sử dụng

Catalog tốt nhưng người dùng vẫn nhắn trực tiếp qua chat, gọi cá nhân hoặc gửi email tự do thì quy trình chưa thay đổi. Mỗi dịch vụ cần một request channel rõ, form tối thiểu và routing phù hợp. Mục tiêu không phải ép người dùng điền nhiều thông tin; mục tiêu là thu đủ dữ liệu để xử lý nhanh và đo lường nhất quán.

Những yêu cầu phổ biến nên được productize: cấp account, cài phần mềm chuẩn, yêu cầu truy cập, thiết bị mới, hỗ trợ phòng họp. Form có thể tự động hóa bước approval, kiểm tra policy và tạo task cho nhóm thực hiện. Khi đó catalog trở thành giao diện thực tế của IT với doanh nghiệp, không phải tài liệu tĩnh.

Chương trình Kỹ Năng Hỗ Trợ Helpdesk / Service Desk hỗ trợ phần chuẩn hóa tiếp nhận và trải nghiệm người dùng ở tuyến đầu.

Triển khai theo 80/20: bắt đầu từ dịch vụ có nhu cầu cao và tác động lớn

Không cần xây 100 dịch vụ ngay từ đầu. Hãy chọn 10–20 dịch vụ tạo phần lớn tương tác với người dùng hoặc có tác động kinh doanh lớn. Với mỗi dịch vụ, tổ chức workshop ngắn với owner kỹ thuật và đại diện người dùng để thống nhất phạm vi, kỳ vọng và ngôn ngữ. Sau đó pilot, đo câu hỏi phát sinh và sửa entry trước khi mở rộng.

Catalog nên có version owner và ngày review. Khi nền tảng, chính sách hoặc tổ chức thay đổi, cam kết dịch vụ cũng thay đổi. Tài liệu cũ làm hại uy tín nhiều hơn không có tài liệu. IT Manager cần đưa catalog review vào operating rhythm, ví dụ hàng quý đối với dịch vụ trọng yếu và khi có thay đổi lớn.

Không nên biến catalog thành “menu marketing”. Nếu một cam kết chưa đo được hoặc không đủ capacity để thực hiện, hãy ghi rõ trạng thái pilot/target thay vì công bố như thực tế. Tính tin cậy của catalog quan trọng hơn độ bóng bẩy.

Một bước kiểm tra hữu ích trước khi mở rộng catalog là quan sát xem người dùng có còn phải hỏi “tôi phải liên hệ ai?” hoặc “yêu cầu này thuộc hệ thống nào?”. Nếu có, cách đặt tên dịch vụ hoặc routing vẫn chưa đủ trực quan. IT Manager có thể dùng dữ liệu tìm kiếm trên portal, ticket bị chuyển nhóm và câu hỏi lặp lại để cải tiến taxonomy. Khi catalog trưởng thành, mục tiêu không phải có nhiều entry hơn mà là giảm ma sát: người dùng tìm đúng dịch vụ nhanh hơn, cung cấp đủ thông tin ngay lần đầu và hiểu được kỳ vọng hai chiều trước khi gửi yêu cầu.

Tình huống minh họa: onboarding nhân viên mới bị đổ lỗi cho IT

Tình huống giả định: nhiều nhân viên mới đến ngày đầu vẫn chưa có đủ tài khoản. HR cho rằng IT chậm; IT cho rằng thông tin gửi sát giờ và manager chưa duyệt quyền. Sau khi xây service catalog entry “Onboarding nhân viên mới”, các bên thống nhất lead time, thông tin bắt buộc, standard access theo role, owner phê duyệt và cơ chế xử lý ngoại lệ.

Kết quả quan trọng không phải chỉ SLA đẹp hơn. Các tranh luận về trách nhiệm giảm vì điều kiện phục vụ được nhìn thấy từ trước. IT cũng có dữ liệu để chỉ ra tỷ lệ request đúng lead time, tỷ lệ ngoại lệ và bottleneck approval. Từ đó doanh nghiệp có thể cải tiến quy trình liên phòng ban thay vì tiếp tục xem vấn đề như hiệu suất riêng của IT.

Catalog vì vậy vừa là công cụ giao tiếp, vừa là nền tảng đo lường và tự động hóa. Nó giúp chuyển từ quản lý ticket rời rạc sang quản lý dịch vụ end-to-end.

Checklist trước khi công bố một dịch vụ trong catalog

Tên dịch vụ có được người dùng hiểu mà không cần biết thuật ngữ kỹ thuật?
Đã nêu rõ phạm vi bao gồm và loại trừ?
Có một service owner end-to-end?
Kênh yêu cầu và dữ liệu đầu vào đã chuẩn hóa?
Cam kết thời gian có điều kiện và có thể đo?
Trách nhiệm của người dùng/bộ phận yêu cầu đã nêu rõ?
Escalation và ngoại lệ có owner?
Entry có ngày review và người chịu trách nhiệm cập nhật?

Hành động nên bắt đầu: chọn năm loại yêu cầu phổ biến nhất trong ba tháng gần đây, nhóm chúng thành dịch vụ, viết một trang catalog entry cho từng dịch vụ và thử nghiệm với một phòng ban trước khi mở rộng.

Nguồn tham khảo

Các nguồn trên được sử dụng để tham khảo các nguyên tắc quản trị, quản lý dịch vụ và thực hành quản lý. Nội dung bài viết là diễn giải ứng dụng của Infochief Academy.