title: "Giai đoạn B (Business Capability): Xây dựng Business Capability Model"
series: "TOGAF Mastery: Kiến trúc sư Doanh nghiệp Chuyên sâu"
part: "Phần 2 — Giải phẫu ADM (Mastering the ADM Cycle)"
order: 14
audience: "Enterprise Architect (EA) & Solutions Architect hướng EA"
reading_time: "13 phút"
tags:

• TOGAF
• ADM
• Business Architecture
• Business Capability Model
• Enterprise Architecture
• Giai đoạn B

Giai đoạn B (Business Capability): Xây dựng Business Capability Model

Một tập đoàn bán lẻ tôi từng làm việc cùng có ba phòng ban báo cáo với ba Giám đốc khác nhau, cùng lúc triển khai ba dự án "quản lý khách hàng thân thiết" độc lập: Marketing xây một hệ thống loyalty cho kênh app, Sales xây một CRM tích điểm cho kênh đại lý, Chăm sóc khách hàng xây một module ghi nhận ưu đãi cho kênh contact center. Ba ngân sách riêng, ba vendor riêng, ba database khách hàng riêng — và không ai trong ba đội biết về sự tồn tại của hai đội còn lại cho đến khi phòng Tài chính hỏi tại sao chi phí "customer loyalty" xuất hiện ba lần trong ba dòng ngân sách khác nhau của cùng một năm.

Đây không phải lỗi của ai cả. Đó là hệ quả tất yếu của một doanh nghiệp không có bản đồ năng lực chung. Mỗi phòng ban nhìn thấy "công việc của mình" qua lăng kính tổ chức và quy trình riêng, và khi không có một ngôn ngữ trung lập để nói "chúng ta đang xây cùng một khả năng", trùng lặp là điều không thể tránh. Value Stream Mapping ở bài trước cho ta thấy dòng chảy giá trị end-to-end xuyên chức năng — nhưng Value Stream trả lời "hành trình tạo ra giá trị ra sao", còn có một câu hỏi nền tảng hơn mà Value Stream không trả lời trực tiếp: doanh nghiệp này, xét đến tận cùng, CÓ THỂ LÀM ĐƯỢC NHỮNG GÌ? Đó là câu hỏi của Business Capability Model — công cụ mà tôi cho là artifact quan trọng bậc nhất trong toàn bộ TOGAF ADM, vì nó là thứ duy nhất đủ ổn định để làm "hệ quy chiếu" khi mọi thứ khác — tổ chức, quy trình, hệ thống — liên tục thay đổi.

Bản chất

Business Capability là "khả năng mà doanh nghiệp sở hữu hoặc cần sở hữu để đạt được mục tiêu kinh doanh" — một cách diễn đạt trừu tượng, ổn định về việc doanh nghiệp CÓ THỂ LÀM GÌ, độc lập với việc AI làm, LÀM NHƯ THẾ NÀO, hay bằng CÔNG CỤ nào. "Quản lý Đơn hàng" là một capability. "Đánh giá Rủi ro Tín dụng" là một capability. "Quản lý Quan hệ Khách hàng Thân thiết" là một capability.

Ba nguyên tắc bắt buộc để phân biệt Capability với những khái niệm hay bị nhầm lẫn:

Capability không phải là phòng ban (Organization Unit). Phòng Marketing có thể đóng góp vào nhiều capability (Quản lý Thương hiệu, Quản lý Khách hàng Thân thiết, Phân tích Thị trường), và một capability như "Quản lý Khách hàng Thân thiết" có thể cần đóng góp từ Marketing, Sales, CSKH. Nếu bạn vẽ Capability Model mà mỗi ô trùng khớp 1-1 với một phòng ban trên sơ đồ tổ chức, bạn đang vẽ lại org chart chứ không phải Capability Model — và bạn đã đánh mất toàn bộ giá trị của bài tập này.

Capability không phải là quy trình (Business Process). Quy trình mô tả TRÌNH TỰ HÀNH ĐỘNG — "Nhận đơn → Kiểm tra tồn kho → Xác nhận → Giao hàng". Capability là DANH TỪ, không phải ĐỘNG TỪ theo trình tự: "Quản lý Đơn hàng". Một capability có thể được hiện thực hóa bởi nhiều quy trình khác nhau ở các đơn vị kinh doanh khác nhau, và quy trình có thể thay đổi liên tục theo sáng kiến cải tiến — trong khi capability gần như không đổi tên qua nhiều năm. Đây chính là lý do Capability Model được coi là artifact ổn định nhất trong Business Architecture: tái cơ cấu tổ chức, chuyển đổi quy trình BPR, hay thay hệ thống ERP đều không làm thay đổi việc doanh nghiệp "có khả năng Quản lý Đơn hàng" — chỉ thay đổi CÁCH capability đó được thực thi.

Capability không phải là ứng dụng/hệ thống. Một capability có thể chưa được hệ thống hóa (thực hiện thủ công qua Excel và email) và vẫn là một capability hợp lệ. Việc ánh xạ "hệ thống nào phục vụ capability nào" là công việc của Giai đoạn C (Application Portfolio) — Capability Model ở Giai đoạn B phải được xây dựng TRƯỚC và ĐỘC LẬP với việc hệ thống hóa, chính vì vậy nó mới đóng vai trò trung lập làm khung tham chiếu.

Câu hỏi trắc nghiệm nhanh mà tôi hay dùng khi review với đội kiến trúc: nếu tên gọi bắt đầu bằng động từ hành động cụ thể theo trình tự thời gian ("Nhận, Kiểm tra, Duyệt") — đó là process. Nếu tên gọi là một cụm danh từ mô tả khả năng trừu tượng ("Quản lý", "Đánh giá", "Phân tích" + đối tượng) và không đổi dù quy trình bên dưới có tái thiết kế — đó là capability.

Khung & Kỹ thuật áp dụng

Business Capability Model được xây theo cấu trúc phân cấp (hierarchical decomposition), thường 3 cấp là đủ cho phần lớn doanh nghiệp cỡ vừa và lớn; doanh nghiệp rất phức tạp có thể cần đến Level 4.

Quy trình xây dựng theo trình tự thực chiến, không phải lý thuyết:

1. Xuất phát từ Value Stream đã vẽ ở bài trước — mỗi Value Stage thường ánh xạ tới một hoặc vài capability then chốt. Đây là input trực tiếp, tránh việc "vẽ capability từ trên trời" thiếu gắn kết với giá trị thực tế.
2. Workshop cross-functional bắt buộc — không bao giờ để một phòng ban tự vẽ capability của "lãnh địa" mình. Phải có đại diện từ ít nhất Kinh doanh, Vận hành, CNTT, và một stakeholder cấp Giám đốc/C-level để phá vỡ tư duy silo. Đây chính là công cụ hóa giải case trùng lặp đầu bài.
3. Đặt tên theo chuẩn Danh từ + Tính từ bổ nghĩa, tránh động từ hành động, tránh gắn brand/hệ thống cụ thể ("Quản lý CRM Salesforce" là sai — hãy gọi "Quản lý Quan hệ Khách hàng").
4. Kiểm tra tính đầy đủ và không trùng lặp (MECE — Mutually Exclusive, Collectively Exhaustive) ở từng cấp: một hoạt động kinh doanh chỉ nên thuộc về đúng một capability, và toàn bộ hoạt động của doanh nghiệp phải được bao phủ.
5. Gán chủ sở hữu nghiệp vụ (Capability Owner) cho mỗi Level 1 — đây là vai trò trách nhiệm giải trình (accountability) về sức khỏe của capability đó, không nhất thiết trùng với một chức danh quản lý hiện có.
6. Thẩm định (Heat Map) mức trưởng thành và mức độ quan trọng chiến lược cho từng capability — dùng thang điểm đơn giản (ví dụ 1-5) đánh giá hai trục: Business Value (giá trị chiến lược) và Current Maturity/Health (mức trưởng thành hiện tại: quy trình, con người, công nghệ, dữ liệu). Đây là input trực tiếp cho việc ưu tiên đầu tư ở Giai đoạn E.

Một kỹ thuật bổ trợ quan trọng: Capability-to-Strategy Mapping — với mỗi mục tiêu chiến lược (đã xác định ở Giai đoạn A), liệt kê capability nào cần được nâng cấp/đầu tư để hiện thực hóa mục tiêu đó. Đây là cầu nối biến Business Capability Model từ một bài tập học thuật thành công cụ ra quyết định đầu tư thực sự có sức nặng trước Ban điều hành.

Case thực tế minh hoạ

(Case minh hoạ điển hình tổng hợp, không phải case của một công ty cụ thể có thật, số liệu chỉ mang tính minh hoạ tương đối.)

Một doanh nghiệp bán lẻ đa kênh (giả định) đang trong giai đoạn D của ADM cho một sáng kiến chuyển đổi số toàn diện. Khi đội kiến trúc tổ chức workshop xây Business Capability Model ở Giai đoạn B, họ phát hiện dưới Level 1 capability "Quản lý Quan hệ Khách hàng Thân thiết" (thuộc domain "Quản trị Khách hàng"), có ba đầu mối đang cùng lúc đầu tư cho cùng một sub-capability "Quản lý Điểm thưởng & Ưu đãi":

• Phòng Marketing đã ký hợp đồng với một vendor loyalty platform quốc tế cho kênh ứng dụng di động, chi phí license hàng năm đáng kể.
• Phòng Kinh doanh (kênh đại lý) đang thuê một đội phát triển nội bộ xây module tích điểm riêng tích hợp vào hệ thống quản lý đại lý sẵn có.
• Phòng Chăm sóc khách hàng dùng một add-on của phần mềm tổng đài để ghi nhận và áp dụng ưu đãi thủ công khi khách gọi lên.

Khi ba mũi tên này được đặt cạnh nhau trên cùng một ô capability trong bản đồ, sự trùng lặp trở nên hiển nhiên theo cách mà không một cuộc họp ngân sách riêng lẻ nào từng lộ ra: cùng một khả năng kinh doanh — "biết khách hàng này đang ở hạng nào, có bao nhiêu điểm, được hưởng ưu đãi gì" — đang được ba hệ thống độc lập, ba nguồn dữ liệu khách hàng không đồng bộ, và quan trọng nhất là TRẢI NGHIỆM KHÁCH HÀNG BỊ PHÂN MẢNH: khách tích điểm trên app nhưng đại lý không nhìn thấy, gọi tổng đài thì nhân viên không biết khách đã có ưu đãi gì trên app.

Điểm mấu chốt về mặt phương pháp: chính vì Business Capability Model được vẽ độc lập với tổ chức và hệ thống hiện có, đội kiến trúc mới "nhìn xuyên" được qua ranh giới phòng ban để thấy bản chất giống nhau của ba khoản đầu tư này. Nếu chỉ nhìn qua lăng kính "dự án của phòng Marketing" so với "dự án của phòng Kinh doanh", không ai nghĩ chúng liên quan — vì tên dự án khác nhau, KPI khác nhau, ngân sách khác nhau. Nhưng dưới góc nhìn capability, chúng là MỘT.

Từ phát hiện này, đội kiến trúc đề xuất hợp nhất thành một nền tảng Customer Loyalty & Rewards dùng chung, phục vụ cả ba kênh qua API thống nhất — vừa loại bỏ chi phí trùng lặp về license và nhân sự phát triển, vừa giải quyết tận gốc vấn đề trải nghiệm khách hàng phân mảnh. Đây chính là dạng phát hiện mà Business Capability Model tạo ra giá trị lớn nhất: không phải bằng cách vẽ đẹp, mà bằng cách làm lộ ra những khoản đầu tư trùng lặp ẩn dưới các ranh giới tổ chức.

📐 Template/Artifact áp dụng ngay

Business Capability Heat Map Register — bảng dùng để kiểm kê, đánh giá và ưu tiên capability, có thể copy trực tiếp vào Excel/Confluence và bắt đầu điền:

Quy tắc điền tối thiểu bắt buộc:

• Mỗi Level 1 capability PHẢI có đúng một Capability Owner (không được để trống, không được gán cho một nhóm chung chung).
• Cột "Đơn vị/phòng ban đóng góp" liệt kê TẤT CẢ đơn vị có hoạt động thuộc capability này — cột này chính là công cụ phát hiện trùng lặp: nếu nhiều dòng cùng Capability ID xuất hiện với hệ thống hỗ trợ khác nhau từ các phòng ban khác nhau, đó là tín hiệu đỏ cần điều tra.
• Business Value và Maturity chấm điểm theo thang thống nhất toàn công ty (định nghĩa rõ 1-5 nghĩa là gì trước khi workshop, tránh mỗi người hiểu một kiểu).
• Capability có Business Value cao (4-5) nhưng Maturity thấp (1-2) là vùng ưu tiên đầu tư số một — đây chính là logic ưu tiên hóa chuẩn TOGAF cho Giai đoạn E sau này.

🎯 Góc nhìn Chief EA
Nếu tôi xóa hết tên phòng ban và tên hệ thống khỏi bản đồ này, doanh nghiệp còn lại BAO NHIÊU khả năng thực sự khác biệt — và con số đó có khớp với số lượng nền tảng công nghệ chúng ta đang vận hành không?
Capability nào có Business Value cao nhất nhưng đang được từ hai đơn vị trở lên tự ý đầu tư riêng lẻ mà không ai biết về nhau?
Nếu một Capability Owner nghỉ việc ngày mai, ai là người còn lại có đủ thẩm quyền nói "không" với một dự án trùng lặp sắp được phê duyệt?
Bản đồ capability này được cập nhật lần cuối khi nào — và nếu câu trả lời là "hơn một năm trước", nó còn đáng tin để ra quyết định đầu tư hôm nay không?

🔄 Vị trí trong chu trình ADM

Việc xây Business Capability Model diễn ra trong Giai đoạn B — Business Architecture, và bổ trợ trực tiếp cho Value Stream Mapping đã thực hiện ở Giai đoạn B (Business Architecture). Hai artifact này cùng thuộc Giai đoạn B nhưng trả lời hai câu hỏi bổ sung cho nhau: Value Stream cho biết "giá trị chảy qua doanh nghiệp như thế nào", còn Capability Model cho biết "doanh nghiệp có những khả năng gì để tạo ra dòng chảy đó".

• Nhận đầu vào từ: Value Stream đã vẽ — mỗi Value Stage là điểm khởi đầu để nhận diện capability nào đang được kích hoạt tại giai đoạn đó của hành trình giá trị.
• Cho đầu ra sang: Giai đoạn C — Information Systems Architecture (bài 15-16, đặc biệt là Application Portfolio ở bài 16) — Business Capability Model chính là khung tham chiếu trung lập để ánh xạ "ứng dụng nào đang phục vụ năng lực nào", từ đó phát hiện các vùng trùng lặp ứng dụng (như case ở trên) hoặc các capability chưa có hệ thống hỗ trợ (gap cần đầu tư mới).

🔗 Bài viết liên quan

• Giai đoạn B (Business Architecture): Value Stream Mapping — artifact song sinh của Capability Model trong Giai đoạn B, cung cấp góc nhìn "dòng chảy giá trị" bổ sung cho góc nhìn "khả năng tĩnh".
• Giai đoạn C (Application): Application Portfolio — nơi Capability Model được dùng làm khung ánh xạ ứng dụng, phát hiện trùng lặp và gap đầu tư công nghệ.

Bài trước: Giai đoạn B (Business Architecture) · Bài tiếp theo: Giai đoạn C (Information Systems Architecture)