Cách tính nhân sự IT Helpdesk theo người dùng ticket và giờ hỗ trợ
Không có một tỷ lệ cố định kiểu “một nhân sự IT Helpdesk phục vụ X người dùng” phù hợp cho mọi doanh nghiệp. Cách tính nhân sự IT Helpdesk đáng tin cậy phải bắt đầu từ khối lượng ticket, thời gian xử lý, mức độ phức tạp, khung giờ hỗ trợ, SLA, khả năng tự phục vụ và yêu cầu dự phòng.
Bài viết này trình bày mô hình capacity planning helpdesk theo tải công việc, sau đó áp dụng vào ba kịch bản minh họa cho 50, 200 và 500 người dùng. Doanh nghiệp có thể thay các giả định bằng dữ liệu thực tế để ước tính ngân sách, so sánh đội nội bộ với thuê ngoài và chuẩn bị đầu vào cho báo giá.
Vì sao không thể tính nhân sự IT Helpdesk chỉ theo số người dùng?
Số người dùng chỉ cho biết quy mô phục vụ, chưa cho biết lượng công việc mà đội Helpdesk phải xử lý. Hai doanh nghiệp cùng có 200 nhân viên vẫn có thể cần nguồn lực rất khác nhau nếu một bên dùng thiết bị đồng nhất, làm việc giờ hành chính và có cổng tự phục vụ; bên còn lại vận hành nhiều địa điểm, nhiều ứng dụng, hỗ trợ ca đêm và đặt SLA phản hồi ngắn.
Theo tài liệu Workforce Management của Atlassian, lập kế hoạch còn bao gồm lịch ca, ngưỡng năng lực và phân công đúng kỹ năng. ServiceNow cũng đặt dự báo nhu cầu, lịch làm việc và nghỉ phép trong cùng bài toán tối ưu nguồn lực. Vì vậy, chỉ số ticket per agent chỉ hữu ích khi đi cùng thời gian xử lý và chất lượng dịch vụ.
Doanh nghiệp cần thu thập dữ liệu đầu vào nào trước khi tính nhân sự IT Helpdesk?
Doanh nghiệp nên lấy dữ liệu từ hệ thống ticket trong ít nhất vài chu kỳ vận hành đại diện, thay vì dựa vào cảm nhận của người quản lý. Nếu chưa có dữ liệu lịch sử, có thể bắt đầu bằng khảo sát và giả định, nhưng phải gắn nhãn giả định và hiệu chỉnh sau khi vận hành.
Các đầu vào tối thiểu gồm:
Số người dùng, thiết bị, địa điểm và mô hình làm việc.
Số ticket theo ngày, tuần, tháng và giờ cao điểm.
Cơ cấu ticket đơn giản, trung bình, phức tạp hoặc theo các tuyến hỗ trợ L1, L2, L3.
Thời gian thao tác thực tế cho từng nhóm ticket, không nhầm với tổng thời gian từ lúc mở đến khi đóng.
Tỷ lệ giải quyết ngay ở tuyến đầu, tỷ lệ chuyển cấp, mở lại và tồn đọng.
Tỷ lệ yêu cầu được tự động hóa hoặc người dùng tự xử lý qua kho tri thức.
Khung giờ, số ca, yêu cầu onsite và mức nhân sự tối thiểu mỗi ca.
Mục tiêu SLA về phản hồi, khôi phục hoặc giải quyết theo mức ưu tiên.
Thời gian không trực tiếp xử lý ticket như họp, đào tạo, nghỉ phép, nghỉ bệnh, báo cáo và quản trị hệ thống.
Một ticket IT Helpdesk đủ dữ liệu cần giúp phân loại yêu cầu, ghi nhận thời gian và truy vết người phụ trách. Nếu yêu cầu vẫn phân tán qua chat, điện thoại và email cá nhân, doanh nghiệp nên chuẩn hóa quy trình từ tiếp nhận đến đóng ticket trước khi kỳ vọng số liệu capacity planning chính xác.
Công thức capacity planning helpdesk nên được xây dựng ra sao?
Công thức nền tảng là quy đổi toàn bộ ticket thành giờ xử lý, rồi chia cho năng lực xử lý hữu dụng của một nhân sự toàn thời gian. Kết quả này là FTE theo tải công việc, chưa phải số người cuối cùng phải tuyển hoặc bố trí.
Tải công việc trong kỳ = Tổng của (số ticket từng nhóm × thời gian xử lý trung bình của nhóm)
Năng lực hữu dụng của một FTE = giờ làm việc theo lịch × tỷ lệ thời gian thực sự có thể xử lý ticket
FTE cơ sở = tổng tải công việc ÷ năng lực hữu dụng của một FTE
FTE kế hoạch = FTE cơ sở sau khi kiểm tra độ phủ ca, giờ cao điểm, SLA, backlog, kỹ năng và dự phòng.
Ví dụ, 22 ngày làm việc, mỗi ngày 8 giờ tạo ra 176 giờ theo lịch. Nếu giả định 65% thời gian có thể xử lý ticket, năng lực hữu dụng là 114,4 giờ. Mức 65% chỉ dùng minh họa; doanh nghiệp phải thay bằng dữ liệu thực tế.
Cần tránh hai lỗi. Thứ nhất, lấy tổng giờ làm việc theo hợp đồng làm toàn bộ năng lực xử lý, khiến kế hoạch bị thiếu người. Thứ hai, cộng nhiều “hệ số an toàn” chồng lấn. Nếu thời gian không xử lý ticket đã được phản ánh trong tỷ lệ hữu dụng thì không nên cộng lại cùng phần nghỉ phép hoặc họp lần nữa.
Hệ số phức tạp của ticket nên được áp dụng như thế nào?
Cách tốt nhất là chia ticket thành các nhóm có thời gian xử lý trung bình riêng, vì độ phức tạp khi đó đã nằm trong chính tải công việc. Chỉ nên dùng trọng số phức tạp khi doanh nghiệp chưa có dữ liệu thời gian đủ đáng tin.
Có thể tạm phân nhóm:
Đơn giản: đặt lại mật khẩu, hướng dẫn thao tác, cấu hình cơ bản.
Trung bình: lỗi phần mềm, thiết bị đầu cuối, tài khoản hoặc kết nối cần chẩn đoán.
Phức tạp: sự cố liên quan máy chủ, mạng, bảo mật hoặc cần phối hợp L2/L3.
Nếu mỗi nhóm đã dùng thời gian trung bình 20, 45 và 120 phút thì không nên tiếp tục nhân thêm một “hệ số phức tạp tổng thể”. Làm vậy sẽ tính cùng một yếu tố hai lần. Khi dùng trọng số thay thế, doanh nghiệp phải xác định đó là thang quy đổi nội bộ, không phải tiêu chuẩn chung của ngành.
Ba FTE tải công việc không có nghĩa ba người bất kỳ có thể xử lý mọi yêu cầu. Doanh nghiệp vẫn cần xác định ranh giới giữa L1, L2 và L3, quyền truy cập và ma trận chuyển cấp.
Ca trực SLA và nhân sự dự phòng được tính thế nào?
Sau khi có FTE cơ sở, doanh nghiệp phải kiểm tra khả năng phủ lịch và mức dịch vụ. Một tải công việc nhỏ vẫn có thể đòi hỏi nhiều vị trí nếu cần hiện diện liên tục, trong khi một đội dùng chung có thể hấp thụ tải thấp hiệu quả hơn.
Microsoft mô tả SLA như cơ chế theo dõi chính sách hỗ trợ và mức dịch vụ khách hàng được hưởng. Trong Service Manager, SLA còn gắn với lịch, hàng đợi và chỉ số thời gian; vì vậy thiết kế nhân sự phải bám vào thời gian dịch vụ thực tế.
Doanh nghiệp nên lần lượt kiểm tra:
Mỗi thời điểm cần tối thiểu bao nhiêu người trực và cần kỹ năng gì?
Ca làm có thời gian bàn giao, nghỉ giữa ca và xử lý việc tồn hay không?
Ai thay thế khi nhân sự nghỉ phép, đào tạo hoặc nghỉ bệnh?
Sự cố P1 có yêu cầu nhiều người cùng tham gia hoặc gọi chuyên gia on-call không?
Backlog và giờ cao điểm có làm vi phạm SLA IT Helpdesk dù tổng công suất tháng vẫn đủ không?
Với hỗ trợ 24/7, không thể lấy FTE theo tải rồi làm tròn. Cần lập lịch theo tuần, số vị trí trực đồng thời và lớp dự phòng. Mô hình 24/7 phải duy trì độ phủ ngay cả ở ca ít ticket.
Ví dụ tính nhân sự IT Helpdesk cho 50 200 và 500 người dùng ra sao?
Ba kịch bản dưới đây minh họa cách thay dữ liệu vào công thức, không phải định mức nhân sự. Mức ticket trên mỗi người dùng khác nhau để cho thấy quy mô không quyết định tải công việc.
Giả định chung: 22 ngày làm việc mỗi tháng, 8 giờ mỗi ngày và tỷ lệ xử lý hữu dụng 65%, tương đương 114,4 giờ mỗi FTE. Thời gian trung bình của ticket đơn giản, trung bình và phức tạp lần lượt là 20, 45 và 120 phút.
Hạng mục | 50 người dùng | 200 người dùng | 500 người dùng |
Ticket/tháng giả định | 30 | 180 | 600 |
Cơ cấu đơn giản/trung bình/phức tạp | 80%/15%/5% | 70%/20%/10% | 65%/25%/10% |
Thời gian xử lý theo nhóm | 20/45/120 phút | 20/45/120 phút | 20/45/120 phút |
Tổng giờ xử lý | 14,4 | 105,0 | 362,5 |
Khung giờ hỗ trợ | 8x5 | 8x5 | 8x5, nhiều điểm |
Năng lực hữu dụng/FTE | 114,4 giờ | 114,4 giờ | 114,4 giờ |
FTE theo tải công việc | 0,13 | 0,92 | 3,17 |
Điều chỉnh ca và dự phòng | Cần đầu mối thay thế | Cần phủ nghỉ và giờ cao điểm | Cần phủ lịch, kỹ năng và nhiều điểm |
Phương án tham khảo | Kiêm nhiệm, dùng chung hoặc thuê ngoài | 1 nội bộ kết hợp nguồn lực dự phòng | Khoảng 4 vị trí 8x5, có L2/L3 dùng chung |
Với 200 người dùng: (126 × 20 + 36 × 45 + 18 × 120) ÷ 60 = 105 giờ; FTE cơ sở là 105 ÷ 114,4 = 0,92. Một người duy nhất không thể trực liên tục và đồng thời phủ nghỉ hoặc đợt tăng tải, nên có thể cần nguồn lực thuê ngoài hay đội dùng chung dự phòng.
Với 500 người dùng, tải là (390 × 20 + 150 × 45 + 60 × 120) ÷ 60 = 362,5 giờ, tương đương 3,17 FTE. Bốn vị trí chỉ là điểm bắt đầu cho mô hình 8x5; nếu chuyển sang 24/7, phải xây lại lịch phủ ca.
Kết quả cũng có thể giảm khi kho tri thức, chuẩn hóa thiết bị và tự động hóa làm giảm số ticket hoặc thời gian xử lý. Ngược lại, yêu cầu onsite, nhiều ứng dụng đặc thù, SLA gắt, ticket mở lại và backlog sẽ làm nhu cầu tăng.
Khi nào nên duy trì đội nội bộ thuê ngoài hoặc dùng mô hình kết hợp?
Theo định hướng của ITIL Service từ PeopleCert, quản lý dịch vụ cần xem xét đồng thời mức dịch vụ, độ tin cậy vận hành và cải tiến liên tục. Vì vậy, lựa chọn mô hình nhân sự không nên chỉ dựa trên chi phí lương hoặc số lượng người dùng.
Mô hình | Phù hợp khi | Điểm cần kiểm tra trước khi chọn |
Nội bộ | Tải ổn định, cần hiện diện thường xuyên, hệ thống đặc thù | Dự phòng nghỉ, tuyển L2/L3, ca ngoài giờ |
Thuê ngoài | Tải biến động, quy mô nhỏ, cần phạm vi kỹ năng rộng | SLA, phạm vi, bảo mật, quyền truy cập, báo cáo |
Kết hợp | Đã có IT nội bộ nhưng thiếu độ phủ hoặc kỹ năng chuyên sâu | Ma trận trách nhiệm, chuyển cấp, quyền sở hữu ticket |
Doanh nghiệp đã có IT nội bộ không nhất thiết phải thay thế đội hiện tại. Mô hình phối hợp IT nội bộ với Helpdesk thuê ngoài có thể để đội nội bộ tập trung vào hệ thống và dự án, còn đối tác tiếp nhận L1, hỗ trợ ngoài giờ hoặc bổ sung nguồn lực cao điểm.
IPSIP Việt Nam hỗ trợ doanh nghiệp xây dựng phương án IT Helpdesk như thế nào?
IPSIP Việt Nam vận hành IT Helpdesk từ xa và tại chỗ, hoặc phối hợp với đội IT nội bộ theo phạm vi và SLA đã thống nhất. Ngoài ra IPSIP còn cung cấp các nhóm dịch vụ IT thuê ngoài, Managed IT, Cloud, NOC và SOC 24/7, cho phép doanh nghiệp kết hợp hỗ trợ người dùng với vận hành hạ tầng hoặc giám sát an ninh mạng khi nhu cầu thực tế yêu cầu.
Một phương án phù hợp nên bắt đầu bằng khảo sát số người dùng, thiết bị, địa điểm, lịch sử ticket, hệ thống trọng yếu, giờ hỗ trợ, SLA và nhu cầu onsite. Từ đó, doanh nghiệp mới có thể so sánh đội riêng, dịch vụ dùng chung hoặc mô hình kết hợp trên cùng một cơ sở tải công việc.
Nếu doanh nghiệp đang lập ngân sách hoặc muốn kiểm tra lại cách tính nhân sự IT Helpdesk, hãy yêu cầu khảo sát nhu cầu hoặc nhận báo giá IT Helpdesk. Phạm vi khảo sát nên làm rõ tải ticket, độ phủ ca, mức SLA và mô hình nguồn lực trước khi chốt chi phí.
Tham khảo
Microsoft Learn, Configure Service Level Management in Service Manager
Atlassian Support, Assign work to the right agents with Workforce Management
ServiceNow, Workforce Optimization
PeopleCert, ITIL Service Version 5
Bình luận