INFOCHIEF ACADEMY · CIO KNOWLEDGE SERIES

Xây dựng IT Operating Model: Tổ chức bộ phận IT theo năng lực, dịch vụ và giá trị kinh doanh.

Một bộ phận IT có thể có đủ hạ tầng, ứng dụng, bảo mật và đội ngũ vận hành nhưng vẫn phản ứng chậm trước nhu cầu kinh doanh. Vấn đề thường không nằm ở thiếu công nghệ mà ở cách tổ chức năng lực, quyền quyết định và dịch vụ. Bài viết này giúp CIO thiết kế IT Operating Model để biến cấu trúc IT thành một cơ chế tạo giá trị có thể vận hành và đo lường.

Biên soạn: Infochief Academy · Chuyên đề: Giám đốc Công nghệ Thông tin – CIO

← Trở về danh mục CIO

CIO trình bày IT Operating Model theo năng lực, dịch vụ và giá trị kinh doanh
Minh họa biên tập cho chủ đề Xây dựng IT Operating Model: Tổ chức bộ phận IT theo năng lực, dịch vụ và giá trị kinh doanh.

Operating Model không phải sơ đồ tổ chức

Nhiều doanh nghiệp bắt đầu bằng việc vẽ lại sơ đồ phòng ban: hạ tầng, ứng dụng, bảo mật, dữ liệu, helpdesk. Cách này mô tả ai đang ngồi ở đâu, nhưng chưa trả lời được IT tạo giá trị bằng cách nào. Một IT Operating Model phải mô tả cách chiến lược được chuyển thành năng lực, dịch vụ, quyền quyết định, luồng công việc và cơ chế đo lường.

Điểm khác biệt quan trọng là chuyển từ tư duy “quản lý tài nguyên kỹ thuật” sang “vận hành một hệ thống cung cấp năng lực và dịch vụ”. Khi đó CIO không chỉ hỏi bộ phận nào phụ trách máy chủ, mà phải hỏi dịch vụ nào đang bảo vệ doanh thu, năng lực nào cần phát triển và ai có quyền quyết định khi ưu tiên xung đột.

Đây là bước nối giữa chiến lược CIO và năng lực thực thi của Trưởng Phòng IT Chuyên Nghiệp – IT Manager, bởi mô hình chỉ có ý nghĩa khi được chuyển thành trách nhiệm, quy trình và KPI hằng ngày.

Bắt đầu từ giá trị, không bắt đầu từ chức danh

Thiết kế Operating Model nên đi từ các kết quả doanh nghiệp cần bảo vệ hoặc cải thiện: tăng tốc ra thị trường, vận hành liên tục, nâng trải nghiệm khách hàng, giảm rủi ro, hỗ trợ mở rộng quy mô. Từ đó xác định các dịch vụ và năng lực IT cần thiết.

Giá trị kinh doanhDịch vụ IT liên quanNăng lực cần có
Hoạt động liên tụcAvailability, Incident, DRObservability, recovery, crisis coordination
Tăng tốc phát triển sản phẩmPlatform, integration, releaseArchitecture, DevOps, automation
Kiểm soát rủi roSecurity, identity, complianceRisk, IAM, monitoring, assurance
Tối ưu chi phíCloud, asset, vendorFinOps, sourcing, demand management

Cách tiếp cận này giúp tránh việc mỗi nhóm kỹ thuật tự tối ưu mục tiêu riêng. Một đội hạ tầng có thể tối ưu độ ổn định, một đội ứng dụng tối ưu tốc độ thay đổi; Operating Model phải làm rõ cách hai mục tiêu đó được cân bằng theo ưu tiên kinh doanh.

Năm thành phần CIO cần thiết kế đồng bộ

Một mô hình vận hành thực dụng có thể được kiểm tra qua năm thành phần: capabilities, services, decision rights, ways of working và performance management.

  1. Capabilities: tổ chức có đủ con người, quy trình và công nghệ để làm điều cần làm hay chưa?
  2. Services: IT đang cung cấp những dịch vụ nào, cho ai, với mức cam kết nào?
  3. Decision rights: quyết định nào thuộc CIO, kiến trúc, security, product owner hay business owner?
  4. Ways of working: công việc đi qua demand, design, delivery, change và operations như thế nào?
  5. Performance management: đo hiệu suất theo hoạt động hay theo kết quả và giá trị?

Nếu một thành phần thay đổi mà bốn thành phần còn lại không đổi, tổ chức dễ phát sinh “lệch mô hình”. Ví dụ chuyển sang product team nhưng ngân sách, KPI và quyền kiến trúc vẫn quản lý theo dự án truyền thống sẽ tạo xung đột liên tục.

Chọn mô hình tập trung, liên kết hay nền tảng

Không có một cấu trúc phù hợp cho mọi doanh nghiệp. Tổ chức nhỏ hoặc môi trường kiểm soát cao có thể dùng mô hình tập trung. Doanh nghiệp đa ngành thường cần mô hình liên kết: năng lực nền tảng và governance tập trung, trong khi các nhóm business technology nằm gần đơn vị kinh doanh. Các tổ chức số trưởng thành hơn có thể phát triển platform teams cung cấp năng lực dùng chung như một sản phẩm nội bộ.

AWS và Microsoft đều nhấn mạnh operating model phải làm rõ năng lực, trách nhiệm, governance và mối quan hệ giữa platform với workload teams. Điều CIO cần tránh là sao chép mô hình “cloud-native” khi tổ chức chưa có nền tảng kỹ năng, tài chính hoặc quản trị tương ứng.

Thiết kế quyền quyết định trước khi thiết kế quy trình

Nhiều quy trình IT dài không phải do quá nhiều bước kỹ thuật, mà vì không rõ ai có quyền quyết định. Trước khi tối ưu workflow, CIO nên lập decision inventory cho các quyết định như: phê duyệt kiến trúc, chấp nhận rủi ro, lựa chọn nhà cung cấp, ưu tiên demand, go-live, ngoại lệ bảo mật và dừng dịch vụ.

RACI chỉ hữu ích khi được gắn với loại quyết định cụ thể và ngưỡng thẩm quyền. Với các dự án lớn, năng lực quản trị trong chương trình Giám Đốc Dự Án IT – Project Manager giúp biến quyền quyết định thành stage-gate và escalation có thể vận hành.

Tình huống minh họa: IT đủ người nhưng vẫn chậm

Tình huống minh họa: một doanh nghiệp có các nhóm hạ tầng, ứng dụng và bảo mật riêng biệt. Mỗi yêu cầu tích hợp phải đi qua ba hàng đợi, mỗi nhóm có KPI riêng và không ai sở hữu thời gian end-to-end. Kết quả là từng nhóm đều “đúng SLA” nhưng business chờ nhiều tuần.

CIO tái thiết kế mô hình theo dịch vụ tích hợp, chỉ định service owner, xác định một backlog chung và thiết lập platform capability dùng lại. KPI chuyển từ số ticket xử lý sang lead time, tỷ lệ reuse và mức đáp ứng kết quả nghiệp vụ. Điều thay đổi không phải số nhân sự mà là cấu trúc trách nhiệm và luồng giá trị.

Roadmap 90 ngày để thiết kế lại Operating Model

  1. Tuần 1–3: lập bản đồ dịch vụ, capability và pain point ra quyết định.
  2. Tuần 4–6: xác định target model, service ownership và decision rights.
  3. Tuần 7–9: thử nghiệm trên 1–2 value streams có vấn đề rõ.
  4. Tuần 10–12: điều chỉnh KPI, governance, vendor model và vai trò quản lý.
  5. Sau 90 ngày: mở rộng theo bằng chứng, không triển khai đồng loạt chỉ vì sơ đồ đã được phê duyệt.

Đối với CIO mới nhận vai trò, có thể liên kết cách tiếp cận này với chuyên đề 90 Ngày Lãnh Đạo IT để biến chẩn đoán tổ chức thành chương trình hành động có nhịp độ.

Checklist: Operating Model có thực sự vận hành?

  • Dịch vụ trọng yếu có owner rõ ràng.
  • Năng lực dùng chung không bị nhân bản vô kiểm soát.
  • Quyền quyết định và ngưỡng escalation được công bố.
  • KPI có chỉ số end-to-end, không chỉ KPI từng silo.
  • Business owner tham gia ưu tiên demand và xác nhận giá trị.
  • Nhà cung cấp được tích hợp vào cùng cơ chế service governance.
  • Mô hình có cơ chế xem xét lại khi chiến lược thay đổi.

Hành động nên bắt đầu: chọn một dịch vụ có nhiều bàn giao giữa các nhóm, vẽ lại luồng từ nhu cầu đến kết quả và xác định nơi trách nhiệm hoặc quyền quyết định đang bị đứt gãy.

Những chỉ số cho thấy Operating Model đang tạo giá trị

Sau khi tái thiết kế, CIO cần đo xem mô hình mới có thực sự cải thiện cách doanh nghiệp vận hành hay chỉ thay tên phòng ban. Một số chỉ số hữu ích gồm lead time từ demand đến production, số lần bàn giao giữa các nhóm, tỷ lệ dịch vụ có owner, tỷ lệ reuse platform, change failure rate, mức hài lòng của business owner và chi phí trên mỗi đơn vị dịch vụ. Không cần dùng tất cả cùng lúc; nên chọn một tập nhỏ phản ánh đúng bottleneck cần xử lý.

Quan trọng hơn là so sánh xu hướng trước và sau thay đổi. Nếu cơ cấu mới giảm handoff nhưng thời gian phê duyệt vẫn kéo dài, vấn đề có thể nằm ở decision rights chứ không phải organization design. Nếu platform reuse tăng nhưng chi phí support tăng mạnh, CIO cần xem lại service boundaries hoặc khả năng tự phục vụ.

Operating Model cũng phải được review khi chiến lược thay đổi. Một mô hình phù hợp cho giai đoạn chuẩn hóa chi phí có thể không phù hợp khi doanh nghiệp bước vào giai đoạn M&A, mở sản phẩm số hoặc tăng tốc AI. Do đó, nên coi Operating Model là một hệ thống sống với chu kỳ đánh giá định kỳ, thay vì một dự án tái cơ cấu hoàn thành một lần.

Kết luận: tổ chức IT quanh luồng giá trị, không quanh công nghệ

IT Operating Model tốt không cố xóa mọi chuyên môn kỹ thuật. Nó giữ chuyên môn nhưng làm rõ cách các năng lực chuyên sâu phối hợp để tạo dịch vụ và kết quả kinh doanh. CIO cần thiết kế đồng thời cấu trúc, service ownership, quyền quyết định, cách làm việc và cơ chế đo lường.

Nếu phải chọn một nguyên tắc duy nhất để bắt đầu, hãy chọn: mỗi năng lực và vai trò IT phải trả lời được nó đóng góp vào luồng giá trị nào và quyết định nào. Khi câu trả lời rõ, sơ đồ tổ chức sẽ trở thành hệ quả của operating logic, không phải điểm xuất phát.

Nguồn tham khảo

  1. AWS – Cloud Operating Model overview
  2. Microsoft – Choose a cloud operating model
  3. ISO/IEC 38500:2024 – Governance of IT for the organization
  4. ISACA – COBIT resources

Các nguồn trên được dùng làm tài liệu tham khảo cho nguyên tắc quản trị và phương pháp. Nội dung bài viết là diễn giải ứng dụng của Infochief Academy.