INFOCHIEF ACADEMY · IT MANAGER KNOWLEDGE SERIES

Bộ phận IT quá tải nhưng không được thêm người: Trưởng phòng nên bắt đầu từ đâu?

Khi ticket tăng, dự án dồn dập, người dùng liên tục nhắc việc nhưng yêu cầu bổ sung biên chế chưa được chấp thuận, phản xạ dễ thấy nhất là “làm nhanh hơn”. Vấn đề là một đội ngũ đã quá tải thường không thiếu nỗ lực; họ thiếu cơ chế để nhìn rõ nhu cầu, giới hạn công việc đang làm, bảo vệ năng lực cho việc quan trọng và dừng những việc không còn tạo đủ giá trị. Bài viết này đưa ra một cách tiếp cận để IT Manager phục hồi hiệu suất trước khi nghĩ đến tuyển thêm người.

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 rà soát nhu cầu, mức ưu tiên và năng lực đội ngũ trước khi quyết định cách xử lý quá tải.

Quá tải không đồng nghĩa với thiếu người: trước hết phải nhìn đúng hệ thống công việc

Một bộ phận IT có thể cảm thấy “thiếu người” trong nhiều tháng dù số lượng nhân sự không thay đổi. Nguyên nhân thường không nằm ở một biến số duy nhất. Nhu cầu có thể tăng nhanh hơn năng lực; quá nhiều dự án được khởi động cùng lúc; các yêu cầu nhỏ chen ngang công việc chính; nhân sự có kỹ năng quan trọng bị kéo vào mọi sự cố; hoặc nhóm phải duy trì quá nhiều hệ thống cũ. Nếu trưởng phòng chỉ nhìn tổng số ticket hay số giờ làm thêm, rất khó biết nên can thiệp ở đâu.

Điểm xuất phát hữu ích hơn là xem bộ phận IT như một hệ thống có nhu cầu đầu vào, năng lực xử lý, công việc đang thực hiện và kết quả đầu ra. Quá tải xảy ra khi lượng công việc cam kết vượt quá năng lực thực tế trong một thời gian đủ dài. Khi đó, tăng tốc từng cá nhân chỉ tạo thêm chuyển ngữ cảnh, lỗi, làm lại và thời gian chờ giữa các nhóm. Người giỏi nhất càng dễ trở thành nút thắt vì họ được gọi vào mọi vấn đề.

Vì vậy, IT Manager cần tách câu hỏi “có cần thêm người không?” khỏi câu hỏi “hệ thống công việc hiện tại có đang được quản lý đúng không?”. Chương trình Trưởng Phòng IT Chuyên Nghiệp – IT Manager của Infochief nhấn mạnh năng lực điều hành bộ phận theo mục tiêu, nguồn lực và kết quả; đây cũng là tư duy cốt lõi khi xử lý tình trạng quá tải.

Đo nhu cầu và năng lực theo bốn dòng công việc thay vì một con số tổng

Hãy lập một bức tranh tối thiểu trong hai đến bốn tuần. Không cần công cụ phức tạp; điều quan trọng là phân loại nhất quán. Một mô hình thực dụng là chia nhu cầu thành bốn dòng: vận hành bắt buộc, yêu cầu người dùng, thay đổi/dự án và cải tiến/rủi ro. Mỗi dòng có tính chất khác nhau nên không thể gom thành một “backlog” duy nhất rồi xếp hàng theo người gọi lớn tiếng nhất.

Dòng công việc	Ví dụ	Câu hỏi quản lý
Vận hành bắt buộc	Giám sát, sao lưu, vá lỗi, kiểm tra định kỳ	Việc nào phải làm để giữ dịch vụ an toàn và ổn định?
Yêu cầu & hỗ trợ	Ticket, cấp quyền, xử lý sự cố, service request	Nhu cầu nào có thể chuẩn hóa, tự phục vụ hoặc phân tuyến?
Thay đổi & dự án	Nâng cấp, tích hợp, triển khai hệ thống mới	Dự án nào thực sự cần bắt đầu ngay và ai sở hữu kết quả?
Cải tiến & rủi ro	Tự động hóa, xử lý nợ kỹ thuật, DR, bảo mật	Nếu luôn trì hoãn dòng này, rủi ro nào sẽ tích tụ?

Tiếp theo, đo năng lực theo vai trò và kỹ năng, không chỉ theo số đầu người. Một nhóm tám người không có nghĩa là có tám người thay thế lẫn nhau. Có thể chỉ một người đủ năng lực quản trị firewall, một người hiểu sâu ERP và hai người có thể triển khai tự động hóa. SFIA mô tả năng lực theo kỹ năng cùng mức trách nhiệm, nhắc IT Manager rằng hiệu suất đội ngũ phụ thuộc cả chuyên môn lẫn mức tự chủ, ảnh hưởng và độ phức tạp công việc.

Trong vận hành dịch vụ, tư duy của Quản Lý Dịch Vụ IT – ITSM cũng hữu ích: thay vì chỉ đếm ticket, hãy nhìn nhu cầu, luồng giá trị, chất lượng dịch vụ và khả năng cải tiến liên tục.

Giới hạn công việc đang làm: biện pháp nhanh nhất để giảm “bận nhưng không xong”

Một đội quá tải thường có quá nhiều việc ở trạng thái “đang làm”. Mỗi nhân viên mở nhiều ticket, dự án có nhiều hạng mục song song, họp chen vào giữa ngày, sự cố làm gián đoạn kế hoạch. Kết quả là công việc nằm chờ, chuyển giao nhiều lần và khó kết thúc. Vì vậy, trước khi tìm cách tăng công suất, hãy giảm lượng công việc đang mở.

IT Manager có thể đặt giới hạn WIP ở ba cấp. Cấp cá nhân: mỗi người chỉ có một số lượng công việc chính đang xử lý. Cấp nhóm: chỉ một số thay đổi hoặc dự án được phép ở trạng thái thực thi. Cấp bộ phận: các sáng kiến mới phải chờ cho đến khi có năng lực được giải phóng. Quy tắc này cần đi kèm một “hàng chờ minh bạch” để người yêu cầu biết việc của họ đang ở đâu và vì sao chưa bắt đầu.

Giới hạn WIP không có nghĩa là từ chối hỗ trợ khẩn cấp. Nhóm cần một làn riêng cho sự cố nghiêm trọng, nhưng điều kiện để đi vào làn đó phải rõ: mức ảnh hưởng, số người dùng bị tác động, dịch vụ trọng yếu và mức rủi ro. Khi mọi yêu cầu đều có thể tự gắn nhãn “khẩn cấp”, cơ chế ưu tiên đã mất tác dụng.

Một cách kiểm tra đơn giản: chọn 20 công việc đang mở và hỏi “Nếu chỉ được hoàn thành 10 việc trong hai tuần tới, 10 việc nào tạo hoặc bảo vệ nhiều giá trị nhất?”. Câu hỏi này buộc quản lý phải ra quyết định, thay vì phân tán nguồn lực để giữ tất cả công việc ở trạng thái nửa hoàn thành.

Thiết lập cơ chế ưu tiên để loại “khẩn cấp giả” và bảo vệ việc quan trọng

Ưu tiên không nên dựa trên chức danh người yêu cầu hay thời điểm gửi email. Một cơ chế đủ đơn giản có thể dùng bốn tiêu chí: tác động kinh doanh, rủi ro nếu trì hoãn, mức độ phụ thuộc và thời hạn thực tế. Mỗi yêu cầu được đánh giá theo cùng một cách, sau đó IT Manager trao đổi với chủ sở hữu nghiệp vụ khi có xung đột.

Tiêu chí	Câu hỏi	Dấu hiệu ưu tiên cao
Tác động kinh doanh	Việc này ảnh hưởng doanh thu, khách hàng hoặc vận hành nào?	Dịch vụ trọng yếu hoặc nhiều người dùng bị ảnh hưởng
Rủi ro trì hoãn	Nếu chậm 1–2 tuần, hậu quả là gì?	An toàn, tuân thủ, mất dữ liệu, gián đoạn nghiêm trọng
Phụ thuộc	Việc nào khác đang chờ kết quả này?	Đây là nút mở khóa cho nhiều đầu việc quan trọng
Thời hạn	Deadline là cam kết thật hay mong muốn?	Có ngày pháp lý, hợp đồng hoặc sự kiện kinh doanh rõ

Khi nhu cầu vượt khả năng, trưởng phòng không nên âm thầm “cố cân”. Hãy công khai trade-off: nếu dự án A được đưa lên, việc B phải lùi; nếu SLA cho nhóm này tăng, năng lực cho hoạt động khác giảm. Cơ chế này biến vấn đề quá tải từ chuyện nội bộ IT thành một quyết định phân bổ giá trị và rủi ro có sự tham gia của các bên liên quan.

Tìm nút thắt năng lực trước khi phân lại việc hoặc đào tạo

Không phải mọi người đều quá tải giống nhau. Một nhóm có thể thiếu thời gian của chuyên gia cơ sở dữ liệu nhưng lại dư năng lực ở một số tác vụ hỗ trợ cơ bản. Hãy lập “bản đồ nút thắt”: kỹ năng nào chỉ một người có, hoạt động nào cần phê duyệt của một vai trò, bước nào tạo hàng chờ dài nhất và việc nào thường quay lại vì chất lượng kém.

Từ đó, IT Manager có bốn lựa chọn trước khi xin thêm biên chế. Thứ nhất, chuyển giao kiến thức để giảm phụ thuộc cá nhân. Thứ hai, chuẩn hóa checklist và runbook để người ở mức năng lực thấp hơn xử lý được các trường hợp lặp lại. Thứ ba, tự động hóa tác vụ khối lượng lớn nhưng ít biến động. Thứ tư, điều chỉnh phạm vi dịch vụ hoặc cam kết để phù hợp với năng lực thực tế.

Những năng lực giám sát, giao việc và phản hồi trong chương trình Quản Lý Giám Sát IT – IT Supervisor đặc biệt hữu ích khi trưởng phòng muốn đẩy quyền xử lý xuống tuyến dưới mà vẫn giữ kiểm soát. Với bài toán năng lực hạ tầng và hiệu suất, chuyên đề Quản Lý Năng Lực & Hiệu Suất IT là một liên kết thực tế để chuyển từ phản ứng sang dự báo.

Kế hoạch phục hồi 30 ngày khi chưa thể tăng người

Mục tiêu của 30 ngày đầu không phải giải quyết hết backlog. Mục tiêu là lấy lại quyền kiểm soát dòng công việc và tạo bằng chứng cho quyết định tiếp theo.

Tuần 1 – Nhìn thấy sự thật: thống kê nhu cầu, công việc đang mở, năng lực theo kỹ năng, các cam kết bắt buộc và 10 nguồn gián đoạn lớn nhất.
Tuần 2 – Cắt giảm và xếp lại: dừng hoặc hoãn việc giá trị thấp, đóng các ticket không còn hợp lệ, giới hạn WIP và xác định cơ chế ưu tiên.
Tuần 3 – Gỡ nút thắt: phân tuyến yêu cầu, viết runbook cho tác vụ lặp lại, chuyển giao kiến thức và tự động hóa một số bước có khối lượng cao.
Tuần 4 – Chốt mô hình điều hành: thống nhất chỉ số tải, SLA thực tế, lịch rà soát backlog, trách nhiệm quyết định và báo cáo trade-off với lãnh đạo.

Trong giai đoạn này, không nên mở một chương trình cải tiến quá lớn. Một vài thay đổi nhỏ nhưng giảm được chuyển ngữ cảnh, chờ đợi hoặc làm lại thường có tác động nhanh hơn. Chuyên đề Quản Lý Bộ Phận – Phòng Ban IT có thể hỗ trợ trưởng phòng chuẩn hóa cơ cấu điều hành, KPI và trách nhiệm khi cần đưa các thay đổi này thành cách làm ổn định.

Tình huống minh họa: đội tám người nhưng “ai cũng thiếu thời gian”

Tình huống giả định: một bộ phận IT tám người quản lý hạ tầng, hỗ trợ người dùng và ba dự án nội bộ. Mỗi tuần nhóm nhận nhiều yêu cầu mới; trưởng phòng phân việc theo người rảnh nhất và hầu như không từ chối yêu cầu nào. Sau vài tháng, backlog tăng, dự án trễ và chuyên gia hệ thống phải tham gia gần như mọi vấn đề khó.

Thay vì đề xuất tuyển ngay hai người, trưởng phòng tiến hành rà soát bốn tuần. Kết quả cho thấy nhiều công việc đang mở nhưng chưa có tiêu chí hoàn thành, một số yêu cầu lặp lại có thể hướng dẫn tự phục vụ, ba dự án cạnh tranh cùng một chuyên gia và lịch họp chiếm nhiều khung thời gian sâu cần cho xử lý kỹ thuật. Nhóm quyết định đóng các yêu cầu không còn nhu cầu, giới hạn số dự án đang chạy, tạo runbook cho tác vụ cấp quyền phổ biến và bố trí một vòng hỗ trợ tuyến đầu để bảo vệ thời gian của chuyên gia.

Kết quả kỳ vọng không nhất thiết là “làm được nhiều hơn ngay lập tức”. Dấu hiệu phục hồi tốt hơn là công việc quan trọng hoàn thành đều hơn, thời gian chờ giảm, sự cố ít phải chuyển cấp và trưởng phòng có dữ liệu rõ để giải thích phần nhu cầu nào vẫn vượt năng lực. Nếu sau khi đã tối ưu dòng công việc mà chênh lệch vẫn kéo dài, khi đó đề xuất bổ sung nhân sự có cơ sở mạnh hơn vì nó gắn với năng lực thiếu hụt cụ thể thay vì cảm nhận.

Checklist hằng tuần: trưởng phòng cần kiểm tra gì để tránh quá tải quay lại?

Số lượng công việc đang mở có vượt giới hạn đã đặt không?
Những yêu cầu mới nào thực sự thay đổi mức ưu tiên của tuần?
Có đầu việc nào chờ một kỹ năng hoặc một người quá lâu không?
Dự án nào đang tiêu tốn nguồn lực nhưng chưa tạo tiến triển có thể kiểm chứng?
Có ticket lặp lại nào cần problem management, runbook hoặc tự động hóa?
Nhóm có đủ thời gian cho bảo trì phòng ngừa, rủi ro và cải tiến không?
Cam kết với phòng ban có phản ánh năng lực thật hay chỉ là mong muốn?
Trade-off nào cần đưa lên CIO hoặc Ban điều hành thay vì để IT tự gánh?

Hành động nên bắt đầu: trong tuần này, hãy chọn một bảng công việc duy nhất, phân loại toàn bộ đầu việc theo bốn dòng nhu cầu, giới hạn số việc “đang làm” và xác định ba công việc có thể dừng hoặc hoãn. Đây là cách nhanh nhất để chuyển từ trạng thái phản ứng sang điều hành có chủ đích.

Khi chưa được thêm người, IT Manager vẫn có thể cải thiện đáng kể bằng cách quản lý nhu cầu, WIP, nút thắt và quyết định ưu tiên. Nhưng mục tiêu không phải ép đội ngũ “chịu được nhiều hơn”; mục tiêu là xây một hệ thống công việc mà nguồn lực hiện có được dùng vào những kết quả quan trọng nhất và sự quá tải được nhìn thấy sớm, có dữ liệu, có người quyết định.

Nguồn tham khảo

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