Ma trận RACI giữa doanh nghiệp và nhà cung cấp IT Helpdesk
Thuê ngoài IT Helpdesk không có nghĩa doanh nghiệp chuyển toàn bộ trách nhiệm công nghệ cho nhà cung cấp.
Vendor có thể tiếp nhận ticket, hỗ trợ người dùng, xử lý endpoint, kiểm tra network hoặc phối hợp với các đơn vị thứ ba. Nhưng khi cần cấp quyền quản trị, thay đổi cấu hình production, xử lý sự cố bảo mật hoặc quyết định ưu tiên trong một major incident, câu hỏi quan trọng không còn là vendor có làm được không? mà là ai có quyền quyết định và ai chịu trách nhiệm cuối cùng?
Đó là lý do ma trận RACI nên được xác định cùng với phạm vi dịch vụ và SLA ngay từ đầu.
RACI giúp doanh nghiệp phân biệt bốn vai trò: Responsible – người trực tiếp thực hiện; Accountable – người chịu trách nhiệm cuối cùng; Consulted – bên cần được tham vấn; và Informed – bên cần được thông báo.
Với mô hình dịch vụ IT Helpdesk thuê ngoài, ma trận này đặc biệt hữu ích khi trách nhiệm được chia giữa người dùng, IT nội bộ, nhà cung cấp Helpdesk, đội security, nhà cung cấp đường truyền và các vendor ứng dụng khác.
RACI IT Helpdesk giải quyết vấn đề gì mà SLA chưa giải quyết?
Trước khi lập RACI, doanh nghiệp cần phân biệt ba lớp quản trị khác nhau: scope, SLA và trách nhiệm.
Scope trả lời câu hỏi nhà cung cấp hỗ trợ những gì. Chẳng hạn Helpdesk có thể hỗ trợ laptop, Microsoft 365, tài khoản người dùng, Wi-Fi hoặc phối hợp với ISP. Nếu doanh nghiệp chưa xác định rõ phạm vi này, có thể tham khảo các nhóm công việc của IT Support và IT Helpdesk trước khi thiết kế ma trận trách nhiệm.
SLA IT Helpdesk lại trả lời câu hỏi dịch vụ phải phản hồi hoặc xử lý trong điều kiện nào và trong bao lâu. Một ticket P1 có thể cần được phản hồi nhanh hơn P3, nhưng SLA không tự động xác định ai được quyền thay đổi firewall, ai phê duyệt cấp quyền hoặc ai quyết định shutdown một hệ thống quan trọng.
RACI bổ sung phần còn thiếu: ai thực hiện, ai chịu trách nhiệm cuối cùng, ai phải được hỏi ý kiến và ai phải được thông báo.
Điểm quan trọng nhất là: Thuê ngoài việc thực hiện không đồng nghĩa thuê ngoài toàn bộ trách nhiệm quản trị.
Ví dụ, vendor Helpdesk có thể là bên trực tiếp tạo tài khoản cho nhân viên mới. Nhưng người quản lý bộ phận hoặc IT Manager vẫn có thể là người chịu trách nhiệm phê duyệt việc cấp quyền. Khi đó, vendor là Responsible, trong khi doanh nghiệp giữ vai trò Accountable.
5 nguyên tắc lập ma trận RACI giữa doanh nghiệp và vendor
RACI chỉ hữu ích khi nó phản ánh đúng quyền hạn thực tế. Một bảng đẹp nhưng không khớp với hợp đồng, quyền truy cập hoặc quy trình phê duyệt sẽ không giải quyết được vấn đề vận hành.
1. Mỗi đầu việc quan trọng cần một Accountable rõ ràng
Một hoạt động có thể có nhiều người tham gia xử lý, nhưng cần tránh tình trạng không ai biết ai chịu trách nhiệm cuối cùng.
Ví dụ, khi toàn bộ văn phòng mất Internet, Helpdesk có thể kiểm tra thiết bị, ISP có thể kiểm tra đường truyền, còn IT nội bộ phối hợp với quản lý văn phòng. Tuy nhiên, vẫn cần một đầu mối Accountable chịu trách nhiệm điều phối cho đến khi dịch vụ được khôi phục.
2. Responsible không đồng nghĩa với quyền phê duyệt
Vendor có thể có năng lực kỹ thuật để thực hiện một thay đổi nhưng không có nghĩa họ được phép tự quyết định thay đổi đó.
Một kỹ thuật viên Helpdesk có thể biết cách thêm firewall rule, tạo administrator account hoặc restart server. Nhưng nếu đây là hệ thống production, quyền thực hiện phải phụ thuộc vào authority đã được doanh nghiệp phê duyệt.
3. Tách quyền truy cập khỏi quyền quyết định
Đây là điểm đặc biệt quan trọng với tài khoản đặc quyền.
Vendor cần quyền đủ để hoàn thành công việc, nhưng không nên mặc định mọi kỹ thuật viên Helpdesk đều có full administrator access trên tất cả hệ thống.
Doanh nghiệp nên xác định rõ:
Ai được quyền truy cập hệ thống nào.
Quyền truy cập là thường trực hay cấp theo yêu cầu.
Khi nào cần approval.
Hoạt động nào phải được logging.
Ai có thể yêu cầu nâng quyền.
Ai được quyền phê duyệt.
4. Escalation phải được xác định trước khi sự cố xảy ra
Khi một sự cố vượt khỏi phạm vi Helpdesk, kỹ thuật viên phải biết cần chuyển cho ai.
Ví dụ:
Lỗi ứng dụng ERP → application vendor.
Internet mất diện rộng → ISP.
Endpoint có dấu hiệu bị tấn công → security/SOC.
Switch core gặp lỗi → network specialist.
Quyền truy cập nhạy cảm → system owner hoặc IT Manager.
Không xác định trước escalation path sẽ khiến ticket bị chuyển vòng giữa nhiều bên, trong khi người dùng vẫn chưa thể làm việc.
5. RACI phải khớp với scope, SLA và hợp đồng
Nếu hợp đồng nói vendor quản lý endpoint nhưng RACI yêu cầu mọi thao tác đều chờ IT nội bộ phê duyệt, thời gian xử lý thực tế có thể không phù hợp với SLA.
Ngược lại, nếu SLA rất chặt nhưng vendor không được cấp đủ quyền để xử lý, nhà cung cấp cũng khó đáp ứng cam kết.
RACI vì vậy không nên là tài liệu đứng riêng. Nó cần được đối chiếu với service scope, escalation matrix, quyền truy cập và SLA.
Ma trận RACI mẫu theo nhóm công việc IT Helpdesk
Bảng dưới đây là mẫu tham khảo, không phải ma trận mặc định áp dụng cho mọi doanh nghiệp. Vai trò thực tế cần điều chỉnh theo hệ thống, năng lực IT nội bộ, hợp đồng và mức quyền doanh nghiệp muốn giao cho vendor.
Nhóm công việc | IT nội bộ / Doanh nghiệp | Vendor IT Helpdesk | Business Owner / Quản lý | Security / Specialist |
Tiếp nhận và xử lý ticket người dùng | A/C | R | I | – |
Reset mật khẩu theo quy trình đã duyệt | A | R | I | C khi cần |
Cài đặt phần mềm đã được phê duyệt | A | R | I | C |
Setup và bàn giao endpoint | A | R | I | C |
Theo dõi patch/update endpoint | A | R | I | C |
Troubleshoot LAN/Wi-Fi | A | R | I | C |
Thay đổi cấu hình network production | A | R/C | I | C/R |
Làm việc với ISP hoặc vendor thứ ba | A | R/C | I | C |
Tạo tài khoản người dùng | A | R | C | C |
Cấp quyền vào hệ thống nhạy cảm | A | R/C | C | C/R |
Tiếp nhận cảnh báo bảo mật từ người dùng | A | R | I | C/R |
Điều tra security incident | A/C | C | I | R |
Điều phối major incident | A | R/C | C/I | C/R |
Thực hiện change đã được duyệt | A | R | I | C |
Phê duyệt change có rủi ro cao | A/R | C | C | C |
Review SLA, backlog và recurring issue | A | R/C | I | C |
User support: Vendor thực hiện, doanh nghiệp chịu trách nhiệm cuối cùng
Các yêu cầu như lỗi Outlook, không vào được VPN, máy in không hoạt động hoặc phần mềm văn phòng gặp sự cố thường phù hợp để Helpdesk trực tiếp xử lý.
Trong trường hợp này, vendor có thể giữ vai trò Responsible.
Tuy nhiên, doanh nghiệp hoặc IT Manager vẫn nên giữ Accountable đối với chất lượng dịch vụ tổng thể: phạm vi hỗ trợ, quyền mà kỹ thuật viên được sử dụng, cách ưu tiên ticket và cách xử lý vấn đề lặp lại.
Endpoint: Phân biệt vận hành với quyết định vòng đời thiết bị
Vendor có thể đảm nhiệm setup laptop, cài phần mềm, cập nhật hệ điều hành, xử lý lỗi endpoint hoặc thu hồi thiết bị.
Nhưng những quyết định như thay laptop mới, thay đổi baseline bảo mật, xóa dữ liệu hoặc cho phép một phần mềm chưa được phê duyệt vẫn nên có owner phía doanh nghiệp.
Nói cách khác, Helpdesk có thể chịu trách nhiệm thực hiện nhưng không nhất thiết chịu trách nhiệm quyết định chính sách endpoint.
Network: Troubleshooting khác với quyền kiểm soát thay đổi hệ thống
Helpdesk có thể kiểm tra Wi-Fi, dây mạng, địa chỉ IP, DNS hoặc xác định sự cố nằm ở endpoint, LAN hay ISP.
Nhưng khi phải thay VLAN, routing, firewall rule hoặc cấu hình core network, doanh nghiệp cần xác định rõ vendor có được quyền thực hiện hay chỉ được escalation.
Đây là khu vực rất dễ phát sinh hiểu nhầm nếu hợp đồng chỉ ghi chung chung “hỗ trợ network”.
Vendor bên thứ ba: Xác định rõ ai phối hợp và ai chịu trách nhiệm cuối cùng
Nhiều ticket không thể được một Helpdesk giải quyết độc lập.
Một lỗi Microsoft 365 có thể cần mở case với Microsoft. Sự cố Internet cần làm việc với ISP. Lỗi ứng dụng kế toán có thể thuộc trách nhiệm của nhà cung cấp phần mềm.
RACI nên chỉ rõ:
Ai mở ticket với vendor thứ ba.
Ai cung cấp log hoặc thông tin kỹ thuật.
Ai theo dõi tiến độ.
Ai cập nhật cho người dùng.
Ai chịu trách nhiệm cuối cùng cho business outcome.
Nếu không có phân công này, Helpdesk có thể hoàn thành phần troubleshooting của mình nhưng ticket vẫn bị “treo” ở bên thứ ba.
Security và quyền truy cập: Helpdesk tiếp nhận và chuyển cấp, không mặc định chịu trách nhiệm điều tra
Helpdesk thường là một trong những nơi đầu tiên nhận tín hiệu bất thường: người dùng báo email lạ, tài khoản bị khóa, endpoint xuất hiện cảnh báo hoặc máy tính có hành vi bất thường.
Vai trò phù hợp của Helpdesk có thể là tiếp nhận, thu thập thông tin ban đầu, cô lập theo playbook đã được phê duyệt và escalation.
Điều tra security incident chuyên sâu lại có thể thuộc IT Security, SOC hoặc đơn vị chuyên trách.
NIST SP 800-61 Revision 3, được phát hành tháng 4/2025, cũng nhấn mạnh rằng incident response liên quan đến nhiều cá nhân, nhóm và bên thứ ba; leadership, incident handlers và các stakeholder khác có vai trò khác nhau trong quyết định và xử lý sự cố.
RACI giúp doanh nghiệp tránh tình trạng một kỹ thuật viên Helpdesk phải tự quyết định những vấn đề vượt quá authority của mình.
Major Incident: Khi người xử lý không phải người chịu trách nhiệm cuối cùng
Major incident là tình huống RACI thể hiện rõ giá trị nhất.
Giả sử toàn bộ văn phòng mất Internet.
Helpdesk có thể:
Tiếp nhận nhiều ticket.
Nhận diện đây không còn là lỗi của một người dùng.
Kiểm tra router, firewall hoặc thiết bị mạng theo quyền được cấp.
Liên hệ ISP.
Cập nhật trạng thái sự cố.
Escalation sang network specialist.
Nhưng người chịu trách nhiệm điều phối phía doanh nghiệp có thể vẫn là IT Manager.
Nếu sự cố ảnh hưởng hoạt động kinh doanh nghiêm trọng, business owner hoặc ban quản lý cũng cần được đưa vào luồng thông tin.
Một RACI cho Major Incident có thể được thiết kế như sau:
Hoạt động | Vendor Helpdesk | IT Manager | Specialist/ Vendor liên quan | Business Owner |
Nhận diện major incident | R | A | C | I |
Triage ban đầu | R | A | C | I |
Quyết định escalation | R | A | C | I |
Thay đổi production khẩn cấp | R/C | A | R/C | I |
Cập nhật người dùng | R | A | C | I |
Quyết định ưu tiên kinh doanh | C | C | C | A/R |
Post-incident review | R/C | A | C | I |
Mục tiêu không phải làm ma trận phức tạp hơn. Mục tiêu là tránh phải tranh luận “ai được quyết định?” ngay giữa lúc hệ thống đang ngừng hoạt động.
Change Management: Vendor được phép thay đổi đến đâu?
Một Helpdesk vận hành hiệu quả cần đủ quyền để xử lý nhanh, nhưng quyền đó phải có ranh giới.
Có thể phân change thành ba nhóm thực tế.
Standard change là thay đổi đã được doanh nghiệp phê duyệt trước và có quy trình rõ. Ví dụ cài một phần mềm chuẩn hoặc thêm máy in theo mẫu cấu hình đã thống nhất. Vendor có thể trực tiếp thực hiện mà không cần xin lại approval từng lần.
Normal change là thay đổi cần xem xét trước khi thực hiện. Ví dụ sửa firewall rule, thay cấu hình network hoặc thay đổi policy trên diện rộng. Vendor có thể đề xuất và thực hiện nhưng doanh nghiệp giữ quyền phê duyệt.
Emergency change xuất hiện khi cần hành động nhanh để giảm tác động của một sự cố nghiêm trọng. Quy trình có thể được rút gọn, nhưng vẫn cần xác định ai có authority cho phép hành động và ai phải được thông báo.
Một nguyên tắc hữu ích là: Vendor cần biết không chỉ “mình có thể làm gì”, mà còn “khi nào mình không được phép tự làm”.
RACI vì vậy nên gắn trực tiếp với access level và change authority.
Review RACI định kỳ để tránh scope creep và khoảng trống trách nhiệm
Ma trận RACI không nên được tạo một lần khi ký hợp đồng rồi để nguyên trong nhiều năm.
Hệ thống IT thay đổi liên tục. Doanh nghiệp có thể mở thêm văn phòng, chuyển lên cloud, triển khai ERP mới, thay firewall, thuê SOC hoặc thay người phụ trách IT.
Mỗi thay đổi như vậy có thể tạo ra một responsibility boundary mới.
Doanh nghiệp nên review RACI khi:
Bắt đầu hoặc gia hạn hợp đồng Helpdesk.
Thay đổi phạm vi dịch vụ.
Thêm site hoặc văn phòng mới.
Triển khai hệ thống quan trọng mới.
Thay đổi nhà cung cấp thứ ba.
Có major incident.
Thay đổi IT Manager hoặc key stakeholder.
Vendor được cấp thêm privileged access.
Trong mỗi kỳ review, cần kiểm tra ít nhất năm câu hỏi:
Người Accountable hiện tại còn đúng không?
Có hệ thống nào chưa có owner rõ ràng không?
Vendor đang có quyền rộng hơn phạm vi trách nhiệm hay không?
Có ticket nào thường xuyên bị chuyển qua lại giữa nhiều bên không?
RACI hiện tại có còn khớp với scope, SLA và quy trình escalation không?
Đối với doanh nghiệp đã có đội IT riêng, bài Thuê ngoài dịch vụ IT hay tự vận hành IT nội bộ? phân tích sâu hơn cách phân chia nguồn lực giữa mô hình in-house, outsource và co-managed. Bài RACI này không thay thế quyết định đó; nó giúp hai bên vận hành rõ trách nhiệm sau khi mô hình đã được chọn.
Trước khi ký hợp đồng, doanh nghiệp cũng nên kiểm tra liệu cách phân công được đề xuất có thực sự tồn tại trong quy trình vận hành của vendor hay chỉ nằm trên proposal. Có thể sử dụng 12 bằng chứng due diligence nhà cung cấp IT Helpdesk để kiểm tra quy trình xử lý ticket, escalation, nhân sự, quyền truy cập và khả năng cung cấp bằng chứng vận hành.
Trước khi ký hợp đồng IT Helpdesk, hãy chốt RACI cùng scope và SLA
Một câu hỏi như “vendor có hỗ trợ network không?” thường chưa đủ.
Doanh nghiệp nên hỏi cụ thể hơn:
Khi network lỗi, vendor trực tiếp xử lý đến bước nào?
Khi cần thay đổi firewall, ai phê duyệt?
Nếu nguyên nhân nằm ở ISP, ai mở case và theo dõi?
Nếu ticket liên quan security, Helpdesk xử lý hay chuyển SOC?
Ai có quyền tạo hoặc nâng privileged account?
Khi xảy ra major incident, ai là Incident Owner?
Ai được quyền chấp thuận emergency change?
Ai thông báo cho ban lãnh đạo và người dùng?
Ai chịu trách nhiệm review recurring issue sau sự cố?
Khi những câu hỏi này được trả lời bằng RACI, doanh nghiệp sẽ có một ranh giới trách nhiệm rõ ràng hơn giữa nội bộ và vendor.
Điều đó giúp giảm ba rủi ro phổ biến: việc không có owner, vendor hành động vượt authority và ticket bị chuyển qua lại giữa nhiều bên.
Tổng kết lại, ma trận RACI IT Helpdesk không phải tài liệu thay thế SLA hay hợp đồng dịch vụ. Nó giải quyết một câu hỏi khác nhưng rất quan trọng: ai thực hiện, ai quyết định, ai cần được tham vấn và ai phải được thông báo trong từng nhóm công việc.
Một RACI phù hợp nên bao phủ ít nhất user support, endpoint, network, vendor bên thứ ba, quyền truy cập, security incident, major incident và change management.
Quan trọng hơn, RACI phải phản ánh đúng mô hình vận hành thực tế. Vendor có thể chịu trách nhiệm xử lý phần lớn ticket, nhưng doanh nghiệp vẫn cần giữ accountability đối với những quyết định ảnh hưởng đến quyền truy cập, rủi ro, production system và hoạt động kinh doanh.
IT Helpdesk & IT Support từ IPSIP Việt Nam
Nếu doanh nghiệp đang chuẩn bị thuê ngoài IT Helpdesk hoặc muốn chuẩn hóa lại cách phối hợp với các vendor hiện tại, IPSIP hỗ trợ doanh nghiệp xây dựng phương án dựa trên hiện trạng thực tế trước khi triển khai dịch vụ IT Helpdesk & IT Support.
Nguồn tham khảo:
