Một doanh nghiệp thiết kế lại dịch vụ IT theo ITIL 4: Bắt đầu từ đâu?

Gọi tên dịch vụ bằng công việc cần đạt

Doanh nghiệp đang quản lý theo nhóm công nghệ: thiết bị, mạng, ứng dụng và quyền. Cách tổ chức này giữ chuyên môn nhưng khiến nhân viên phải hiểu cơ cấu nội bộ để tìm người giúp. Khi vấn đề liên quan nhiều phần, họ nhận nhiều hướng dẫn mà không biết ai giữ kết quả.

Nhóm khởi động chọn một dịch vụ làm việc và cộng tác từ nhiều địa điểm. Kết quả cần hỗ trợ là nhân viên có khả năng truy cập, sử dụng thông tin đúng và hoàn tất công việc theo vai trò. Các thành phần kỹ thuật vẫn được quản lý, nhưng giờ được nối với một nhu cầu rõ.

Cần xác định khách hàng nội bộ, người dùng, người cấp nguồn lực và chủ dịch vụ. Chủ nghiệp vụ hiểu công việc, IT hiểu khả năng cung cấp, còn người phụ trách thông tin xác nhận điều kiện sử dụng. Không giao toàn bộ trách nhiệm giá trị cho IT chỉ vì dịch vụ có nhiều công nghệ.

Nền tảng trong chương trình ITIL 4 Foundation là hướng tham khảo để xây ngôn ngữ chung. Trong tình huống, các thuật ngữ phải được diễn giải thành kết quả và vai trò thực tế, để chương trình không chỉ đổi tên phòng ban hoặc hồ sơ.

Đi theo hành trình trước khi thiết kế lại

Nhóm quan sát một số nhu cầu phù hợp: nhân viên bắt đầu công việc tại địa điểm mới, cần truy cập tài liệu hoặc gặp gián đoạn. Họ ghi thông tin đầu vào, người tham gia, chờ và làm lại. Những trao đổi qua thư riêng hoặc bảng cá nhân cũng được nhìn, vì đó là phần công việc đang diễn ra.

Dữ liệu cho thấy một số yêu cầu thiếu vai trò, tài liệu hướng dẫn phân tán và đầu mối thường chuyển người dùng sang nhóm khác. Nhiều phần công nghệ vẫn tạo giá trị, nhưng cách giao nhận chưa đủ. Thay công cụ toàn bộ lúc này có thể làm mất thời gian mà chưa sửa quyền và dữ liệu.

Nhóm rà bốn chiều: tổ chức và con người; thông tin và công nghệ; đối tác và nhà cung cấp; luồng giá trị và quy trình. Trong mỗi chiều, họ tìm điều kiện liên quan kết quả, không thu thập mọi thông tin chỉ để lập một bản kiểm kê lớn. Các khoảng trống được giữ cùng bằng chứng và giới hạn.

Một phát hiện cần được đối chiếu trước khi biến thành nguyên nhân. Nhân viên nói công cụ chậm có thể đang chờ quyền hoặc chưa tìm được tài liệu đúng. Quan sát công việc giúp nhóm chọn kiểm tra, thay vì nhận mọi lời đề nghị như một yêu cầu chức năng đã đủ rõ.

Thiết kế khả năng cung cấp và trách nhiệm cùng nhau

Doanh nghiệp mô tả offering theo nhóm sử dụng: khả năng truy cập, cộng tác, hỗ trợ và điều kiện. Phần quyền, dữ liệu, giờ phục vụ và việc người dùng cần làm được nêu rõ. Mô tả phải giúp lựa chọn, không chỉ liệt kê ứng dụng đang có.

Chủ dịch vụ cùng các nhóm thiết kế luồng từ nhu cầu tới kết quả. Những hoạt động của Service Value Chain được kết hợp theo loại nhu cầu, không coi là một tuyến duy nhất. Yêu cầu quen thuộc dùng cách cung cấp đã chuẩn bị; nhu cầu khác hoặc thay đổi có tác động cần đánh giá phù hợp.

Tại mỗi điểm giao nhận, xác định đầu ra, người nhận và điều kiện. Service Desk giữ đường thông tin với người dùng, các nhóm thực hiện chuyên môn và người có quyền quyết định ngoại lệ. Một đầu mối dịch vụ không làm thay mọi việc, nhưng phải có khả năng yêu cầu làm rõ khi luồng dừng.

Bảng là công cụ thiết kế đề xuất cho tình huống giả định, không phải mẫu ITIL bắt buộc. Nhóm dùng nó để rà sự nhất quán. Nếu cam kết cần nguồn lực chưa có hoặc người xác nhận không đủ quyền, phải sửa điều kiện trước khi công bố cách phục vụ mới.

Năng lực tổ chức dịch vụ theo nhu cầu và kết quả có thể được phát triển qua chương trình Quản lý Dịch vụ IT – ITSM. Trong doanh nghiệp, người sở hữu dịch vụ phải được xác nhận và có cơ chế phối hợp, để mô hình tiếp tục được dùng sau giai đoạn thiết kế.

Chọn practices theo khoảng trống, không theo danh sách

Nhóm không cần triển khai đồng thời mọi practice. Họ chọn những khả năng đang ảnh hưởng rõ: tiếp nhận và xử lý yêu cầu, tri thức, mức dịch vụ, quyền cùng các kiểm soát liên quan. Các practices hỗ trợ người, thông tin, công nghệ và cách làm, không chỉ tạo thêm quy trình.

Incident Management giúp khôi phục khi khả năng làm việc bị gián đoạn; Problem Management giúp quản lý nguyên nhân hoặc nguy cơ; Change Enablement giữ thay đổi có đánh giá và quyền phù hợp. Những phần này cần giao nhận thông tin, nhưng có mục tiêu khác nên không gộp mọi vấn đề vào một loại ticket.

Tri thức phải có người cập nhật và điều kiện sử dụng. Một hướng dẫn cũ được sao chép vào kho mới chưa tự tạo giá trị. Nhóm chọn nội dung theo nhu cầu, thử với người dùng và giữ đường nhận hỗ trợ khi họ không đủ điều kiện hoặc cách làm không khớp.

Năng lực phân công và điều phối có thể được phát triển qua chương trình Trưởng Phòng IT – IT Manager. Trong tình huống, người quản lý phải bố trí nguồn lực thường xuyên, không chỉ yêu cầu chuyên gia viết tài liệu ngoài công việc hiện hữu rồi mặc định dịch vụ mới đã sẵn sàng.

Thử một phạm vi có thể học và điều chỉnh

Doanh nghiệp chọn một nhóm vai trò và một số nhu cầu để thử. Họ giữ định nghĩa hoàn tất, dữ liệu nền và những điều kiện bảo vệ thông tin. Phạm vi đủ nhỏ để quan sát, nhưng phải đủ để kiểm tra quan hệ giữa đầu vào, giao nhận và khả năng người dùng thực hiện công việc.

Trong thử nghiệm, nhóm theo dõi lúc người dùng được nhận, các lần hỏi lại, điều kiện thiếu và việc có thể tiếp tục sau hỗ trợ. Phản hồi từ người chưa hoàn tất cũng được giữ. Không chỉ khảo sát nhóm thuận lợi hoặc xem số yêu cầu tự phục vụ như bằng chứng thành công.

Nếu việc tìm hướng dẫn tốt hơn nhưng quyền vẫn tới muộn, bước tiếp theo cần xử lý nguồn vai trò và cơ chế xác nhận. Nếu thông tin đã đúng mà công cụ không hỗ trợ giao nhận, có căn cứ điều chỉnh công nghệ. Phản hồi làm kế hoạch thay đổi theo vấn đề đã quan sát.

Nhóm cũng rà tác động tới hoạt động hiện hữu. Nhân lực tham gia cải tiến vẫn cần hỗ trợ dịch vụ đang chạy; lịch phải phản ánh tải thực. Không nên tạo một phạm vi thử chỉ hoạt động vì các việc khác bị bỏ mà không được người có quyền thống nhất.

Việc kiểm chứng cần giữ giới hạn. Nhóm vai trò được chọn có thể có dữ liệu hoặc nhu cầu khác với nhóm sẽ mở rộng. Những khác biệt đó là đầu vào cho bước tiếp theo, không phải lý do mặc định sao chép toàn bộ cách làm đã thử.

Đưa kết quả vào cơ chế điều hành thường xuyên

Sau thử nghiệm, người bảo trợ và chủ dịch vụ xem tác dụng cùng chi phí, rủi ro và điều kiện. Có thể giữ, sửa, mở rộng hoặc dừng một phần. Quyết định cần ghi người sở hữu và tiêu chí xem lại, để tiến triển không chỉ được kể bằng số tài liệu đã tạo.

Mức dịch vụ được rà theo khả năng toàn chuỗi. Báo cáo cần phản ánh kết quả công việc, những điểm chờ quan trọng và sai lệch cần lựa chọn. Các chỉ số kỹ thuật vẫn giúp giải thích, nhưng không nên thay thế việc xác nhận dịch vụ đang hỗ trợ nhu cầu ra sao.

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 nối kết quả dịch vụ với lựa chọn doanh nghiệp. Trong thực tế, lãnh đạo cần sử dụng thông tin mới trong quyết định nguồn lực và trách nhiệm, nếu không hành vi của các nhóm sẽ khó thay đổi.

Cơ chế cải tiến thường xuyên cần chủ hành động, dữ liệu và thời điểm. Khi nhu cầu hoặc đối tác đổi, rà phạm vi và điều kiện thay vì giữ cam kết cũ theo thói quen. Những bài học từ thử phải được chuyển thành tri thức dùng được để nhóm khác không phải học lại mọi thứ.

Doanh nghiệp trong tình huống không bắt đầu bằng việc làm đủ một thư viện quy trình. Họ bắt đầu từ công việc bị cản, giữ phần hiện trạng có ích, làm rõ trách nhiệm và thử một cách phục vụ có thể kiểm chứng. Đó là lộ trình để ITIL 4 đi vào dịch vụ thực, với giá trị được quản lý sau cả ngày triển khai.

Bài viết liên quan

• Think and Work Holistically: Vì sao tối ưu một bộ phận chưa chắc cải thiện toàn bộ dịch vụ?
• Keep It Simple and Practical: Thiết kế quy trình IT đủ kiểm soát nhưng không quan liêu.
• Service Level Management: Chuyển cam kết dịch vụ thành các chỉ số có ý nghĩa.
• Continual Improvement Model: Áp dụng bảy bước để cải tiến hoạt động dịch vụ IT.

Nguồn tham khảo

1. PeopleCert — ITIL 4 Foundation
2. PeopleCert Community — Culture as the True Success Factor in ITIL Adoption
3. PeopleCert Community — Creative ITIL Implementation: Practicing the Framework Before It Is Formally Adopted