Co-managed IT Helpdesk: Cách chia việc giữa IT nội bộ và đối tác
Co-managed IT Helpdesk là mô hình đồng quản lý trong đó đội IT nội bộ và đối tác cùng hỗ trợ người dùng theo phạm vi, quyền hạn, công cụ và chỉ số đã thống nhất. Đây không phải phương án mặc định thay thế nhân sự hiện có, mà là cách bổ sung năng lực ở những khu vực đội nội bộ chưa đủ nguồn lực, thời gian hoặc độ phủ.
Thách thức lớn nhất của mô hình này không nằm ở việc ai xử lý nhiều ticket hơn. Nếu mô hình vận hành không rõ, một yêu cầu có thể bị chuyển qua lại giữa L1, L2, đội ứng dụng và nhà cung cấp hạ tầng. Ngược lại, khi phạm vi, RACI, công cụ và escalation được thiết kế đồng bộ, người dùng có thể nhận hỗ trợ thống nhất dù phía sau có nhiều đội cùng tham gia.
Co-managed IT Helpdesk là gì và khác thuê ngoài toàn bộ như thế nào?
Co-managed IT Helpdesk giữ lại vai trò chủ động của đội IT nội bộ trong khi bổ sung năng lực từ đối tác. Doanh nghiệp vẫn có thể sở hữu chiến lược, kiến trúc, chính sách bảo mật và quyền phê duyệt thay đổi; đối tác tiếp nhận những phần việc được giao như L1, onsite, trực ngoài giờ hoặc hỗ trợ một nhóm công nghệ.
Điểm khác biệt nằm ở trách nhiệm đồng vận hành. Với mô hình thuê ngoài toàn bộ, nhà cung cấp có thể đảm nhận phần lớn quy trình Helpdesk theo phạm vi hợp đồng. Trong mô hình đồng quản lý, dịch vụ được tạo thành từ công việc của cả hai bên nên cần thiết kế rõ điểm giao nhận, dữ liệu và người chịu trách nhiệm cuối cùng.
Bài viết về khi doanh nghiệp đã có đội IT nội bộ giúp trả lời câu hỏi có nên bổ sung nguồn lực bên ngoài. Sau khi đã chọn hướng kết hợp, bài này đi tiếp một bước: xác định đối tác làm gì, nội bộ giữ gì và hai bên phối hợp bằng cơ chế nào.
CISA cũng lưu ý rằng sử dụng nhà cung cấp dịch vụ không làm mất đi trách nhiệm quản trị rủi ro của doanh nghiệp. Khuyến nghị quản trị rủi ro MSP của CISA nhấn mạnh việc phối hợp giữa lãnh đạo, bộ phận mua sắm và đội kỹ thuật khi quản lý dịch vụ bên ngoài.
Khi nào doanh nghiệp nên thiết kế mô hình IT nội bộ kết hợp IT thuê ngoài?
Mô hình IT nội bộ kết hợp IT thuê ngoài phù hợp khi doanh nghiệp cần mở rộng độ phủ hỗ trợ nhưng vẫn muốn giữ tri thức, quyền kiểm soát và năng lực quyết định bên trong. Nhu cầu này thường xuất hiện khi đội nội bộ bị cuốn vào ticket thường ngày, có nhiều chi nhánh hoặc cần hỗ trợ ngoài khung giờ hiện tại.
Dấu hiệu cần thiết kế mô hình đồng quản lý không chỉ là số lượng ticket tăng. Doanh nghiệp cũng nên xem xét tỷ lệ onsite, độ phức tạp của hệ thống, khung giờ hoạt động, tình trạng thiếu kỹ năng chuyên môn và mức độ phụ thuộc vào một vài cá nhân.
Ví dụ, IT nội bộ có thể hiểu sâu ứng dụng nghiệp vụ nhưng không đủ nhân lực trực service desk. Ngược lại, đối tác có thể tiếp nhận, phân loại và xử lý các yêu cầu phổ biến nhưng cần đội nội bộ quyết định thay đổi trên ERP hoặc hệ thống sản xuất. Operating model tốt phải tận dụng hai loại năng lực này mà không tạo thêm một tầng trung gian khiến người dùng phải chờ.
Có thể chia phạm vi Co-managed IT Helpdesk theo những cách nào?
Phạm vi Co-managed IT Helpdesk có thể được chia theo cấp hỗ trợ, địa điểm, thời gian hoặc công nghệ. Doanh nghiệp cũng có thể kết hợp nhiều chiều, nhưng phải xác định một nguyên tắc chính để tránh việc mỗi ticket được diễn giải theo cách khác nhau.
Cách chia scope | IT nội bộ có thể phụ trách | Đối tác có thể phụ trách | Điểm cần kiểm soát |
Theo tier L1/L2/L3 | L2/L3, hệ thống đặc thù, phê duyệt thay đổi | Tiếp nhận, L1 và một phần L2 | Tiêu chí chuyển cấp và quyền đóng ticket |
Theo địa điểm | Trụ sở, data center hoặc site trọng yếu | Chi nhánh, kho hoặc site không có IT | Điều phối onsite, phụ tùng và quy trình thống nhất |
Theo thời gian | Giờ hành chính hoặc thời gian có chuyên gia | Ngoài giờ, cuối tuần hoặc ca bổ sung | Bàn giao ca và cách tính SLA |
Theo công nghệ | Ứng dụng nghiệp vụ, kiến trúc, bảo mật | Endpoint, Microsoft 365, mạng văn phòng | Ticket liên miền và trách nhiệm điều phối |
Không có hàng nào trong bảng là cấu trúc mặc định. Doanh nghiệp cần điều chỉnh theo năng lực hiện tại, mức độ rủi ro và yêu cầu kinh doanh.
Chia việc theo L1, L2 và L3 cần xác định ra sao?
Chia theo tier phù hợp khi doanh nghiệp có thể phân loại tương đối rõ độ phức tạp và quyền hạn của từng cấp hỗ trợ. Đối tác thường có lợi thế ở khả năng tiếp nhận tập trung và chuẩn hóa L1, trong khi IT nội bộ hiểu sâu hệ thống đặc thù; tuy nhiên, đây không phải quy tắc bắt buộc.
L1 có thể tiếp nhận, xác minh thông tin, hướng dẫn thao tác và xử lý lỗi phổ biến. L2 cần kiến thức kỹ thuật sâu hơn hoặc quyền truy cập cao hơn. L3 thường liên quan đến chuyên gia sản phẩm, kiến trúc, nhà phát triển hoặc hãng. Chi tiết về các cấp độ hỗ trợ IT L1, L2 và L3 có thể được dùng để xây service catalog, nhưng doanh nghiệp vẫn phải mô tả đầu việc cụ thể trong từng cấp.
Rủi ro lớn nhất là xem tier như một tuyến chuyển tiếp máy móc. Nếu L1 chỉ ghi nhận rồi chuyển mọi ticket, người dùng phải lặp lại thông tin và thời gian xử lý tăng. Vì vậy, điều kiện escalation cần dựa trên kỹ năng, quyền hạn, tác động và thời gian đã xử lý, không chỉ dựa vào việc kỹ thuật viên “chưa tìm được câu trả lời”.
Một ticket sau khi chuyển cấp vẫn cần người điều phối xuyên suốt. L2 hoặc L3 có thể thực hiện xử lý chuyên môn, nhưng service desk nên duy trì giao tiếp với người dùng và cập nhật trạng thái trên cùng hệ thống.
Chia scope theo địa điểm, thời gian hoặc công nghệ có gì khác nhau?
Mỗi cách chia giải quyết một loại khoảng trống khác nhau. Chia theo địa điểm bổ sung độ phủ vật lý; chia theo thời gian mở rộng giờ phục vụ; còn chia theo công nghệ bổ sung năng lực chuyên môn.
Với mô hình theo địa điểm, IT nội bộ có thể phụ trách trụ sở trong khi đối tác hỗ trợ chi nhánh. Hai bên cần thống nhất quy trình onsite, kho linh kiện, quyền truy cập và trách nhiệm khi sự cố liên quan đồng thời đến mạng tại site và hệ thống trung tâm. Việc chọn IT Helpdesk remote hay onsite nên dựa trên loại sự cố, không chỉ dựa vào vị trí người dùng.
Chia theo thời gian phù hợp với doanh nghiệp hoạt động nhiều ca. IT nội bộ có thể làm việc trong giờ hành chính, còn đối tác trực buổi tối hoặc cuối tuần. Khi đó, biên bản bàn giao ca phải nêu ticket mở, tác động, hành động đã thực hiện, bước tiếp theo và người có quyền phê duyệt. SLA cũng phải xác định đồng hồ có tiếp tục chạy qua hai ca hay được tính theo lịch riêng.
Chia theo công nghệ phù hợp khi nội bộ muốn giữ ứng dụng nghiệp vụ, còn đối tác hỗ trợ endpoint, Microsoft 365 hoặc mạng văn phòng. Rủi ro là ticket liên miền bị chuyển vòng. Mô hình cần một bên chịu trách nhiệm điều phối, kể cả khi nguyên nhân cuối cùng thuộc nhà cung cấp khác.
Ma trận RACI giữa IT nội bộ và đối tác nên được xây dựng thế nào?
RACI giúp chuyển những mô tả chung như “hai bên phối hợp” thành trách nhiệm cụ thể. Trong đó, R là bên trực tiếp thực hiện, A là bên chịu trách nhiệm cuối cùng, C là bên được tham vấn và I là bên được thông báo.
Mỗi hoạt động chỉ nên có một bên giữ vai trò A. Có thể có nhiều bên thực hiện hoặc được tham vấn, nhưng hai bên cùng “chịu trách nhiệm cuối cùng” thường khiến quyết định bị trì hoãn.
Hoạt động | IT nội bộ | Đối tác Helpdesk | Nghiệp vụ/nhà cung cấp khác |
Tiếp nhận và ghi nhận ticket | I | A/R | I |
Phân loại mức ưu tiên | A/C | R | C |
Xử lý yêu cầu L1 | I | A/R | I |
Xử lý ứng dụng nghiệp vụ | A/R | C | C/R |
Phê duyệt thay đổi | A/R | C | C |
Quản lý quyền truy cập | A | R hoặc C | C |
Điều phối sự cố nghiêm trọng | A | R | C/R |
Báo cáo và cải tiến dịch vụ | A | R | C |
Đây chỉ là ma trận minh họa. Nếu đối tác được giao quyền quản lý dịch vụ rộng hơn, vai trò A có thể thay đổi ở một số hoạt động. Doanh nghiệp nên xây ma trận RACI giữa doanh nghiệp và nhà cung cấp IT Helpdesk đến cấp nhóm công việc, không cần chi tiết tới từng thao tác nhỏ.
RACI cũng không thay thế quy trình. Việc ghi IT nội bộ là A cho quản lý quyền truy cập chưa cho biết ai được duyệt quyền, dữ liệu nào cần kiểm tra và thời gian hoàn tất yêu cầu.
Hai bên cần dùng chung những công cụ và dữ liệu nào?
Mô hình đồng quản lý cần một nguồn dữ liệu vận hành thống nhất. Nếu IT nội bộ và đối tác giữ ticket trên hai hệ thống không đồng bộ, doanh nghiệp khó xác định trạng thái thật, thời gian xử lý và trách nhiệm hiện tại.
Hệ thống ticket nên là nguồn dữ liệu chính cho yêu cầu, trạng thái, SLA, trao đổi và bằng chứng đóng việc. Kho tri thức cần lưu hướng dẫn, known error, workaround và quy trình. Danh mục tài sản hoặc CMDB, nếu có, phải giúp hai bên liên kết ticket với người dùng, thiết bị và dịch vụ bị ảnh hưởng.
Dashboard KPI, công cụ giám sát, MDM/RMM và kênh trao đổi sự cố có thể khác nhau, nhưng dữ liệu quan trọng phải quay về nguồn chính. Quy định vận hành cần nói rõ ai được tạo, sửa, chuyển, đóng và mở lại ticket; ai sở hữu dữ liệu; thời gian lưu giữ; cũng như cách xuất dữ liệu khi kết thúc hợp đồng.
Quyền truy cập của đối tác cần được cấp theo nhiệm vụ. Nguyên tắc quyền tối thiểu của Microsoft khuyến nghị chỉ cấp quyền cần thiết, loại bỏ quyền không dùng và rà soát quyền định kỳ. Co-managed không nên trở thành lý do để cấp quyền quản trị toàn hệ thống cho mọi kỹ thuật viên bên ngoài.
Quy trình escalation cần thiết kế ra sao để ticket không bị chuyển vòng?
Escalation hiệu quả phải xác định điều kiện kích hoạt, người tiếp nhận và quyền quyết định. Danh sách số điện thoại hoặc tên quản lý chưa đủ nếu không nói rõ khi nào cần liên hệ và người đó phải làm gì.
Escalation kỹ thuật được kích hoạt khi ticket vượt khả năng, quyền hạn hoặc thời gian xử lý của tier hiện tại. Escalation quản lý áp dụng khi ticket có nguy cơ vượt SLA, bị chuyển vòng hoặc thiếu nguồn lực. Escalation kinh doanh dành cho sự cố có tác động lớn đến vận hành, doanh thu, khách hàng hoặc tuân thủ.
Mỗi cấp cần có thời gian xác nhận, kênh liên hệ, tần suất cập nhật và người có quyền phê duyệt workaround hoặc thay đổi. Với sự cố nghiêm trọng, đội kỹ thuật có thể xử lý song song trong khi một đầu mối quản lý giao tiếp với lãnh đạo và người dùng.
Mức ưu tiên cần được thống nhất theo tác động và độ khẩn cấp. Ma trận ưu tiên ticket P1–P4 giúp hai bên giảm tình trạng cùng một sự cố nhưng mỗi đội đánh giá một mức khác nhau.
KPI dùng chung nào giúp đánh giá toàn bộ dịch vụ?
KPI chung phải phản ánh kết quả xuyên suốt hành trình người dùng, không chỉ hiệu suất riêng của từng đội. Nếu đối tác đạt SLA phản hồi nhưng IT nội bộ chậm phê duyệt, hoặc nội bộ xử lý kỹ thuật nhanh nhưng service desk không cập nhật người dùng, trải nghiệm chung vẫn không đạt.
FCR cho biết tỷ lệ xử lý ngay lần đầu; MTTR đo thời gian khôi phục hoặc xử lý nhưng phải thống nhất định nghĩa; backlog phản ánh khối lượng tồn; reopen rate cho thấy chất lượng xử lý ban đầu. Tỷ lệ chuyển cấp, chuyển sai nhóm, SLA và CSAT cũng giúp đánh giá điểm giao giữa các bên.
Doanh nghiệp nên theo dõi thêm ticket lặp lại, tiến độ problem action, chất lượng kho tri thức và mức độ đầy đủ của bàn giao ca. Bộ KPI IT Helpdesk gồm FCR, MTTR, CSAT, backlog và reopen rate có thể làm nền tảng, nhưng mục tiêu cần điều chỉnh theo phạm vi của từng bên.
Theo nguyên tắc quản lý mức dịch vụ của ITIL/PeopleCert, mục tiêu dịch vụ cần dựa trên nhu cầu kinh doanh, được xác định, theo dõi và cải tiến với sự tham gia của đối tác, nhà cung cấp. Vì vậy, KPI không nên chỉ dùng để quy lỗi mà còn phải chỉ ra điểm cần cải thiện trong operating model.
Khi phân tích kết quả, cần tách thời gian do đối tác xử lý, thời gian chờ nội bộ phê duyệt và thời gian chờ nhà cung cấp thứ ba. Tuy vậy, báo cáo tổng vẫn phải cho thấy người dùng đã chờ bao lâu từ lúc gửi yêu cầu đến khi khôi phục dịch vụ.
Doanh nghiệp nên triển khai Co-managed IT Helpdesk theo những bước nào?
Doanh nghiệp nên bắt đầu bằng dữ liệu hiện trạng thay vì chọn trước một mô hình chia việc. Dữ liệu cần có gồm người dùng, thiết bị, địa điểm, giờ hoạt động, lịch sử ticket, tỷ lệ onsite, hệ thống quan trọng và năng lực hiện tại của đội nội bộ.
Từ đó, doanh nghiệp xác định cách chia chính theo tier, site, thời gian hoặc công nghệ; sau đó lập service catalog và RACI. Bước tiếp theo là thống nhất hệ thống ticket, kho tri thức, quyền truy cập, escalation và KPI chung.
Trước khi áp dụng toàn bộ, hai bên nên chạy thử trên một phạm vi có thể kiểm soát. Giai đoạn pilot cần có điều kiện nghiệm thu, danh sách rủi ro và cơ chế điều chỉnh. Kết quả thử nghiệm phải cho biết mô hình có giảm backlog, cải thiện khả năng tiếp nhận và giữ được chất lượng chuyển giao hay không.
Sau khi vận hành chính thức, operating model cần được rà soát định kỳ hoặc khi có thay đổi lớn về người dùng, địa điểm, công nghệ và giờ hoạt động. RACI và service catalog không nên trở thành tài liệu ký xong rồi để nguyên trong suốt hợp đồng.
IPSIP Việt Nam hỗ trợ thiết kế mô hình Co-managed IT Helpdesk như thế nào?
IPSIP Việt Nam có thể bắt đầu bằng khảo sát năng lực hiện tại của đội IT nội bộ cùng dữ liệu vận hành thực tế. Phạm vi khảo sát gồm người dùng, thiết bị, địa điểm, giờ hỗ trợ, lịch sử ticket, hệ thống, nhu cầu onsite và những phần việc doanh nghiệp muốn tiếp tục giữ nội bộ.
Từ kết quả khảo sát, IPSIP phối hợp xây dựng service catalog, chia scope theo tier, site, thời gian hoặc công nghệ; xác định RACI; thiết kế quy trình ticket, escalation và KPI chung. Mô hình hỗ trợ có thể kết hợp remote và onsite, đồng thời kết nối với IT outsourcing, NOC hoặc SOC khi trách nhiệm thực tế cần nhiều đội chuyên môn.
Mục tiêu không phải chuyển càng nhiều công việc ra ngoài càng tốt. Một operating model phù hợp phải giúp đội nội bộ tập trung vào phần việc cần tri thức doanh nghiệp và quyền quyết định, trong khi đối tác bổ sung độ phủ, quy trình hoặc kỹ năng còn thiếu.
Trước khi giao ticket cho đối tác, doanh nghiệp cần xác định rõ phần việc giữ nội bộ, điểm escalation và dữ liệu dùng chung. Liên hệ ngay với IPSIP, yêu cầu khảo sát nhu cầu hoặc nhận báo giá IT Helpdesk để xây dựng mô hình Co-managed IT Helpdesk phù hợp với năng lực hiện tại, thay vì áp một cấu trúc thuê ngoài cố định.
Co-managed IT Helpdesk không phải là hình thức thuê ngoài toàn bộ dưới một tên gọi khác. Đây là mô hình phối hợp trong đó IT nội bộ và đối tác cùng tạo ra dịch vụ hỗ trợ, nhưng mỗi hoạt động vẫn cần phạm vi, quyền hạn và một bên chịu trách nhiệm cuối cùng.
Hiệu quả của mô hình phụ thuộc vào bốn yếu tố: cách chia scope, ma trận RACI, nguồn dữ liệu chung và cơ chế escalation. KPI cũng cần đo toàn bộ hành trình người dùng thay vì chỉ đánh giá từng đội riêng lẻ.
Khi người dùng, địa điểm, công nghệ hoặc giờ vận hành thay đổi, operating model phải được rà soát tương ứng. Một cuộc khảo sát hiện trạng trước báo giá sẽ giúp doanh nghiệp lựa chọn phạm vi bổ sung phù hợp và tránh chồng chéo với đội IT hiện có.
