INFOCHIEF ACADEMY · IT MANAGER KNOWLEDGE SERIES

Quản trị nguồn lực IT: Làm thế nào để cân đối công việc thường xuyên và các dự án mới?

Một đội IT có thể làm việc hết công suất nhưng vẫn liên tục trễ dự án, quá tải khi có sự cố và không tạo được thời gian cho cải tiến. Nguyên nhân thường không nằm ở việc “thiếu người” đơn thuần mà ở cách nhu cầu được đưa vào hàng đợi, cách năng lực được ước lượng và cách trưởng phòng bảo vệ những ưu tiên thực sự quan trọng. Bài viết này trình bày cách biến quản trị nguồn lực từ lịch làm việc cá nhân thành một cơ chế điều hành danh mục công việc.

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: phân bổ năng lực đội IT giữa hoạt động vận hành, cải tiến và danh mục dự án.

Khi công việc thường xuyên luôn thắng dự án mới

Bộ phận IT sống trong hai thế giới cùng lúc. Một bên là công việc phải làm để doanh nghiệp tiếp tục vận hành: xử lý sự cố, hỗ trợ người dùng, vá lỗi, sao lưu, kiểm tra an toàn, quản lý tài khoản và các hoạt động định kỳ. Bên kia là các sáng kiến thay đổi: triển khai ERP, nâng cấp hạ tầng, tự động hóa, di chuyển cloud hoặc đáp ứng một yêu cầu kinh doanh mới. Nếu hai loại nhu cầu này dùng chung một “bể nguồn lực” nhưng không có nguyên tắc phân bổ, công việc khẩn cấp sẽ liên tục chen ngang và dự án chỉ tiến khi đội ngũ còn thời gian thừa.

Điều nguy hiểm là trưởng phòng thường nhìn quá tải ở cấp cá nhân: ai đang bận, ai còn trống. Trong khi vấn đề thật sự nằm ở cấp danh mục: có bao nhiêu năng lực đang bị khóa vào vận hành bắt buộc, bao nhiêu dành cho thay đổi đã cam kết, bao nhiêu cần giữ cho rủi ro phát sinh và bao nhiêu nên dành cho cải tiến chủ động. Cách nhìn này giúp IT Manager chuyển từ “xếp lịch người” sang quản trị năng lực như một nguồn lực hữu hạn có giá trị kinh doanh.

Bước đầu tiên là ngừng giả định 100% thời gian làm việc của nhân viên có thể phân bổ cho task. Họ còn họp, phối hợp, trực hỗ trợ, xử lý ngoại lệ, học hệ thống và chuyển đổi ngữ cảnh. Một kế hoạch đẹp trên bảng tính nhưng sử dụng 100% capacity thường là kế hoạch không có khả năng hấp thụ biến động.

Lập bản đồ nhu cầu trước khi nói đến thiếu người

Hãy gom toàn bộ nhu cầu IT vào bốn nhóm: Run – duy trì dịch vụ hiện tại; Change – dự án hoặc thay đổi đã được phê duyệt; Improve – cải tiến chủ động để giảm lỗi, tự động hóa hoặc nâng năng suất; Unplanned – sự cố và yêu cầu ngoài kế hoạch. Với mỗi nhóm, IT Manager cần biết khối lượng, thời hạn, mức độ bắt buộc và hệ quả nếu trì hoãn. Chỉ khi nhìn thấy toàn bộ bức tranh mới có thể tranh luận một cách có cơ sở về việc cần thêm người, giảm phạm vi hay dời thời điểm.

Một sai lầm phổ biến là mọi yêu cầu đều được gọi là “ưu tiên cao”. Khi đó ưu tiên mất ý nghĩa. Thay vì hỏi ai yêu cầu lớn tiếng hơn, hãy dùng cùng một bộ tiêu chí: tác động kinh doanh, rủi ro, nghĩa vụ tuân thủ, cam kết với khách hàng, chi phí trì hoãn và mức phụ thuộc. Các yêu cầu chưa đủ dữ liệu không nên được đưa thẳng vào kế hoạch thực thi; chúng cần đi qua bước làm rõ để tránh chiếm capacity bằng những công việc mơ hồ.

Với các bộ phận đã có quy trình dịch vụ, tư duy của chương trình Quản Lý Dịch Vụ IT – ITSM giúp tách rõ nhu cầu vận hành dịch vụ và nhu cầu thay đổi. Còn khi danh mục dự án chiếm tỷ trọng lớn, năng lực trong khóa Giám Đốc Dự Án IT – Project Manager hỗ trợ xác định phạm vi, nguồn lực và phụ thuộc trước khi cam kết.

Đo capacity theo năng lực, không chỉ theo số người

Hai kỹ sư cùng chức danh không đồng nghĩa có cùng capacity cho mọi loại công việc. Một người có thể xử lý hệ thống mạng nhưng chưa đủ năng lực quản trị cơ sở dữ liệu; một người hiểu sâu ERP nhưng không thể thay thế trực vận hành 24/7. Vì vậy bản đồ nguồn lực nên thể hiện ít nhất ba lớp: thời gian khả dụng, năng lực chuyên môn và mức độ có thể thay thế. Đây là lý do các đội nhỏ thường có vẻ “đủ headcount” nhưng vẫn nghẽn ở một vài kỹ năng then chốt.

IT Manager nên xác định năng lực nền tối thiểu để bảo vệ các dịch vụ trọng yếu. Sau đó mới phân bổ phần còn lại cho dự án. Những vị trí đơn điểm thất bại về con người — chỉ một người biết hệ thống, một người có quyền quản trị hoặc một người hiểu tích hợp — cần được nhìn như rủi ro, không phải như một cách tiết kiệm biên chế. Kế hoạch nguồn lực tốt luôn đi kèm kế hoạch cross-training, tài liệu hóa và phân quyền phù hợp.

Khóa Quản Lý Đội Ngũ Nhân Viên IT có thể được dùng như một liên kết thực hành cho phần phân công, đánh giá năng lực và phát triển đội ngũ; còn Quản Lý Năng Lực & Hiệu Suất IT phù hợp với góc nhìn dự báo nhu cầu và tối ưu năng lực hạ tầng/dịch vụ.

Thiết kế “ngân sách capacity” cho Run, Change và Improve

Không có một tỷ lệ vàng áp dụng cho mọi doanh nghiệp. Tuy nhiên, việc đặt một khung phân bổ ban đầu giúp đội ngũ tránh bị hút hoàn toàn vào việc chữa cháy. Trưởng phòng có thể bắt đầu bằng cách xác định phần capacity bắt buộc cho vận hành và hỗ trợ; phần dành cho các dự án đã cam kết; một quỹ cải tiến nhằm giảm nợ vận hành; và một vùng đệm cho sự cố hoặc yêu cầu không dự báo được. Tỷ lệ được điều chỉnh theo mùa vụ, độ ổn định của dịch vụ và giai đoạn của danh mục dự án.

Điểm quan trọng là vùng đệm không phải “thời gian rảnh”. Nó là bảo hiểm năng lực. Nếu tháng đó ít sự cố, phần dư có thể được kéo sang cải tiến backlog. Nếu sự cố tăng, đội vẫn không phải phá vỡ toàn bộ kế hoạch dự án. Cách làm này tạo một cơ chế hấp thụ biến động thay vì để mỗi biến động trở thành một cuộc thương lượng khẩn cấp.

Nhóm capacity	Mục đích	Câu hỏi kiểm soát
Run	Duy trì dịch vụ, hỗ trợ, bảo trì bắt buộc	Nếu giảm, dịch vụ nào chịu rủi ro?
Change	Dự án và thay đổi đã cam kết	Ưu tiên có được phê duyệt và có sponsor?
Improve	Tự động hóa, giảm lỗi, xử lý nợ vận hành	Cải tiến này giảm workload hoặc rủi ro nào?
Buffer	Sự cố và nhu cầu ngoài dự kiến	Mức biến động lịch sử là bao nhiêu?

Giới hạn công việc đang làm để bảo vệ tiến độ

Một đội ngũ bị chia thành quá nhiều đầu việc thường có cảm giác rất bận nhưng throughput lại thấp. Mỗi lần chuyển từ sự cố sang dự án, rồi sang họp, rồi quay lại cấu hình, nhân viên mất thời gian khôi phục bối cảnh và chất lượng quyết định giảm. Vì vậy IT Manager nên đặt giới hạn Work in Progress ở cấp nhóm hoặc năng lực chuyên môn. Khi giới hạn đã đầy, một yêu cầu mới chỉ được bắt đầu nếu có công việc khác hoàn tất hoặc được chủ động dừng/hoãn.

Giới hạn WIP còn tạo kỷ luật cho bên yêu cầu. Thay vì IT nhận tất cả rồi trễ tất cả, lãnh đạo phải nhìn thấy trade-off: muốn đưa một việc mới vào thì việc nào sẽ ra khỏi hàng ưu tiên. Đây là một thay đổi quan trọng trong quan hệ giữa IT và doanh nghiệp. Nó biến “IT không đủ người” thành cuộc đối thoại về lựa chọn, chi phí trì hoãn và mức ưu tiên.

Đối với trưởng phòng, năng lực quản lý công việc và kết quả này là phần cốt lõi của chương trình Trưởng Phòng IT Chuyên Nghiệp – IT Manager: không chỉ theo dõi ai làm gì, mà kiểm soát dòng công việc để kết quả quan trọng thực sự được hoàn tất.

Thiết lập nhịp điều hành nguồn lực theo tuần, tháng và quý

Ở cấp tuần, nhóm cần một cuộc rà soát ngắn về workload: sự cố lớn, điểm nghẽn, người bị quá tải, task đang chờ phụ thuộc và những thay đổi cần escalation. Ở cấp tháng, trưởng phòng cập nhật forecast capacity theo lịch nghỉ, dự án mới, kế hoạch bảo trì và các cam kết sắp đến. Ở cấp quý, cần nhìn lại cấu trúc nhu cầu: tỷ trọng Run/Change/Improve có còn phù hợp hay không và năng lực nào cần tuyển, đào tạo hoặc mua ngoài.

Nhịp điều hành phải dựa trên dữ liệu vừa đủ. Không cần timesheet chi tiết từng 15 phút. Điều cần biết là xu hướng: bao nhiêu capacity đang bị tiêu thụ bởi sự cố, backlog tồn tại bao lâu, dự án nào thường xuyên kéo người khỏi vận hành, năng lực nào là bottleneck và công việc nào lặp đi lặp lại nhưng chưa được tự động hóa. Các chỉ số này dẫn đến quyết định quản trị, thay vì chỉ mô tả lịch làm việc.

Trưởng phòng cũng nên phân biệt “bận” và “có giá trị”. Một kỹ sư có thể dành nhiều giờ cho thao tác lặp lại mà doanh nghiệp vẫn chưa giải quyết nguyên nhân gốc. Capacity planning chỉ có ý nghĩa khi nó tạo động lực giảm công việc không tạo giá trị, chứ không phải tối ưu hóa việc lấp đầy lịch.

Tình huống minh họa: dự án ERP bị kéo chậm bởi vận hành

Tình huống giả định: một đội IT tám người vừa duy trì hạ tầng, ứng dụng và Service Desk, vừa được giao dự án nâng cấp ERP trong bốn tháng. Hai chuyên gia ứng dụng liên tục bị kéo sang xử lý sự cố và hỗ trợ kỳ chốt sổ, khiến sprint dự án trễ. Trưởng phòng ban đầu giải quyết bằng cách yêu cầu cả nhóm làm thêm giờ, nhưng sau hai tháng chất lượng giảm và backlog vận hành vẫn tăng.

Cách tiếp cận tốt hơn là tách capacity bắt buộc cho kỳ chốt sổ, đặt lịch “protected time” cho dự án, bổ sung người hỗ trợ cấp hai từ nhà cung cấp vào các tuần cao điểm và giới hạn các thay đổi không thiết yếu trong giai đoạn chuyển đổi. Đồng thời, các lỗi lặp lại được đưa vào backlog cải tiến với owner và deadline. Sau đó, tiến độ dự án được báo cáo cùng với mức tiêu thụ capacity vận hành để sponsor hiểu rõ trade-off.

Bài học không phải “làm ít dự án hơn”, mà là làm cho quyết định ưu tiên nhìn thấy được. Khi nguồn lực bị kéo khỏi dự án, cần ghi nhận nó như một thay đổi có tác động đến cam kết; khi vận hành cần thêm capacity, phải nêu rõ rủi ro nếu không cung cấp. Trưởng phòng không nên để những đánh đổi này diễn ra âm thầm.

Checklist để cân đối nguồn lực IT trước khi cam kết kế hoạch

Đã có một backlog duy nhất cho các nhu cầu lớn thay vì mỗi nhóm giữ một danh sách riêng?
Đã tách Run, Change, Improve và Unplanned để thấy cấu trúc workload?
Đã xác định năng lực tối thiểu để bảo vệ dịch vụ trọng yếu?
Đã nhận diện kỹ năng đơn điểm thất bại và kế hoạch dự phòng?
Đã dành vùng đệm cho biến động thay vì lập kế hoạch 100% công suất?
Đã đặt giới hạn WIP để tránh bắt đầu quá nhiều việc cùng lúc?
Mỗi dự án mới có sponsor, ưu tiên và nguồn lực thực sự trước khi cam kết?
Có nhịp review tuần/tháng/quý để điều chỉnh capacity theo dữ liệu?

Hành động nên bắt đầu: lấy bốn tuần gần nhất, phân loại thời gian của đội vào Run, Change, Improve và Unplanned; sau đó so sánh với các cam kết hiện tại. Chỉ cần bài tập này, trưởng phòng thường đã nhìn thấy rõ vì sao kế hoạch đang quá tải và đâu là điểm cần thương lượng lại.

Nguồn tham khảo

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