INFOCHIEF ACADEMY · IT MANAGER KNOWLEDGE SERIES

Khi mọi yêu cầu đều khẩn cấp: IT Manager thiết lập cơ chế ưu tiên ra sao?

IT Manager cần cơ chế ưu tiên minh bạch để phân biệt việc thật sự khẩn cấp, bảo vệ nguồn lực và xử lý yêu cầu theo tác động kinh doanh.

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: IT Manager điều phối yêu cầu theo mức độ tác động, rủi ro và thời hạn kinh doanh.

Khi “khẩn cấp” trở thành ngôn ngữ mặc định, hệ thống ưu tiên đã thất bại

Một bộ phận IT không thiếu việc; điều thiếu thường là một cơ chế thống nhất để quyết định việc nào phải làm trước. Khi kinh doanh, tài chính, vận hành và ban lãnh đạo đều gắn nhãn “khẩn cấp” cho yêu cầu của mình, IT Manager dễ rơi vào hai phản ứng cực đoan: xử lý theo người nói lớn nhất hoặc cố phục vụ tất cả cùng lúc. Cả hai đều làm giảm chất lượng điều hành.

Vấn đề không nằm ở thái độ của người gửi yêu cầu. Mỗi phòng ban nhìn rủi ro từ vị trí của mình: bán hàng sợ mất khách, tài chính sợ chậm chốt số, vận hành sợ ngừng dây chuyền, còn bảo mật sợ sự cố lan rộng. Nếu IT không cung cấp một quy tắc chung để so sánh các rủi ro khác nhau, mọi người buộc phải dùng từ “khẩn cấp” như cách giành sự chú ý.

IT Manager cần chuyển câu hỏi từ “ai yêu cầu trước?” sang “nếu trì hoãn yêu cầu này thì doanh nghiệp mất gì, rủi ro gì tăng lên và có thời hạn bắt buộc nào không?”. Đây là nền tảng của quản lý nhu cầu dịch vụ và cũng là kỹ năng cốt lõi trong chương trình Trưởng Phòng IT Chuyên Nghiệp – IT Manager.

Tách nhu cầu thành các luồng thay vì dồn vào một hàng chờ

Không phải mọi công việc đều nên đi qua cùng một cơ chế. Một sự cố làm ngừng hệ thống thanh toán khác bản chất với yêu cầu thêm báo cáo, một lỗ hổng bảo mật nghiêm trọng khác với yêu cầu cấp tài khoản mới, và một dự án chiến lược không thể bị chen ngang vô hạn bởi các việc phát sinh nhỏ.

IT Manager nên thiết kế tối thiểu bốn luồng: sự cố/gián đoạn, yêu cầu dịch vụ tiêu chuẩn, thay đổi/cải tiến và dự án/sáng kiến. Mỗi luồng có tiêu chí tiếp nhận, SLA hoặc mục tiêu thời gian riêng, quyền phê duyệt riêng và giới hạn năng lực riêng. Khi các luồng được tách, “khẩn cấp” không còn là nhãn duy nhất quyết định thứ tự.

Với các yêu cầu dịch vụ có tính lặp lại, tư duy của Quản Lý Dịch Vụ IT – ITSM giúp chuẩn hóa biểu mẫu, mức dịch vụ và tuyến xử lý. Với công việc dự án, nên đưa vào danh mục để so sánh lợi ích, rủi ro, phụ thuộc và năng lực cung ứng thay vì chen vào backlog vận hành.

Xây ma trận ưu tiên dựa trên tác động, thời gian và rủi ro

Một cơ chế ưu tiên tốt không cần quá phức tạp, nhưng phải đủ rõ để hai người khác nhau có thể đi đến kết luận gần giống nhau khi nhìn cùng một yêu cầu. Có thể dùng bốn nhóm tiêu chí: tác động kinh doanh, mức khẩn cấp theo thời gian, rủi ro/tuân thủ và phạm vi người dùng bị ảnh hưởng.

Tiêu chí	Câu hỏi kiểm tra	Ví dụ bằng chứng
Tác động kinh doanh	Yêu cầu ảnh hưởng doanh thu, vận hành hay khách hàng ở mức nào?	Quy trình dừng, đơn hàng tồn, giao dịch thất bại
Thời gian	Có hạn pháp lý, kỳ chốt hoặc cửa sổ nghiệp vụ không?	Kỳ lương, chốt tài chính, chiến dịch bán hàng
Rủi ro	Trì hoãn có làm tăng rủi ro bảo mật, tuân thủ hay liên tục kinh doanh?	Lỗ hổng, lỗi sao lưu, cảnh báo kiểm toán
Phạm vi	Bao nhiêu người, địa điểm hoặc dịch vụ bị ảnh hưởng?	Một cá nhân, một phòng ban, toàn công ty

Điểm số chỉ hỗ trợ quyết định; nó không thay thế phán đoán quản lý. Một sự kiện có điểm thấp nhưng liên quan nghĩa vụ pháp lý vẫn có thể được nâng ưu tiên nếu có bằng chứng rõ ràng. Điều quan trọng là lý do nâng ưu tiên phải được ghi nhận để tránh biến “ngoại lệ” thành thông lệ.

Thiết lập fast-track nhưng phải kiểm soát chi phí của ngoại lệ

Mọi hệ thống ưu tiên đều cần một làn “fast-track” cho tình huống thực sự cần xử lý ngay. Tuy nhiên, nếu không có điều kiện vào làn, người dùng sẽ biến fast-track thành đường mặc định. IT Manager nên yêu cầu ba thông tin trước khi nhận một yêu cầu khẩn: tác động nếu không làm ngay, thời hạn cụ thể và người sở hữu nghiệp vụ xác nhận mức khẩn.

Mỗi yêu cầu fast-track cũng phải để lại “chi phí cơ hội”: việc nào đang làm phải lùi lại, ai chịu ảnh hưởng và rủi ro mới phát sinh là gì. Cách này giúp người yêu cầu thấy rằng ưu tiên không phải là thêm việc vào hệ thống mà là thay đổi thứ tự sử dụng nguồn lực hữu hạn.

Nếu tỷ lệ fast-track tăng liên tục, đó là tín hiệu quản trị chứ không phải thành tích xử lý nhanh. Nguyên nhân có thể là kế hoạch kinh doanh thay đổi muộn, quy trình yêu cầu thiếu dự báo, backlog tồn quá lâu hoặc năng lực IT không tương xứng. IT Manager cần đưa số liệu này vào họp điều hành thay vì chỉ cố “chữa cháy” tốt hơn.

Quy trình ra quyết định năm bước cho các yêu cầu cạnh tranh

Khi có nhiều yêu cầu cạnh tranh, IT Manager có thể dùng một quy trình ngắn năm bước. Bước một là xác nhận yêu cầu và thông tin tối thiểu. Bước hai là phân loại đúng luồng. Bước ba là đánh giá tác động, thời gian, rủi ro và phụ thuộc. Bước bốn là so sánh với công việc đang thực hiện và năng lực còn lại. Bước năm là công bố quyết định cùng lý do và thời điểm xem xét lại.

Chuẩn hóa đầu vào: không chấm ưu tiên từ một câu nhắn chat thiếu bối cảnh.
Phân loại: incident, request, change, improvement hay project.
Chấm tác động: dùng cùng tiêu chí cho mọi phòng ban.
Kiểm tra capacity: xác định việc nào phải dời nếu nhận việc mới.
Truyền thông quyết định: nêu thứ tự, người chịu trách nhiệm và mốc rà soát.

Nếu có thay đổi lớn hoặc dự án cạnh tranh tài nguyên, năng lực trong khóa Quản Lý Dự Án IT giúp trưởng phòng IT lượng hóa phạm vi, phụ thuộc và kế hoạch nguồn lực trước khi chấp nhận cam kết mới.

Tình huống minh họa: bốn yêu cầu cùng đến trong một buổi sáng

Tình huống giả định: 8 giờ sáng, hệ thống báo cáo quản trị chậm; 8 giờ 15, phòng kinh doanh yêu cầu gấp dashboard cho cuộc họp chiều; 8 giờ 30, nhóm bảo mật phát hiện lỗ hổng cần vá; 9 giờ, phòng nhân sự yêu cầu thay đổi dữ liệu phục vụ kỳ lương.

Nếu xử lý theo thứ tự đến, IT có thể dành cả buổi sửa dashboard trong khi lỗ hổng tăng rủi ro hoặc kỳ lương có thời hạn cứng. Nếu xử lý theo người có chức vụ cao nhất, IT sẽ tạo tiền lệ ưu tiên theo quyền lực. Cách tốt hơn là áp dụng cùng tiêu chí: lỗ hổng được xem xét theo mức phơi nhiễm và khả năng khai thác; yêu cầu lương theo deadline bắt buộc; dashboard theo mức ảnh hưởng của cuộc họp; vấn đề báo cáo theo phạm vi người dùng và giải pháp tạm.

Kết quả không nhất thiết là “một việc duy nhất ưu tiên số một”. IT Manager có thể chia nguồn lực theo luồng: một kỹ sư xử lý vá khẩn, một người bảo đảm kỳ lương, dashboard được cung cấp phương án dữ liệu tạm, còn vấn đề hiệu năng đưa vào điều tra sau khi rủi ro cao nhất được kiểm soát. Quản lý ưu tiên là thiết kế quyết định, không phải xếp một hàng đơn tuyến cho mọi loại việc.

Đo sức khỏe cơ chế ưu tiên thay vì đếm số yêu cầu đã đóng

Số ticket đóng không cho biết hệ thống ưu tiên có tốt hay không. Một đội có thể đóng rất nhiều việc nhỏ nhưng để backlog rủi ro cao tồn tại. IT Manager nên theo dõi một số chỉ số như: tỷ lệ yêu cầu phải fast-track, tuổi trung bình của backlog theo mức ưu tiên, tỷ lệ đổi ưu tiên sau khi bắt đầu thực hiện, số lần trễ do phụ thuộc, tỷ lệ công việc bị gián đoạn bởi yêu cầu mới và mức hài lòng của chủ yêu cầu với tính minh bạch của quyết định.

Hãy chú ý đến xu hướng thay vì một con số đơn lẻ. Nếu fast-track tăng trong ba tuần, cần tìm nguyên nhân. Nếu công việc ưu tiên cao thường bị đánh tụt sau khi phân tích, tiêu chí tiếp nhận có thể chưa đủ tốt. Nếu nhiều yêu cầu chờ “thiếu thông tin”, bộ phận IT đang chuyển chi phí sang người dùng mà chưa hỗ trợ họ làm rõ nhu cầu.

Mục tiêu của dashboard ưu tiên không phải chứng minh IT bận. Nó phải giúp trưởng phòng nhận ra nơi hệ thống quyết định đang tạo lãng phí, trì hoãn hoặc rủi ro.

Checklist 30 ngày để đưa cơ chế ưu tiên vào vận hành

Trong 30 ngày đầu, không nên cố xây quy trình quá chi tiết. Hãy tập trung vào một bộ quy tắc dễ hiểu và có thể sử dụng ngay.

Xác định bốn hoặc năm loại công việc chính đang đi vào IT.
Chốt 3–4 tiêu chí ưu tiên dùng chung cho mọi phòng ban.
Quy định điều kiện fast-track và người có quyền xác nhận.
Thiết lập bảng backlog duy nhất hiển thị mức ưu tiên và lý do.
Gắn giới hạn capacity cho vận hành, thay đổi và dự án.
Rà soát ưu tiên ít nhất hàng tuần với các chủ yêu cầu quan trọng.
Đo tỷ lệ ngoại lệ, tuổi backlog và mức đổi ưu tiên.
Sau một tháng, điều chỉnh tiêu chí dựa trên các quyết định gây tranh cãi thực tế.

Hành động nên bắt đầu: chọn 20 yêu cầu gần nhất và thử chấm lại theo cùng một ma trận. Những trường hợp mà đội ngũ cho điểm rất khác nhau chính là nơi quy tắc ưu tiên cần được làm rõ trước tiên.

Điểm kết thúc không phải là “xếp hạng đúng”, mà là tạo niềm tin vào quyết định

Cơ chế ưu tiên trưởng thành khi các phòng ban không còn phải vận động riêng để được chú ý. Họ biết yêu cầu sẽ được đánh giá theo tiêu chí nào, khi nào có kết quả và nếu không được làm ngay thì lý do là gì. Sự minh bạch này quan trọng không kém thuật toán chấm điểm.

IT Manager cũng cần chấp nhận rằng một số quyết định sẽ không làm tất cả hài lòng. Vai trò quản lý không phải tối đa hóa sự hài lòng tức thời mà là sử dụng nguồn lực hữu hạn theo cách bảo vệ tốt nhất mục tiêu chung. Vì vậy, hãy ghi lại các quyết định gây tranh cãi, xem lại sau một thời gian và kiểm chứng giả định ban đầu. Nếu một loại yêu cầu thường bị đánh giá sai, hãy sửa tiêu chí; nếu một phòng ban liên tục gửi việc quá muộn, hãy xử lý cơ chế lập kế hoạch với họ.

Một hệ thống ưu tiên tốt cuối cùng phải tạo ra ba kết quả: giảm số ngoại lệ, tăng khả năng dự báo và giúp đội IT tập trung lâu hơn vào công việc có giá trị. Khi đạt được điều đó, từ “khẩn cấp” trở lại đúng nghĩa của nó — chỉ dành cho những việc thực sự cần được xử lý khác với nhịp bình thường.

Nguồn tham khảo

Các nguồn trên được dùng làm tài liệu tham khảo cho nguyên tắc quản trị và quản lý. Nội dung bài viết là diễn giải ứng dụng của Infochief Academy cho bối cảnh điều hành bộ phận IT.