OLB #04 — Organization Structure & Governance: Từ Capability đến Accountability

[GIẢ LẬP · PHỤC VỤ NGHIÊN CỨU & ĐÀO TẠO]

Ở OLB #01, Odin Lab Bank bắt đầu bằng Mission, Vision và Strategy. OLB #02 chuyển chiến lược thành Enterprise Architecture. OLB #03 trả lời câu hỏi: ngân hàng cần có những năng lực gì để thực hiện chiến lược? Đến OLB #04, câu hỏi chuyển từ “What must the bank be able to do?” sang một vấn đề khó hơn: Ai thực sự chịu trách nhiệm, ai có quyền quyết định và dựa trên bằng chứng nào?

Strategy → Capability → Service → Accountability → Governance → Organization

1. Đừng bắt đầu bằng sơ đồ tổ chức

Một cách tiếp cận quen thuộc là bắt đầu từ CEO, sau đó chia thành các khối, ban, phòng và nhóm. Cách này dễ hình dung nhưng có thể tạo ra một organigram đẹp mà vẫn không trả lời được ba câu hỏi: ai sở hữu capability, ai chịu trách nhiệm về business service và ai có quyền đưa ra quyết định?

OLB đi theo chiều ngược lại:

Strategy → Capability → Accountability → Organization

Tổ chức là kết quả của thiết kế trách nhiệm, không phải điểm xuất phát. Capability Map của OLB #03 vì vậy trở thành đầu vào trực tiếp cho Organization & Governance.

2. Organization và Governance không phải một thứ

Organization Structure trả lời Who is accountable for what? Trong khi Governance trả lời Who can decide what, under which rules, based on what evidence?

Một đơn vị có thể vận hành một capability nhưng không có toàn quyền quyết định đối với mọi vấn đề liên quan. Vì vậy OLB tách rõ:

Ownership ≠ Accountability ≠ Decision Authority ≠ Execution

Nếu không phân biệt bốn lớp này, tổ chức rất dễ rơi vào trạng thái: nhiều người tham gia nhưng không rõ ai thực sự chịu trách nhiệm.

3. Organization Model bắt đầu từ giá trị

OLB sử dụng chuỗi thiết kế:

Customer → Journey → Business Service → Capability → Accountability → Organization

Khách hàng không quan tâm Payment Processing nằm ở đơn vị nào. Họ quan tâm giao dịch có thực hiện được không, có chính xác và an toàn không, và khi xảy ra gián đoạn thì ngân hàng có khôi phục được dịch vụ không. Vì vậy đối tượng quản trị quan trọng không chỉ là department mà còn là Business Service.

4. Organizational View giả lập của OLB

Ở Enterprise View, OLB sử dụng tám functional domains: Customer & Distribution; Products & Business; Banking Operations; Risk & Compliance; Finance & Treasury; Data & AI; Technology & Digital Platform; Enterprise Management & Resilience.

Đây không phải cơ cấu của một ngân hàng cụ thể và cũng chưa phải organigram chi tiết. Nó là một organizational view giả lập được suy ra từ Capability Map. Điểm quan trọng là Capability Map thường ổn định hơn Organization Chart: capability có thể tồn tại lâu dài trong khi đơn vị sở hữu nó có thể được tái cấu trúc.

5. Capability Owner — ai chịu trách nhiệm về năng lực?

Mỗi capability quan trọng cần có một Capability Owner. Người này không nhất thiết trực tiếp thực hiện mọi hoạt động, nhưng phải nhìn được sức khỏe tổng thể của capability qua các chiều:

Maturity → Performance → Risk Exposure → Technology Health → Resilience Readiness → Investment Need

Ví dụ giả lập, với Payment Processing, accountability không chỉ là một hệ thống thanh toán có chạy hay không. Nó còn bao gồm khả năng đáp ứng business, chất lượng control, dependency công nghệ, risk exposure, resilience readiness và capability gap cần đầu tư.

6. Business Service Owner — ai chịu trách nhiệm với kết quả end-to-end?

Capability Owner vẫn chưa đủ vì một business service thường sử dụng nhiều capability. Hãy tiếp tục case xuyên suốt từ #03: Digital Payment Service.

Một giao dịch chuyển tiền số trong OLB giả lập có thể cần phối hợp các capability như Customer Identity, Payment Processing, Fraud Management, Account Processing, Settlement, Reconciliation, Customer Communication, API & Integration, Technology Operations và Operational Resilience.

Không capability riêng lẻ nào đại diện cho toàn bộ trải nghiệm. Vì vậy OLB bổ sung Business Service Owner — accountability đối với end-to-end service outcome, bao gồm:

Customer Outcome + Performance + Risk + Technology + Resilience

Tư duy quản trị nhờ đó chuyển từ “hệ thống của tôi vẫn chạy” sang “dịch vụ khách hàng có đang hoạt động đúng như ngân hàng kỳ vọng không?”

7. Một service có nhiều bên tham gia, nhưng accountability phải rõ

Digital Payment Service có thể đi qua nhiều lớp:

Business Service Owner → Capability Owners → Process/Control Owners → Application & Technology Owners → Operational Teams

Mỗi lớp có trách nhiệm khác nhau. Sai lầm cần tránh là gắn chữ “Owner” cho quá nhiều người nhưng không định nghĩa owner đó thực sự được quyết định điều gì. Vì vậy OLB nối ownership với Decision Rights.

8. Decision Rights — ai được quyết định điều gì?

Governance chỉ thực sự tồn tại khi quyền quyết định được xác định. OLB phân biệt các nhóm quyết định như:

• Strategic / Portfolio: capability nào cần đầu tư hoặc chuyển đổi?
• Business Service: outcome, target và criticality nào cần được phê duyệt?
• Architecture: giải pháp hoặc exception nào phù hợp với architecture principles?
• Risk: mitigate, transfer, avoid, accept hay escalate?
• Control: control objective, design và evidence nào cần thiết?
• Data & AI: ownership, quality, usage và AI risk được quản trị thế nào?
• Resilience: criticality, dependency, testing và recovery action nào được yêu cầu?

Accountability phải đi cùng Decision Rights. Nếu một người được gọi là owner nhưng không có quyền quyết định hoặc escalation tương ứng, ownership đó chỉ mang tính hình thức.

9. Governance Forum — nơi biến evidence thành decision

OLB giả lập một số forum theo phạm vi quyết định: Enterprise Strategy & Investment; Business Service Governance; Architecture & Technology; Risk & Control; Data & AI Governance; Operational Resilience.

Tên gọi không phải phần quan trọng nhất. Mỗi forum phải tạo được chuỗi:

Decision Scope → Decision Owner → Inputs → Evidence → Decision → Action → Follow-up

Nếu một cuộc họp không tạo ra decision, action, owner và follow-up rõ ràng, nó chưa phải governance hiệu quả.

10. Governance không phải là họp

Trong OLB, một governance cycle chỉ hoàn thành khi đi được từ mục tiêu tới hành động:

Objective → Risk → Control → Evidence → Accountability → Decision → Action

Ví dụ với Digital Payment Service: mục tiêu là dịch vụ đáng tin cậy và resilient; rủi ro có thể là dependency trọng yếu gây gián đoạn; control có thể gồm monitoring, redundancy và recovery capability; evidence đến từ service metrics, dependency mapping, test results và open findings. Từ đó owner và forum phù hợp mới quyết định chấp nhận risk, tăng control hay ưu tiên remediation.

Governance vì vậy là hệ thống biến evidence thành decision và decision thành action.

11. RACI hữu ích — nhưng chưa đủ

RACI giúp phân biệt Responsible, Accountable, Consulted và Informed. Nhưng một bảng RACI lớn không tự tạo ra governance tốt. Với các quyết định trọng yếu, OLB bổ sung bốn trường:

Decision Owner + Decision Authority + Required Evidence + Escalation Path

Một technology team có thể Responsible cho remediation; Risk Owner quyết định treatment hoặc residual risk; Architecture governance xử lý exception; Service Owner chịu accountability với impact lên business service. Vì vậy RACI là công cụ hỗ trợ, không phải Governance Model.

12. Risk ownership phải gắn với business accountability

Một nguyên tắc của OLB là risk không mặc nhiên “thuộc về Risk Department”. Risk function cung cấp framework, oversight, monitoring và challenge phù hợp với vai trò của mình; nhưng người sở hữu business activity/service phải chịu accountability đối với outcome và risk liên quan.

Điều này tránh mô hình “Business tạo risk → Risk quản lý → Technology xử lý”, và thay bằng một mô hình rõ hơn: business/service owner owns the outcome and associated risk; specialist functions support, challenge and assure.

13. Three Lines — nhưng không biến thành ba silo

OLB tham chiếu tư duy Three Lines để phân vai: First Line sở hữu và vận hành business/service/risk/control; Second Line cung cấp framework, oversight, monitoring và challenge; Third Line cung cấp independent assurance.

Nhưng mục tiêu cuối cùng không phải là ba lines hoàn thành ba checklist khác nhau. Điểm hội tụ phải là trusted and resilient business services.

14. Accountability phải truy vết được

Trong OLB Architecture Repository, một quyết định quan trọng phải có thể truy vết theo chuỗi:

Strategic Objective → Capability → Business Service → Accountable Owner → Decision Right → Governance Forum → Risk/Control → Application/Technology Dependency → Resilience Requirement → Evidence → Decision → Action

Ví dụ giả lập: Digital-first Banking → Payment Processing → Digital Payment Service → Service/Capability Ownership → Transaction Integrity Risk → Controls → Technology Dependencies → Recovery Capability → Evidence → Management Decision.

Đây là bước chuyển từ organization chart sang evidence-driven governance.

15. Khi nào organization thực sự cần thay đổi?

OLB không coi tái cấu trúc là giải pháp mặc định. Một vấn đề có thể bắt nguồn từ capability gap, process gap, accountability không rõ, decision rights yếu, technology debt, control weakness, thiếu năng lực con người hoặc governance không tạo được quyết định.

Chỉ khi nguyên nhân thực sự nằm ở organization design thì mới nên thay đổi structure. Nói cách khác: không phải mọi vấn đề quản trị đều cần một sơ đồ tổ chức mới.

16. Từ Organization Chart đến Accountability Architecture

Điểm quan trọng nhất của OLB #04 không phải tạo một organigram. Nó là khả năng trả lời sáu câu hỏi:

• Chúng ta muốn đạt điều gì? — Strategy.
• Ngân hàng phải làm được gì? — Capability.
• Khách hàng đang sử dụng dịch vụ nào? — Business Service.
• Ai chịu trách nhiệm? — Accountability.
• Ai có quyền quyết định? — Decision Rights.
• Dựa trên bằng chứng nào? — Governance.

Đến đây, chuỗi kiến trúc của OLB trở thành:

Strategy → Capability → Service → Accountability → Governance → Organization

Và khi đặt cạnh Odin Method:

Mục tiêu → Rủi ro → Kiểm soát → Bằng chứng → Trách nhiệm → Quyết định → Hành động

Hai chuỗi gặp nhau ở một điểm: Accountability. Architecture, risk hay governance chỉ tạo ra giá trị khi có cơ chế rõ ràng biến thông tin thành quyết định và quyết định thành hành động.

17. Bước tiếp theo — OLB #05: IT Operating Model

Sau #04, OLB đã có Strategy, Enterprise Architecture, Capability Map và Accountability/Governance. Bước tiếp theo là thiết kế IT Operating Model: Technology organization cần vận hành như thế nào để hỗ trợ business capabilities và business services một cách an toàn, hiệu quả và resilient?

---

Khung tham chiếu

OLB sử dụng TOGAF như tham chiếu cho Enterprise/Business Architecture và architecture governance; COBIT cho governance system và accountability; IIA Three Lines Model cho phân vai governance–risk–assurance; NIST Cybersecurity Framework 2.0, đặc biệt Function GOVERN, cho cybersecurity governance; và ISO 22301 cho business continuity management.

Các framework này được sử dụng như nguồn tham chiếu phương pháp. OLB không tuyên bố certification hoặc compliance.

OLB là ngân hàng giả lập/composite được xây dựng từ các mô hình kiến trúc và nghiệp vụ phổ biến trong ngành ngân hàng. Tên tổ chức, vai trò, governance forum, hệ thống, dữ liệu, chỉ tiêu và tình huống được thiết kế riêng cho mục đích nghiên cứu và đào tạo; không mô phỏng một tổ chức cụ thể. Third-party trademarks remain the property of their respective owners; references are illustrative.

ODIN LAB BANK · OLB #04 — ORGANIZATION STRUCTURE & GOVERNANCE
Strategy → Capability → Accountability → Organization
TURN RISK INTO VALUE