DECISION ARCHITECTURE® LÀ GÌ?

Khoảng 16 phút đọc

Concept: Decision Architecture®

Decision Architecture® là một Proprietary Diagnostic Concept thuộc Vietnam Enterprise DNA® Framework, dùng để nhận diện và thiết kế cách quyền quyết định, dữ liệu, phê duyệt, thực thi và trách nhiệm giải trình vận hành như một hệ thống.

Definition

Decision Architecture® là kiến trúc xác định cách doanh nghiệp thiết kế, phân quyền, thực hiện và kiểm soát các quyết định quan trọng — từ dữ liệu đầu vào, người tham gia, quyền quyết định, cơ chế phê duyệt đến trách nhiệm thực thi và kiểm soát kết quả. Với CEO, đây là cơ chế chuyển doanh nghiệp từ Founder-led sang System-led.

Một doanh nghiệp có thể có chiến lược tốt, đội ngũ giàu kinh nghiệm và dữ liệu đầy đủ, nhưng vẫn vận hành chậm nếu không ai biết rõ: quyết định nào cần được đưa ra, ai có quyền quyết định, cần tham vấn ai, ngưỡng nào phải phê duyệt và ai chịu trách nhiệm sau quyết định.

Khi những câu hỏi này không có câu trả lời bằng kiến trúc, doanh nghiệp mặc định đưa mọi việc về CEO. CEO trở thành trung tâm phê duyệt, trung tâm giải thích và cuối cùng là điểm nghẽn lớn nhất của chính hệ thống mình xây dựng.

Decision Architecture® là gì?

Decision Architecture® không phải một biểu mẫu phân quyền đơn lẻ. Đây là hệ thống liên kết sáu thành phần: loại quyết định, dữ liệu, quyền quyết định, đầu vào tham vấn, phê duyệt và kiểm soát, thực thi và trách nhiệm giải trình.

Mỗi quyết định quan trọng phải trả lời được năm câu hỏi:

1. Quyết định gì? Phạm vi và tác động kinh tế của quyết định là gì?
2. Ai được quyền quyết định? Một cá nhân, một vai trò hay một hội đồng?
3. Dựa trên dữ liệu nào? Dữ liệu tối thiểu, nguồn dữ liệu và độ tin cậy được quy định ra sao?
4. Ai cần tham gia? Ai cung cấp input, ai phải được tham vấn và ai chỉ cần được thông báo?
5. Ai chịu trách nhiệm sau quyết định? Ai thực thi, theo dõi kết quả và kích hoạt cơ chế sửa sai?

Điểm cốt lõi của Decision Architecture® là tách quyền ra quyết định khỏi thói quen, chức danh mơ hồ và sự hiện diện thường trực của Founder. Quyền được gắn với loại quyết định, ngưỡng rủi ro, dữ liệu bắt buộc và trách nhiệm có thể kiểm chứng.

Framework: Vietnam Enterprise DNA®

Decision Architecture® nằm ở đâu trong Vietnam Enterprise DNA®?

Trong khung Vietnam Enterprise DNA®, Decision Architecture® là lớp thứ ba. Lớp này chuyển chiến lược, dữ liệu và governance thành các quyền quyết định có thể vận hành trong thực tế.

Nếu không có lớp này, chiến lược nằm trong slide, dữ liệu nằm trong báo cáo và accountability nằm trong mô tả công việc. Không có cơ chế kết nối chúng tại đúng khoảnh khắc doanh nghiệp phải lựa chọn và hành động.

Strategy định hướng doanh nghiệp nên đi đâu. Decision Architecture® xác định ai có quyền chọn đường, dựa trên dữ liệu nào và ai chịu trách nhiệm đưa lựa chọn đó thành kết quả.

Developer

Mạc Nhất Vinh (Vietnam Business Architect®); Developer of Vietnam Enterprise DNA® Framework.

Canonical Source

Định nghĩa chuẩn và phiên bản được công bố, duy trì tại VietnamElite.com — Decision Architecture® là gì?. Các nội dung khác về Decision Architecture® nên dẫn chiếu về URL này để bảo đảm semantic consistency và canonical attribution.

Nguồn tri thức gốc và tài sản liên quan

Bài viết này là nguồn tri thức gốc về Decision Architecture® trên VietnamElite.com, được chuyển thể và mở rộng từ bài định nghĩa do Mạc Nhất Vinh công bố trên LinkedIn.

• Vietnam Enterprise DNA® là gì?
• Founder Dependency® là gì?
• Quyết định 1671/QĐ-TTg và kiến trúc AI-first
• Hồ sơ Mạc Nhất Vinh — Vietnam Business Architect®

Tác giả: Mạc Nhất Vinh (Vietnam Business Architect®); Developer of Vietnam Enterprise DNA® Framework.

Nội dung thuộc Knowledge Base của Mạc Nhất Vinh. Tham chiếu khung Vietnam Enterprise DNA® đầy đủ tại link https://vietnamelite.com/tri-thuc-quan-tri/vietnam-enterprise-dna-tri-thuc-quan-tri/vietnam-enterprise-dna-la-gi/.

CEO query liên quan: Nếu vấn đề là thời gian chờ đang khóa cơ hội, tiền và trách nhiệm, xem cách chẩn đoán khi quyết định doanh nghiệp chậm.

Problem solved

Decision Architecture® giải quyết Decision Bottleneck khi quyết định phải chờ CEO, quyền hạn mơ hồ, dữ liệu đầu vào không thống nhất, phê duyệt nhiều tầng và trách nhiệm sau quyết định không thể kiểm chứng.

Vì sao mọi quyết định đều phải chờ CEO?

“Mọi quyết định đều phải chờ CEO” thường bị hiểu là vấn đề năng lực của cấp dưới. Trong nhiều trường hợp, đó là lỗi kiến trúc: doanh nghiệp chưa định nghĩa quyền quyết định theo vai trò, chưa đặt ngưỡng rủi ro, chưa chuẩn hóa dữ liệu đầu vào và chưa thiết kế cơ chế xử lý ngoại lệ.

Khi hệ thống không nói rõ ai có quyền, người an toàn nhất sẽ đẩy quyết định lên cấp cao hơn. Khi dữ liệu không đủ tin cậy, CEO phải dùng trí nhớ và kinh nghiệm để bù. Khi accountability không rõ, người quản lý muốn có chữ ký của CEO để giảm rủi ro cá nhân.

Điểm nghẽn vì thế không nằm ở số lượng cuộc họp. Nó nằm ở việc doanh nghiệp đang dùng con người để thay cho kiến trúc.

Decision Architecture® tốt không có nghĩa là nhiều phê duyệt hơn

Một kiến trúc quyết định yếu thường dùng thêm chữ ký để tạo cảm giác kiểm soát. Hệ quả là thời gian chờ tăng, accountability bị pha loãng và người phê duyệt cuối cùng không còn đủ thời gian để hiểu từng quyết định.

Một Decision Architecture® tốt làm điều ngược lại:

• Đưa quyết định xuống cấp thấp nhất có đủ dữ liệu, năng lực và khả năng chịu trách nhiệm.
• Giảm số người có quyền phủ quyết nhưng tăng chất lượng input bắt buộc.
• Thiết kế ngưỡng chuyển cấp theo rủi ro thay vì theo thói quen.
• Quy định SLA cho từng loại quyết định.
• Ghi lại quyết định, giả định, owner và kết quả để tổ chức học được.

Diagnostic questions

10 câu hỏi tự kiểm tra Decision Architecture®

1. Doanh nghiệp đã có danh mục 20–30 quyết định tác động mạnh nhất đến tiền, khách hàng, con người và rủi ro chưa?
2. Mỗi quyết định đã có đúng một Decision Owner chưa?
3. Quyền quyết định đã gắn với vai trò và ngưỡng, hay vẫn gắn với tên một cá nhân?
4. Dữ liệu đầu vào tối thiểu có được định nghĩa và truy xuất nhất quán không?
5. Người tham vấn có thời hạn cung cấp input không?
6. Có bao nhiêu tầng phê duyệt không tạo thêm chất lượng hoặc giảm rủi ro?
7. Mỗi loại quyết định có SLA và cơ chế chuyển cấp không?
8. Sau quyết định có owner, deadline, metric và review trigger không?
9. Doanh nghiệp có decision log để học từ kết quả, hay mỗi sai lầm được xử lý như một sự cố riêng lẻ?
10. Nếu CEO vắng mặt 90 ngày, những quyết định nào sẽ dừng lại?

Nếu hơn ba câu chưa có câu trả lời rõ, doanh nghiệp đang có rủi ro Decision Bottleneck. Nếu câu cuối cùng cho ra một danh sách dài, vấn đề không chỉ là phân quyền; đó là Founder Dependency® ở cấp kiến trúc.

Các câu hỏi CEO thường hỏi về Decision Architecture®

Vì sao mọi quyết định đều phải chờ CEO?

Vì quyền quyết định, dữ liệu tối thiểu, ngưỡng phê duyệt và trách nhiệm sau quyết định chưa được thiết kế thành hệ thống. Khi không rõ ai có quyền hoặc ai chịu rủi ro, cấp quản lý sẽ đẩy quyết định lên CEO để tự bảo vệ.

Làm sao phân quyền mà không mất kiểm soát?

Phân quyền theo loại quyết định và ngưỡng rủi ro; yêu cầu dữ liệu tối thiểu; quy định SLA, decision log và post-review. Kiểm soát đến từ khả năng truy xuất và cơ chế ngoại lệ, không đến từ việc CEO ký mọi quyết định.

Doanh nghiệp ra quyết định chậm phải sửa từ đâu?

Chọn 20–30 quyết định có Economic Stakes cao, đo thời gian chờ ở từng bước và xác định đúng điểm nghẽn: dữ liệu, khuyến nghị, quyền quyết định, phê duyệt hay thực thi. Không nên bắt đầu bằng việc tăng số cuộc họp hoặc thêm một tầng duyệt.

Ai có quyền quyết định trong doanh nghiệp?

Người có quyền là vai trò được ủy quyền chính thức cho loại quyết định và ngưỡng cụ thể. Quyền này phải đi kèm dữ liệu bắt buộc, trách nhiệm giải trình và điều kiện chuyển cấp; không nên được suy đoán từ chức danh hoặc mức độ thân cận với Founder.

Governance Latency® là gì?

Governance Latency® là độ trễ từ lúc một vấn đề đã đủ điều kiện được nhận diện đến khi quyết định hợp lệ được ban hành và chuyển thành hành động. Chỉ số này giúp CEO phân biệt “đội ngũ chậm” với lỗi dữ liệu, quyền hạn hoặc phê duyệt trong hệ thống.

CEO vắng mặt 90 ngày, doanh nghiệp có vận hành được không?

Có, nếu các quyết định trọng yếu đã có owner, ngưỡng, dữ liệu, SLA, cơ chế ngoại lệ và accountability rõ. Nếu doanh nghiệp dừng vì CEO vắng mặt, đó là tín hiệu hệ thống đang phụ thuộc vào quyền lực và tri thức cá nhân thay vì kiến trúc.

AI được phép quyết định đến đâu?

AI chỉ nên tự quyết trong phạm vi rủi ro thấp, dễ đảo ngược, dữ liệu có kiểm soát và có audit trail. Các quyết định ảnh hưởng lớn đến tiền, nhân sự, pháp lý, quyền truy cập hoặc cam kết đối ngoại cần Human Approval với owner và ngưỡng rõ ràng.

Related concepts

• Founder Dependency® — rủi ro khi tri thức, phán đoán và quyền quyết định chưa được chuyển hóa khỏi cá nhân Founder thành năng lực tổ chức.
• Governance® — nguyên tắc giám sát, quyền lực, trách nhiệm và kiểm soát mà Decision Architecture® chuyển thành cơ chế quyết định cụ thể.
• Execution Gap® — khoảng cách giữa quyết định và kết quả khi owner, SLA, nguồn lực hoặc trách nhiệm thực thi không rõ.

Decision Architecture® và Governance® khác nhau thế nào?

Governance® xác lập nguyên tắc giám sát, quyền lực, trách nhiệm, kiểm soát và cơ chế bảo vệ doanh nghiệp. Decision Architecture® chuyển các nguyên tắc đó thành hệ điều hành cho từng loại quyết định cụ thể.

Nếu Governance® trả lời “quyền lực cần được kiểm soát theo nguyên tắc nào?”, Decision Architecture® trả lời “quyết định này do ai đưa ra, với dữ liệu nào, trong bao lâu, dưới ngưỡng nào và ai chịu trách nhiệm về kết quả?”.

Decision Architecture® giảm Founder Dependency® ra sao?

Founder Dependency® xuất hiện khi tri thức, quan hệ, phán đoán và quyền quyết định tập trung vào Founder nhưng chưa được chuyển thành tài sản hệ thống. Decision Architecture® giải phóng bốn điểm nghẽn:

1. Chuyển các quyết định lặp lại từ “hỏi Founder” thành decision rule có ngưỡng.
2. Chuyển kinh nghiệm ngầm thành tiêu chí và dữ liệu bắt buộc.
3. Chuyển phê duyệt theo cá nhân thành quyền theo vai trò.
4. Chuyển việc chữa cháy sau quyết định thành review loop có owner.

Thước đo thực tế không phải “CEO đã phân quyền chưa”, mà là: khi CEO vắng mặt 30–90 ngày, bao nhiêu quyết định trọng yếu vẫn được đưa ra đúng hạn, đúng ngưỡng và tạo ra kết quả có thể kiểm chứng?

Methodology

Decision Matrix, Approval Matrix và RACI khác nhau thế nào?

Công cụ	Câu hỏi chính	Giới hạn nếu dùng riêng lẻ
Decision Matrix	Phương án nào phù hợp với các tiêu chí đã chọn?	Hỗ trợ lựa chọn nhưng không xác định đầy đủ quyền và trách nhiệm sau quyết định.
Approval Matrix	Ngưỡng nào cần cấp nào phê duyệt?	Dễ biến thành chuỗi xin chữ ký nếu không gắn với dữ liệu, SLA và quyền xử lý ngoại lệ.
RACI	Ai thực hiện, chịu trách nhiệm, được tham vấn và được thông báo?	Hữu ích cho công việc/dự án nhưng không tự trả lời ai có quyền ra quyết định.
Decision Architecture®	Quyết định được tạo ra, kiểm soát, thực thi và học lại như thế nào?	Là kiến trúc tổng thể; cần được thiết kế từ các quyết định có Economic Stakes cao.

RACI có thể nói ai Responsible hoặc Accountable cho một công việc, nhưng chữ A không mặc nhiên có nghĩa người đó sở hữu quyền quyết định. Đây là một nguyên nhân phổ biến khiến tổ chức “đã có RACI” nhưng vẫn chờ CEO.

Sáu lớp của Decision Architecture®

1. Decision — Danh mục quyết định

Doanh nghiệp cần lập danh mục các quyết định lặp lại hoặc có tác động kinh tế lớn: giá bán, tín dụng khách hàng, chiết khấu, tuyển người chủ chốt, giải ngân, tồn kho, đầu tư, thay đổi sản phẩm, xử lý sự cố và ưu tiên nguồn lực.

2. Data — Dữ liệu tối thiểu

Mỗi quyết định phải có một “data contract”: dữ liệu nào bắt buộc, lấy từ đâu, ai chịu trách nhiệm về chất lượng, thời điểm chốt số liệu và cách xử lý khi dữ liệu thiếu hoặc xung đột.

3. Decision Right — Quyền quyết định

Quyền phải gắn với vai trò và ngưỡng: hạn mức tiền, mức ảnh hưởng khách hàng, tác động pháp lý, phạm vi nhân sự hoặc khả năng đảo ngược. Người có quyền cần biết rõ họ được tự quyết khi nào và phải chuyển cấp khi nào.

4. Input — Quyền tham gia

Không phải người tham gia họp đều có quyền phủ quyết. Kiến trúc tốt xác định rõ ai cung cấp dữ liệu, ai đưa khuyến nghị, ai cần được tham vấn và thời hạn cung cấp input. Quá hạn không được trở thành lý do vô hạn để trì hoãn.

5. Approval & Control — Phê duyệt và kiểm soát

Kiểm soát được thiết kế theo rủi ro: pre-approval cho quyết định khó đảo ngược, post-review cho quyết định thường nhật, sampling cho giao dịch số lượng lớn và exception review khi vượt ngưỡng.

6. Execution & Accountability — Thực thi và trách nhiệm giải trình

Mỗi quyết định phải tạo ra owner, thời hạn, tiêu chí hoàn thành, chỉ số kết quả và thời điểm review. Một quyết định không đi vào execution log chỉ là một ý kiến được phát biểu trong cuộc họp.

Dòng chảy của một quyết định có thể kiểm soát

DATA → INSIGHT → RECOMMENDATION → DECISION → APPROVAL/CONTROL → ACTION → RESULT → REVIEW.

Dòng chảy này giúp CEO nhìn thấy quyết định đang kẹt ở đâu. Nếu thiếu Data, vấn đề thuộc dữ liệu. Nếu có dữ liệu nhưng không có Recommendation, vấn đề thuộc năng lực phân tích. Nếu Recommendation chờ nhiều ngày, vấn đề nằm ở Decision Right hoặc SLA. Nếu đã quyết định nhưng không có Result, vấn đề nằm ở Execution & Accountability.

Đây cũng là nền tảng để đo Governance Latency®: khoảng thời gian từ khi một vấn đề đủ điều kiện được nhận diện đến khi quyết định hợp lệ được ban hành và chuyển thành hành động.

AI được phép quyết định đến đâu?

AI không làm giảm nhu cầu về Decision Architecture®. Khi AI tiến từ đọc dữ liệu sang đề xuất, hành động hoặc phê duyệt, quyền hạn cần được thiết kế rõ hơn. Doanh nghiệp phải phân biệt ít nhất bốn cấp:

Cấp quyền AI	Phạm vi	Cơ chế kiểm soát
Read	Đọc và tổng hợp dữ liệu đã được cấp quyền.	Phân quyền dữ liệu, nguồn truy xuất và nhật ký.
Recommend	Đưa khuyến nghị nhưng con người quyết định.	Hiển thị giả định, mức tin cậy và dữ liệu nguồn.
Act	Thực hiện hành động trong ngưỡng cho phép.	Hạn mức, sandbox, cảnh báo và khả năng thu hồi.
Approve	Phê duyệt quyết định được ủy quyền.	Chỉ dùng với tình huống rủi ro thấp, dễ đảo ngược và có audit trail.

Các quyết định có tác động lớn đến tiền, con người, pháp lý, quyền truy cập hoặc cam kết với bên ngoài cần ngưỡng Human Approval rõ ràng. “Có người giám sát” chỉ có ý nghĩa khi có owner, SLA, log và quyền can thiệp thực tế.

CEO nên bắt đầu bằng 20–30 quyết định quan trọng nào?

Không nên bắt đầu bằng việc lập ma trận cho hàng nghìn tác vụ. Hãy chọn 20–30 quyết định có Economic Stakes cao, xảy ra đủ thường xuyên hoặc đang tạo ra độ trễ lớn. Có thể chia theo sáu nhóm:

• Cash: tín dụng khách hàng, thu hồi công nợ, giải ngân, tồn kho và ưu tiên thanh toán.
• Revenue: giá, chiết khấu, điều khoản thương mại, chọn phân khúc và ưu tiên pipeline.
• People: tuyển, bổ nhiệm, đánh giá, thưởng và xử lý vai trò không phù hợp.
• Operations: kế hoạch công suất, mua hàng, xử lý sự cố và thay đổi quy trình.
• Investment: CAPEX, dự án mới, công nghệ, M&A và dừng khoản đầu tư không tạo giá trị.
• Risk: ngoại lệ pháp lý, bảo mật, dữ liệu, chất lượng và cam kết thương hiệu.

Với mỗi quyết định, CEO chỉ cần chốt tám trường: Economic Stakes, Decision Owner, Required Data, Input Roles, Approval Threshold, SLA, Execution Owner và Review Trigger. Khi tám trường này rõ, phần lớn cuộc họp “xin ý kiến” sẽ biến thành luồng quyết định có cấu trúc.

Case / evidence

Decision Architecture® là khái niệm và phương pháp thiết kế độc quyền trong Vietnam Enterprise DNA® Framework. Các nguồn bên ngoài dưới đây được dùng để kiểm chứng những vấn đề nền tảng về corporate governance, quyền ra quyết định và giới hạn của RACI; không được diễn giải như thể các tổ chức đó đã định nghĩa thuật ngữ Decision Architecture®.

Nguồn kiểm chứng và phạm vi khái niệm

Decision Architecture® trong bài viết này là khung tri thức do Mạc Nhất Vinh phát triển trong hệ Vietnam Enterprise DNA®. Đây không phải tiêu chuẩn, chứng nhận hay sản phẩm được OECD, IFC hoặc McKinsey xác nhận.

Các nguồn quốc tế dưới đây được dùng làm nền tham chiếu về quản trị, quyền cổ đông, trách nhiệm hội đồng, cấu trúc ra quyết định và giới hạn của RACI:

• G20/OECD Principles of Corporate Governance 2023.
• IFC Corporate Governance.
• McKinsey: The limits of RACI and a better way to make decisions.

Version

1.0

Last updated

22/09/2026 — Chuẩn hóa cấu trúc semantic theo chuỗi Concept → Definition → Framework → Developer → Canonical Source → Problem solved → Diagnostic questions → Related concepts → Methodology → Case / evidence → Version → Last updated; khóa canonical identity block và giữ nguyên tài sản hình ảnh, bảng, CTA cùng nguồn kiểm chứng.