Phân loại Incident và Service Request: Cách tránh sai lệch trong xử lý ticket.

Phân biệt mục tiêu khôi phục với mục tiêu cung cấp

Incident thường chỉ gián đoạn ngoài kế hoạch hoặc suy giảm chất lượng dịch vụ. Mục tiêu xử lý là khôi phục trong phạm vi phù hợp. Service Request thường là nhu cầu dịch vụ được người dùng hoặc đại diện có thẩm quyền khởi tạo, như cung cấp thông tin, quyền hoặc thiết bị theo cách đã xác định.

Không phải mọi service request đều tự được phép thực hiện. Danh mục yêu cầu cần nêu điều kiện, người phê duyệt và đầu ra. Ngược lại, incident có thể cần thay đổi để phục hồi, nhưng mục tiêu khôi phục không tự cấp quyền thay đổi mọi cấu hình.

Đừng phân loại theo thời gian xử lý. Một incident đơn giản vẫn là incident; một yêu cầu thiết bị mất nhiều bước vẫn là request. Cũng không nên coi yêu cầu của lãnh đạo là một loại riêng chỉ để đi đường nhanh mà thiếu phê duyệt hoặc dữ liệu.

Nền tảng quản lý dịch vụ IT giúp giữ sự khác biệt này trong quy trình. Luồng cần phục vụ mục tiêu và trách nhiệm, không chỉ tên loại ticket trong phần mềm.

Dùng câu hỏi để xác định trạng thái trước và nhu cầu hiện tại

Hỏi người dùng trước đây có sử dụng được không, điều gì thay đổi và kết quả cần đạt là gì. Nếu một chức năng đang được cung cấp bỗng ngừng, đó là đầu mối incident. Nếu cần một khả năng mới, có thể là request hoặc nhu cầu khác cần đánh giá theo phạm vi tổ chức.

Cần xem quyền hợp lệ. Một người không có quyền truy cập không nhất thiết đang gặp incident của hệ thống. Tuy nhiên, quyền đã được phê duyệt nhưng bị thu hồi sai có thể là gián đoạn đối với dịch vụ họ được phép dùng. Hồ sơ và xác minh giúp phân biệt hai trường hợp.

Khi chưa rõ, giữ phân loại ban đầu với người xác minh và mốc tiếp theo. Không ép người dùng tự chọn thuật ngữ đúng trước khi được hỗ trợ. Tuyến đầu có trách nhiệm giải thích nhu cầu thành dữ liệu để chọn luồng, đồng thời cập nhật phân loại khi có bằng chứng mới.

Người hỗ trợ IT Helpdesk cần sử dụng các câu hỏi này linh hoạt. Bảng là hướng dẫn minh họa, không thay thế bằng chứng của ca cụ thể hoặc cách phân loại đã được doanh nghiệp thống nhất.

Thiết kế danh mục và luồng đủ rõ để tránh đoán

Danh mục request nên mô tả người đủ điều kiện, đầu vào, phê duyệt, người thực hiện và kết quả. Với cấp quyền, cần vai trò cùng thời hạn nếu có. Với thiết bị, cần điều kiện cấp và nhận. Những thông tin này giúp nhân viên không phải hỏi lại từ đầu ở mọi ca.

Incident cần nhóm dịch vụ, biểu hiện, tác động và ưu tiên. Phân loại thành phần hỗ trợ điều tra nhưng không nên quá sâu trước khi có dữ liệu. Một danh mục lỗi quá nhiều lựa chọn dễ khiến tuyến đầu chọn theo thói quen, rồi nhóm nhận lại sửa.

Không phải mọi nhu cầu đều nằm gọn trong hai nhóm. Một đề xuất chức năng chưa có có thể cần đánh giá nhu cầu hoặc thay đổi; một biểu hiện bảo mật cần chuyển cơ chế ứng phó phù hợp; câu hỏi thông tin có thể là request theo danh mục. Không nên dùng Incident hoặc Service Request như hai thùng chứa bắt buộc cho mọi thứ.

Khi request cần thay đổi kỹ thuật, có thể liên kết hồ sơ thay đổi thay vì tạo phê duyệt ngầm. Khi incident cần điều tra nguyên nhân dài hơn sau phục hồi, phần đó có trách nhiệm riêng. Ticket tiếp nhận vẫn giữ lịch sử và kết quả với người dùng.

Ưu tiên và bảo mật vẫn cần được đánh giá riêng

Loại ticket không tự quyết mức ưu tiên. Incident ảnh hưởng nhỏ có thể chờ trong phạm vi cam kết; request theo một mốc nghiệp vụ quan trọng có thể cần xử lý sớm khi đủ điều kiện. Cần tiêu chí phù hợp từng luồng và nguồn lực thực hiện.

Với yêu cầu quyền hoặc dữ liệu, giữ xác minh danh tính và phê duyệt theo quản trị an toàn thông tin. Đổi nhãn từ request sang incident không được dùng để bỏ kiểm soát. Khôi phục quyền cũng cần xác nhận quyền hợp lệ trước đó và phạm vi được phép.

Nếu có dấu hiệu tài khoản bị chiếm quyền hoặc dữ liệu bị tác động, ưu tiên chuyển cơ chế xử lý bảo mật theo tổ chức. Helpdesk không nên tiếp tục các thao tác thông thường có thể làm mất bằng chứng. Phân loại và đường chuyển phải giúp bảo vệ dịch vụ, không tạo trì hoãn vì tranh luận tên loại.

Tình huống giả định: nhân viên mới và nhân viên đang làm việc

Giả sử hai người cùng báo không vào được ứng dụng. Người thứ nhất mới gia nhập, chưa có phê duyệt quyền. Người thứ hai có quyền hợp lệ và hôm qua vẫn làm việc được. Đây là ví dụ minh họa, không phải quy tắc kết luận chỉ từ tình trạng nhân sự.

Với người thứ nhất, tuyến đầu ghi nhu cầu và đưa qua luồng cấp quyền có phê duyệt. Thời hạn công việc được xác nhận để đánh giá khẩn cấp trong cơ chế request. Nếu một quyền tạm được cho phép, phạm vi và thời hạn phải rõ, không tự cấp rộng để người dùng thử.

Với người thứ hai, đội xác minh hiện tượng, phạm vi và dữ liệu quyền rồi xử lý khôi phục. Có thể quyền bị đổi, dịch vụ định danh lỗi hoặc ứng dụng có vấn đề. Việc từng sử dụng được là một đầu mối, chưa chứng minh cơ chế gây lỗi.

Nếu phát hiện cả nhiều người có quyền hợp lệ cùng lỗi, các incident được liên kết với sự cố chung. Request của nhân viên mới không nên gộp thành đã giải quyết chỉ vì sự cố chung kết thúc; nhu cầu cấp quyền của họ vẫn phải hoàn tất theo điều kiện riêng.

Ngược lại, khi thực hiện request mà phát hiện lỗi nền tảng, cần liên kết nhánh incident. Một ticket có thể liên quan nhiều hồ sơ, nhưng mục tiêu và trạng thái phải giữ rõ. Không nên đổi qua lại loại rồi mất lịch sử về việc đã được phê duyệt hoặc phần đang chờ.

Khi một yêu cầu đến với tên loại do người dùng tự chọn, nhân viên không nên đổi nhãn mà không giải thích đường xử lý. Có thể xác nhận nhu cầu rồi nói rõ vì sao cần phê duyệt hoặc điều tra khôi phục. Việc phân loại là trách nhiệm dịch vụ; người dùng không cần biết đúng thuật ngữ để nhận hỗ trợ. Đồng thời, công cụ nên giữ câu mô tả ban đầu để nhóm phía sau hiểu bối cảnh và không nhầm rằng người dùng đã chủ động yêu cầu một quyền ngoài nhu cầu thật.

Rà sai lệch phân loại bằng dữ liệu và mẫu ticket

Theo dõi ticket đổi loại, chuyển nhóm nhiều lần, thiếu phê duyệt và kết quả không phù hợp mục tiêu. Những dữ liệu này giúp xác định danh mục hoặc câu hỏi cần sửa. Không nên đánh giá chỉ bằng tỷ lệ phân loại đúng nếu tiêu chí chưa được thống nhất giữa các nhóm.

Năng lực giám sát đội IT hỗ trợ rà mẫu và huấn luyện theo tình huống. Người giám sát có thể yêu cầu nhân viên giải thích căn cứ phân loại, rồi đối chiếu với bằng chứng sau xử lý. Mục tiêu là cải thiện cách quyết định, không bắt thuộc tên loại.

Báo cáo cần tách thời gian và kết quả của hai luồng theo định nghĩa. Trộn request chờ phê duyệt với incident đang gián đoạn có thể làm số liệu khó đọc. Nhưng tách cũng không nên che tổng thời gian người dùng chờ; cả thời gian dịch vụ và thời gian các bước cần được nhìn phù hợp.

Một vòng cải thiện có thể bắt đầu với các ticket truy cập, phần mềm và thiết bị thường bị nhầm. Rà nhu cầu, trạng thái trước, quyền và mục tiêu, rồi cập nhật danh mục cùng vài câu hỏi phân biệt. Thử trên ca mới và xem số lần hỏi lại hoặc chuyển sai có giảm không.

Cũng cần giữ lịch sử khi đổi loại. Ghi căn cứ mới, người quyết định và tác động đến luồng, thay vì xóa phân loại cũ để báo cáo sạch hơn. Dữ liệu đó giúp tổ chức biết vì sao quyết định ban đầu chưa đủ và điều gì cần cải thiện tại tiếp nhận.

Phân loại tốt làm yêu cầu đi vào đúng cơ chế từ sớm, giữ quyền và phê duyệt ở nơi cần thiết, đồng thời tạo số liệu có nghĩa. Khi Incident và Service Request được phân biệt theo mục tiêu thật, đội hỗ trợ vừa phục hồi dịch vụ hiệu quả hơn vừa cung cấp nhu cầu mới có trách nhiệm.

Bài viết liên quan

• Xây dựng quy trình tiếp nhận và xử lý yêu cầu người dùng theo tiêu chuẩn dịch vụ.
• Thiết lập mức độ ưu tiên ticket dựa trên tác động và mức độ khẩn cấp.
• Quản lý vòng đời ticket: Từ tiếp nhận đến xác nhận hoàn tất và đóng yêu cầu.
• Áp dụng SLA trong hoạt động Service Desk: Cam kết thời gian và kiểm soát chất lượng.

Nguồn tham khảo

1. PeopleCert — ITIL 4 Practitioner: Incident Management
2. PeopleCert — ITIL 4 Practitioner: Service Request Management
3. Atlassian — Service Request Management