INFOCHIEF ACADEMY · ITSM KNOWLEDGE SERIES

Xây dựng cơ chế phối hợp giữa các nhóm IT để tránh tình trạng chuyển ticket vòng quanh.

Ticket đi vòng thường cho thấy trách nhiệm, bằng chứng hoặc điểm nhận việc chưa rõ. Thiết kế đầu mối dịch vụ và cơ chế giao nhận giúp chuyên môn được huy động đúng, còn tiến trình với người dùng vẫn được giữ liên tục.

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

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

Minh họa biên tập: service Desk cùng nhóm hạ tầng và ứng dụng thống nhất trách nhiệm nhận việc.

Ticket được chuyển từ Service Desk sang mạng, rồi ứng dụng, rồi quay về nơi tiếp nhận vì thiếu thông tin. Mỗi lần chuyển đều có một lý do, nhưng sau nhiều lượt chưa ai giữ câu hỏi người dùng ban đầu: làm sao hoàn thành công việc đang bị chặn? Phần mềm có đầy đủ lịch sử; trách nhiệm dịch vụ vẫn bị đứt.

Chuyển vòng không chỉ là vấn đề chọn sai nhóm. Nó có thể xuất phát từ danh mục chưa rõ, hồ sơ thiếu bằng chứng, quyền quyết định không khớp hoặc cơ chế nhận việc chỉ tồn tại trên giấy. Thêm quy tắc tự động sẽ ít hiệu quả nếu những khoảng trống ấy chưa được xử lý.

Doanh nghiệp cần thiết kế cách các nhóm nhận phần việc, giữ tiến trình và giải quyết tranh chấp. Khi đó ticket trở thành hồ sơ phối hợp, thay vì một vật được chuyển đến nơi có khả năng sẽ chịu trách nhiệm.

Dựng lại một vòng chuyển để biết nó đang thiếu điều gì

Chọn các ticket chuyển nhiều hoặc quay lại, đọc dòng thời gian và lý do từng lượt. Phân biệt chuyển có thông tin mới với chuyển chỉ đổi nhóm. Có thể cần nhiều chuyên môn; điều đáng sửa là những lượt không tạo tiến triển hoặc không có xác nhận người sẽ làm bước tiếp.

Nếu lý do là thiếu dữ liệu, xem thông tin đó có thể thu ở tuyến đầu không và người nhận đã mô tả nhu cầu rõ chưa. Nếu là ngoài phạm vi, xem danh mục có chỉ đúng đầu mối không. Nếu là quá tải, cần cơ chế nguồn lực; đổi tên nhóm nhận không tạo thêm năng lực xử lý.

Không nên đặt số lượt chuyển bằng không cho mọi ticket. Một yêu cầu có nhiều phần có thể cần chuyển hoặc tách nhiệm vụ hợp lý. Mục tiêu là đúng năng lực với ít vòng hỏi lại và trách nhiệm liên tục. Chỉ số chuyển cần được đọc cùng độ phức tạp và chất lượng kết quả.

Các thực hành trong chương trình Quản lý Dịch vụ IT hỗ trợ nối danh mục, Incident và Service Request. Phân loại theo mục tiêu giúp chọn luồng đúng trước khi chọn nhóm, tránh gửi một nhu cầu cung cấp vào nhóm đang cố tìm nguyên nhân kỹ thuật.

Giữ một người sở hữu tiến trình, chia rõ phần chuyên môn

Người sở hữu ticket hoặc dịch vụ cần biết việc đang ở đâu, ai làm tiếp và người dùng nhận thông tin từ ai. Nhóm chuyên môn có thể giữ một nhiệm vụ, không nhất thiết giữ toàn bộ quan hệ khách hàng. Nếu chuyển toàn bộ trách nhiệm, phải chuyển cả cập nhật và điều kiện kết thúc, không chỉ tên trên hồ sơ.

Với nhiều nhóm cùng tham gia, có thể giữ hồ sơ chung và các nhiệm vụ liên kết. Mỗi nhiệm vụ nêu câu hỏi, người nhận và đầu ra. Người giữ tiến trình tổng hợp kết quả về mục tiêu phục hồi hoặc cung cấp, tránh để người dùng phải ghép các câu trả lời riêng.

Chủ dịch vụ cần quyền phối hợp hoặc đường xin quyết định khi nhóm chưa thống nhất. Một cái tên trong trường sở hữu chưa đủ nếu người đó không huy động được và không biết ai chốt tranh chấp. Cơ chế phải dựa trên quyền tổ chức đã giao, không chỉ dựa vào người có quan hệ tốt với nhiều nhóm.

Tình huống giả định, một lỗi báo cáo có thể liên quan kết nối hoặc xử lý ứng dụng. Service Desk giữ đầu mối, nhóm mạng kiểm một luồng theo thời điểm, nhóm ứng dụng kiểm dấu vết giao dịch. Không cần chuyển toàn bộ ticket qua lại sau mỗi kết quả bình thường; người điều phối giữ các câu hỏi còn mở và bước kiểm chứng tiếp.

Đặt điều kiện nhận việc và phản hồi đủ dùng

Gói giao nhận cần dịch vụ, biểu hiện, thời điểm, phạm vi cùng thao tác đã làm và kết quả. Người gửi nêu rõ cần người nhận kiểm điều gì hoặc quyết định điều gì. “Nhờ hỗ trợ” có thể dùng trong trao đổi, nhưng không nên là toàn bộ đầu ra của một lần chuyển cấp.

Người nhận cần phản hồi chấp nhận hoặc nêu cụ thể phần còn thiếu và cách tiếp tục. Nếu thiếu thông tin nhưng tác động lớn, có thể nhận phần kiểm phù hợp và phân công bổ sung, thay vì trả toàn bộ rồi chờ. Trách nhiệm không nên phụ thuộc việc biểu mẫu đã đủ mọi trường trong tình huống khẩn.

Điểm giao nhận	Điều phải xác định	Tín hiệu công việc đã đi tiếp
Gửi nhiệm vụ	Câu hỏi và bằng chứng đủ dùng	Đúng đầu mối được thông báo
Nhận nhiệm vụ	Người làm và phần còn thiếu	Chấp nhận cùng bước tiếp theo
Trả kết quả	Phép kiểm, phạm vi và kết luận	Điều đã xác nhận cùng giới hạn
Kết thúc hoặc chuyển tiếp	Trách nhiệm còn lại	Người nhận rõ và hồ sơ được liên kết

Bảng là một mẫu kiểm giao nhận. Những cam kết nội bộ cần lịch, thời gian và cơ chế chuyển cấp phù hợp dịch vụ. Chờ nhóm khác không tự làm đồng hồ SLA dừng; cách đo phải theo thỏa thuận. Giữ tổng thời gian người dùng chờ giúp thấy phần độ trễ mà quy tắc SLA có thể không phản ánh.

Những kỹ năng mô tả và ghi hành động trong chương trình IT Helpdesk giúp giảm vòng hỏi. Tuyến đầu cần nhận phản hồi cụ thể từ nhóm chuyên môn để cải thiện hồ sơ, thay vì chỉ biết ticket bị trả vì không đủ chất lượng.

Tranh chấp cần một đường quyết định, không cần thêm vòng chuyển

Khi hai nhóm đều cho rằng phần việc ngoài phạm vi, giữ ticket ở một đầu mối đang chịu trách nhiệm và gọi người điều phối theo cơ chế. Người quyết định xem mục tiêu dịch vụ, bằng chứng và năng lực, rồi phân phần cần làm. Không nên dùng việc ai chạm ticket gần nhất làm căn cứ duy nhất để gán trách nhiệm.

Phân biệt tranh chấp phạm vi với thiếu quyền. Nếu cần thay đổi hoặc phê duyệt, phải đến người có thẩm quyền; một kỹ sư nhận ticket không tự có quyền làm mọi thao tác. Nếu cần hợp đồng hoặc nguồn lực đối tác, cần đường quản lý tương ứng, không gửi lại tuyến đầu như thể họ có thể quyết.

Vai trò phân bổ và quyền trong chương trình IT Manager phù hợp ở những điểm vượt khả năng phối hợp của trưởng nhóm. Lãnh đạo cần giải quyết khoảng trống trách nhiệm, không chỉ yêu cầu các bên chủ động hơn mà giữ nguyên điều kiện gây tắc.

Nếu tranh chấp cùng loại lặp, cập nhật danh mục, mô hình trách nhiệm hoặc quy tắc tiếp nhận. Một quyết định tạm giúp xử lý ca hiện tại, nhưng không tự sửa luồng dài hạn. Ghi phần cần cải tiến có người sở hữu để lần sau không phải thương lượng lại từ đầu.

Công cụ cần phản ánh cơ chế, không che sự chưa thống nhất

Quy tắc phân tuyến có thể hỗ trợ theo dịch vụ hoặc loại yêu cầu, nhưng cần kiểm ngoại lệ và cách điều chỉnh. Từ khóa giống nhau có thể xuất hiện ở Incident và yêu cầu cấp mới. Giai đoạn đầu nên đọc các lượt phân sai, cập nhật mẫu và giữ quyền sửa cho người phù hợp.

Trạng thái cần phản ánh việc đang làm hoặc chờ ai. Không nên tạo quá nhiều nhãn nếu không giúp quyết định; cũng không nên dùng một trạng thái đang xử lý cho mọi khoảng chờ. Người điều phối cần thấy phần chưa được nhận, tuổi nhiệm vụ và mốc cập nhật để hành động.

Các trao đổi nhanh phải đưa quyết định trở lại hồ sơ. Khi chuyển ca, người nhận cần biết dữ kiện, giả thuyết và phần đang chờ mà không phải đọc toàn bộ nhóm chat. Bàn giao được chấp nhận là một điểm giao nhận cần kiểm, không chỉ một thông báo đã gửi.

Năng lực tổ chức ca và huấn luyện trong chương trình IT Supervisor giúp giữ cách làm thống nhất. Công cụ có thể nhắc, nhưng người quản lý cần xử lý thiếu đầu mối, thiếu năng lực hoặc hành vi trả việc không có phản hồi dùng được.

Dữ liệu nhạy cảm cần nơi lưu và quyền phù hợp. Không phải mọi nhóm tham gia đều cần đọc toàn bộ tệp người dùng gửi. Có thể giữ bản tóm tắt trên hồ sơ chung và dẫn đến bằng chứng được phân quyền. Phối hợp tốt cần thông tin đủ, không cần thông tin được chia rộng hơn mục đích.

Kiểm tra cơ chế bằng kết quả và những vòng chưa tạo giá trị

Theo dõi thời gian chờ nhận, số lượt trả lại vì thiếu dữ liệu và những vòng chuyển không có thông tin mới. Đọc hồ sơ mẫu để hiểu cơ chế, tránh dùng số đếm để quy lỗi cho nhóm nhận nhiều ca khó. Một nhóm tham gia thêm có thể giúp giải quyết đúng hơn, dù số lượt phối hợp tăng.

Kết quả cần xác nhận theo công việc người dùng. Nếu từng nhóm đều báo phần mình bình thường nhưng giao dịch vẫn không thực hiện được, hồ sơ chưa đủ căn cứ để đóng. Người giữ tiến trình phải nối những kết quả ấy và chọn câu hỏi tiếp, không gửi chúng nguyên văn cho người dùng rồi coi trách nhiệm đã hoàn tất.

Sau sửa giao nhận, thử với ca đủ thông tin, ca thiếu và ca cần nhiều nhóm. Xem người nhận có bắt đầu được, người dùng có được cập nhật và tranh chấp có đường quyết định không. Nếu giảm lượt chuyển bằng cách giữ ticket ở nơi thiếu năng lực, đó không phải cải tiến.

Báo cáo mỗi mẫu sai lệch cùng hành động và người nhận. Có thể sửa câu hỏi đầu vào, cách nhóm dịch vụ hoặc quyền điều phối. Không cần thêm cuộc họp thường trực nếu vấn đề nằm ở một điều kiện nhận việc chưa được viết và thống nhất.

Bước đầu là lấy một ticket đi vòng, dựng lý do từng lần chuyển và chỉ ra nơi không ai giữ bước tiếp. Đặt một quy tắc giao nhận, thử rồi rà bằng kết quả. Phối hợp liên nhóm có giá trị khi chuyên môn được huy động theo câu hỏi rõ, còn người dùng vẫn thấy một dịch vụ liên tục từ tiếp nhận đến việc có thể hoàn thành.