INFOCHIEF ACADEMY · IT MANAGER KNOWLEDGE SERIES

Thiết kế cơ cấu tổ chức IT: Phân chia chức năng, nhiệm vụ và trách nhiệm như thế nào?

Không có một sơ đồ tổ chức IT “chuẩn” phù hợp cho mọi doanh nghiệp. Cùng quy mô nhân sự, một công ty sản xuất, ngân hàng và doanh nghiệp SaaS có thể cần cách tổ chức hoàn toàn khác nhau. Câu hỏi đúng không phải “nên có bao nhiêu team”, mà là “dịch vụ, năng lực và quyết định nào cần được sở hữu rõ để hỗ trợ doanh nghiệp”.

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: Sơ đồ cơ cấu tổ chức bộ phận IT theo chức năng, dịch vụ và trách nhiệm quản lý.

Đừng bắt đầu từ sơ đồ hộp: hãy bắt đầu từ công việc tổ chức phải chịu trách nhiệm

Sai lầm phổ biến khi tái cơ cấu IT là vẽ sơ đồ dựa trên con người hiện có: ai đang mạnh hạ tầng thì lập team hạ tầng, ai biết ứng dụng thì lập team ứng dụng, ai lâu năm nhất thì làm trưởng nhóm. Cách này dễ triển khai nhưng có thể để lại khoảng trống trách nhiệm như quản lý dịch vụ đầu-cuối, kiến trúc, dữ liệu, nhà cung cấp hoặc an toàn thông tin.

Thiết kế tổ chức nên bắt đầu từ ba bản đồ: danh mục dịch vụ IT, các năng lực cần có và các quyết định phải được đưa ra. Từ đó mới xác định nhóm chức năng, vai trò, reporting line và cơ chế phối hợp. Với bộ phận nhỏ, một người có thể kiêm nhiều vai; nhưng trách nhiệm vẫn cần được định nghĩa tách biệt.

Chuyên đề Quản Lý Bộ Phận – Phòng Ban IT của Infochief có thể được dùng như tài liệu thực hành để chuẩn hóa chức năng, quy trình và KPI sau khi cơ cấu được xác định.

Bốn nguyên tắc thiết kế cơ cấu IT có thể thích ứng với tăng trưởng

Bám vào dịch vụ và giá trị: cơ cấu phải giúp một người hoặc nhóm chịu trách nhiệm rõ cho dịch vụ quan trọng, không chỉ cho công nghệ thành phần.
Tách quyền kiểm soát khi cần: bảo mật, phê duyệt thay đổi, kiểm toán hoặc quản trị kiến trúc cần mức độc lập phù hợp để tránh xung đột lợi ích.
Giảm số điểm bàn giao: quá nhiều nhóm chuyên môn sâu có thể tạo handoff, chờ đợi và đổ lỗi. Thiết kế phải cân bằng chuyên môn hóa với flow đầu-cuối.
Thiết kế theo năng lực tương lai: nếu doanh nghiệp chuyển sang cloud, data hoặc product model, cơ cấu không thể chỉ phản ánh công nghệ legacy hiện tại.

Các nguyên tắc này tương thích với góc nhìn quản trị của ISO/IEC 38500 và tư duy đa chiều của ITIL về tổ chức-con người, công nghệ, đối tác và luồng giá trị. Chúng giúp IT Manager tránh coi org chart là bài toán hành chính thuần túy.

Các nhóm chức năng điển hình và trách nhiệm cần xác định

Năng lực/chức năng	Trách nhiệm chính	Rủi ro nếu không rõ owner
Service Management / Service Desk	tiếp nhận nhu cầu, SLA/XLA, incident/request, cải tiến	người dùng bị chuyển vòng, không ai sở hữu trải nghiệm
Infrastructure / Cloud	compute, network, platform, capacity, resilience	tối ưu cục bộ, thiếu kế hoạch năng lực
Applications / Integration	ứng dụng nghiệp vụ, tích hợp, lifecycle	phân mảnh ứng dụng, thay đổi khó kiểm soát
Data	data quality, ownership, platform, analytics support	dữ liệu rời rạc, không rõ trách nhiệm
Cybersecurity	risk, control, monitoring, response	xung đột giữa tốc độ và kiểm soát
Projects / Change	portfolio, project delivery, change coordination	nhiều sáng kiến cạnh tranh nguồn lực
Governance / Architecture / Vendor	standards, decision rights, supplier performance	đầu tư manh mún, phụ thuộc nhà cung cấp

Không phải doanh nghiệp nào cũng cần bảy phòng riêng. Mục đích của bảng là xác định capability. Với đội 10 người, một người có thể vừa quản lý network vừa quản lý cloud; một IT Manager có thể trực tiếp sở hữu governance. Khi quy mô tăng, các capability có thể tách thành team hoặc role chuyên trách.

Nếu tổ chức sử dụng nhiều dịch vụ thuê ngoài, thiết kế nội bộ càng phải rõ về service ownership, vendor management và architecture. Outsourcing công việc không đồng nghĩa outsourcing trách nhiệm. Nội dung Quản Lý Mua Sắm & Nhà Cung Cấp IT hữu ích khi cơ cấu cần mở rộng ra hệ sinh thái đối tác.

Chọn mô hình tập trung, phân tán hay liên kết theo sản phẩm/dịch vụ

Mô hình tập trung phù hợp khi doanh nghiệp cần chuẩn hóa, kiểm soát chi phí và có quy mô chưa lớn. Mô hình phân tán gần business unit tạo tốc độ và hiểu nghiệp vụ nhưng dễ trùng lặp công nghệ. Mô hình liên kết hoặc federated cố gắng giữ nền tảng, tiêu chuẩn và governance ở trung tâm trong khi product/domain team gần với nghiệp vụ.

Mô hình	Ưu điểm	Điều kiện cần
Tập trung	chuẩn hóa, dễ kiểm soát, tối ưu chuyên môn	cơ chế ưu tiên minh bạch để business không cảm thấy xa IT
Phân tán theo đơn vị	gần nghiệp vụ, phản hồi nhanh	architecture và security guardrails đủ mạnh
Federated / product-aligned	cân bằng tốc độ và chuẩn chung	decision rights, platform ownership và funding model rõ

IT Manager không nên chọn mô hình theo xu hướng. Hãy nhìn vào quy mô, mức đa dạng nghiệp vụ, tốc độ thay đổi, yêu cầu kiểm soát và khả năng lãnh đạo của các trưởng nhóm. Cơ cấu là phương tiện để ra quyết định và giao trách nhiệm tốt hơn, không phải mục tiêu tự thân.

Thiết kế vai trò và giao diện phối hợp: nơi org chart thường bỏ sót

Mỗi role nên có ba lớp mô tả: outcome chịu trách nhiệm, decision rights và interfaces. Job description chỉ liệt kê nhiệm vụ thường không đủ. Ví dụ, Service Owner không chỉ “theo dõi SLA”; role này cần quyền triệu tập review, yêu cầu action từ team kỹ thuật và escalated khi dịch vụ có rủi ro vượt ngưỡng.

Các giao diện quan trọng cần được thiết kế rõ: Service Desk ↔ technical team, Security ↔ project, Infrastructure ↔ Applications, IT ↔ business owner, IT ↔ vendor. Ở mỗi giao diện, xác định đầu vào, output, thời hạn, dữ liệu và ai có quyền quyết định.

Khi trách nhiệm chồng chéo, RACI có thể là công cụ hỗ trợ, nhưng RACI chỉ hiệu quả sau khi scope và decision point đã rõ. Bài Áp dụng RACI để giải quyết chồng chéo trách nhiệm đi sâu vào cách dùng công cụ này.

Tình huống minh họa: bộ phận IT lớn lên nhưng vẫn vận hành như một nhóm kỹ thuật nhỏ

Tình huống giả định: doanh nghiệp tăng từ 300 lên 1.200 nhân viên. Đội IT tăng từ 8 lên 25 người nhưng cơ cấu vẫn theo “ai biết gì làm nấy”. Khi có sự cố ERP, hạ tầng kiểm tra server, ứng dụng kiểm tra code, vendor kiểm tra database; không ai sở hữu toàn bộ dịch vụ nên thời gian phối hợp dài.

IT Manager thiết kế lại theo service ownership. ERP có Service Owner chịu trách nhiệm đầu-cuối; technical team vẫn giữ chuyên môn. Incident Manager điều phối sự cố nghiêm trọng; Security có điểm kiểm soát độc lập; vendor được đưa vào RACI và SLA. Org chart thay đổi ít hơn dự kiến, nhưng decision rights và interface thay đổi mạnh.

Bài học: cải tổ tổ chức không nhất thiết bắt đầu bằng thay đổi chức danh. Nhiều vấn đề được giải quyết bằng cách làm rõ owner, quyền quyết định, quy trình phối hợp và tiêu chí escalation.

Span of control và năng lực trưởng nhóm

Một điểm ít được chú ý trong org design là số lượng người và độ phức tạp role mà một quản lý trực tiếp có thể hỗ trợ. Span quá rộng khiến quản lý chỉ còn thời gian chữa cháy; span quá hẹp tạo tầng quản lý không cần thiết. Không có một con số cố định phù hợp mọi tổ chức. Cần xem mức tự chủ của nhân viên, độ đa dạng công việc, mức biến động và khả năng chuẩn hóa quy trình.

Khi trưởng nhóm chưa đủ năng lực, việc tách thêm team có thể làm tăng số điểm ra quyết định nhưng không cải thiện chất lượng quản lý. Do đó org design phải đi cùng leadership pipeline: xác định role leader, năng lực cần có, cơ chế delegation và succession. Cơ cấu chỉ vận hành tốt khi người giữ vai trò có đủ thẩm quyền và kỹ năng.

Checklist thiết kế cơ cấu tổ chức IT

Danh mục dịch vụ trọng yếu có owner đầu-cuối.
Các capability cần thiết hiện tại và 2–3 năm tới đã được xác định.
Quyền quyết định về kiến trúc, bảo mật, thay đổi và vendor có chủ sở hữu rõ.
Không có quá nhiều handoff cho một luồng công việc phổ biến.
Trưởng nhóm có phạm vi quản lý và span phù hợp; không quản quá nhiều role không liên quan.
Cơ cấu thể hiện cả nội bộ và đối tác ngoài nếu phụ thuộc lớn vào outsource/cloud.
Có cơ chế review định kỳ để điều chỉnh cơ cấu khi chiến lược hoặc quy mô thay đổi.

Sau khi org chart được chốt, nên cập nhật RACI, job description, service ownership, escalation matrix và KPI. Nếu chỉ công bố sơ đồ mới mà không thay các cơ chế này, hành vi vận hành cũ sẽ nhanh chóng quay lại.

Kết luận: thiết kế tổ chức là thiết kế trách nhiệm và khả năng phối hợp

Cơ cấu IT hiệu quả không được đo bằng số tầng quản lý hay số team, mà bằng khả năng đưa quyết định xuống đúng cấp, sở hữu dịch vụ rõ, phối hợp nhanh và phát triển năng lực theo định hướng doanh nghiệp. Một cơ cấu nhỏ nhưng rõ trách nhiệm có thể vận hành tốt hơn một cơ cấu lớn nhiều chức danh.

IT Manager nên xem org design là một hệ thống sống. Khi danh mục dịch vụ, công nghệ, nhà cung cấp và ưu tiên kinh doanh thay đổi, cơ cấu và decision rights cũng cần được xem lại.

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ụ, trách nhiệm và tổ chức công việc. Nội dung bài viết là diễn giải ứng dụng của Infochief Academy.