BI 4 — Metric & KPI: định nghĩa đúng & Single Source of Truth

Vì sao một con số lại "sai" khi không hề sai?

Trong rất nhiều tổ chức, cuộc họp giữa các phòng ban thường bắt đầu bằng câu hỏi tưởng chừng đơn giản: "Doanh thu tháng này là bao nhiêu?". Rồi điều khó chịu xảy ra: phòng Kinh doanh báo một con số, phòng Tài chính báo con số khác, còn báo cáo BI hiện lên con số thứ ba. Không ai nói dối, không ai tính nhầm phép cộng. Vấn đề nằm ở chỗ mỗi phòng đang dùng một định nghĩa "doanh thu" khác nhau: có phòng tính cả VAT, có phòng trừ hàng trả lại, có phòng ghi nhận theo ngày đặt hàng còn phòng kia theo ngày xuất hóa đơn.

Đây chính là lý do bài học này tồn tại. BI không chỉ là vẽ biểu đồ đẹp; phần khó nhất, và quan trọng nhất, là định nghĩa chỉ số một cách thống nhất, rõ ràng, có thể tái dùng. Bài viết đi từ những khái niệm nền tảng (metric, dimension, KPI) tới các kỹ thuật tổ chức hiện đại (semantic layer, single source of truth) và minh họa bằng các chỉ số ngân hàng thực tế.

Metric và Dimension: hai mặt của mọi câu hỏi phân tích

Mọi câu hỏi phân tích đều có dạng: "Đo cái gì, chia theo cái gì?". Đó chính là metric và dimension.

Metric (số đo)

Metric là một giá trị định lượng — thứ bạn muốn đo lường và tổng hợp. Metric gần như luôn là một con số có thể cộng, đếm, trung bình hoặc tính tỷ lệ: tổng doanh thu, số khách hàng, số dư bình quân, tỷ lệ chuyển đổi. Đặc trưng của metric là nó trả lời câu hỏi "bao nhiêu".

Dimension (chiều phân tích)

Dimension là góc nhìn để cắt lát metric — thường là thuộc tính mô tả, dạng văn bản hoặc phân loại: thời gian (tháng, quý), địa lý (thành phố, chi nhánh), loại tiền tệ, phòng ban, phân khúc khách hàng. Dimension trả lời câu hỏi "theo cái gì".

Ví dụ trực giác: "Tổng số dư (metric) theo loại tiền tệ (dimension)". Một báo cáo BI điển hình là sự kết hợp của một hoặc vài metric với một hoặc vài dimension.

▶ Chạy được trong SQL Builder — Tổng số dư theo loại tiền tệ (metric = tổng balance, dimension = currency):

SELECT currency, SUM(balance) AS total_balance
FROM accounts
GROUP BY currency
ORDER BY total_balance DESC;

Phân loại metric theo tính chất cộng dồn

Hiểu metric "cộng được hay không" là điều then chốt để tránh tổng hợp sai:

• Additive metric (cộng được hoàn toàn): cộng được theo mọi dimension. Ví dụ điển hình là số tiền giao dịch — bạn cộng được theo ngày, theo khách hàng, theo loại giao dịch mà vẫn đúng.
• Semi-additive metric (cộng được một phần): cộng được theo một số dimension nhưng không theo thời gian. Ví dụ kinh điển là số dư tài khoản (balance): cộng số dư của nhiều tài khoản tại cùng một thời điểm thì hợp lý, nhưng cộng số dư của cùng một tài khoản qua nhiều ngày thì vô nghĩa (sẽ dùng số dư cuối kỳ hoặc bình quân thay vì tổng).
• Non-additive / ratio metric (không cộng được): các tỷ lệ như tỷ lệ chuyển đổi, NIM, NPL ratio. Không bao giờ được cộng hay lấy trung bình các tỷ lệ con để ra tỷ lệ tổng. Phải tính lại tử số và mẫu số rồi mới chia. Đây là một trong những lỗi BI phổ biến nhất.

▶ Chạy được trong SQL Builder — Một ratio metric: tỷ trọng số dư của mỗi loại tiền trên tổng toàn hệ thống (lưu ý tính lại tử/mẫu, không trung bình cục bộ):

SELECT currency,
       SUM(balance) AS total_balance,
       ROUND(SUM(balance) * 100.0 / (SELECT SUM(balance) FROM accounts), 2) AS pct_of_total
FROM accounts
GROUP BY currency
ORDER BY pct_of_total DESC;

KPI tốt trông như thế nào?

Metric là bất kỳ con số nào đo được. KPI (Key Performance Indicator) là một metric đặc biệt: nó được chọn lọc vì gắn trực tiếp với một mục tiêu chiến lược và được theo dõi sát sao. Mọi KPI đều là metric, nhưng không phải metric nào cũng xứng đáng là KPI. Số lượng pixel màu xanh trên dashboard là một metric vô dụng; tỷ lệ khách hàng rời bỏ (churn) là một KPI.

Một KPI tốt thỏa mãn các tiêu chí sau (gần với khung SMART):

• Gắn mục tiêu (relevant): phải phản ánh một mục tiêu kinh doanh cụ thể. Nếu không ai hành động gì khi nó thay đổi, đó không phải KPI.
• Đo được (measurable): có công thức rõ ràng, dữ liệu sẵn có, tính được lặp lại cho ra cùng kết quả.
• Có ngưỡng (target/threshold): kèm mục tiêu và ngưỡng cảnh báo. "NPL 2%" chỉ có ý nghĩa khi biết ngưỡng chấp nhận là dưới 3%.
• Actionable (hành động được): khi KPI xấu đi, phải có người chịu trách nhiệm và biết cần làm gì.
• Có thời hạn (time-bound): gắn với một khoảng thời gian xác định (tháng, quý, năm).

Leading indicator và Lagging indicator

Đây là sự phân biệt mà nhiều người làm BI bỏ qua nhưng cực kỳ giá trị:

• Lagging indicator (chỉ số trễ): đo kết quả đã xảy ra. Ví dụ: doanh thu quý vừa rồi, lợi nhuận năm ngoái, NPL hiện tại. Chúng chính xác nhưng bạn không còn thay đổi được nữa — như nhìn vào gương chiếu hậu.
• Leading indicator (chỉ số dẫn): dự báo kết quả tương lai và có thể tác động. Ví dụ: số hồ sơ vay đang chờ duyệt, số khách hàng mới mở tài khoản tuần này, tỷ lệ khách hàng tương tác với ứng dụng. Leading indicator giúp bạn lái con thuyền trước khi va đá.

Một bộ KPI cân bằng cần cả hai: lagging để biết mình đang ở đâu, leading để biết mình sắp đi đâu.

Bẫy lớn nhất: cùng một cái tên, ba định nghĩa

Quay lại câu chuyện mở đầu. Gốc rễ của "mâu thuẫn số liệu" hiếm khi là lỗi kỹ thuật — nó là lỗi ngữ nghĩa (semantic). Khi định nghĩa metric nằm rải rác trong từng câu SQL, từng file Excel, từng dashboard riêng lẻ, mỗi người sẽ tự diễn giải theo cách của mình:

• "Khách hàng hoạt động" — hoạt động trong 30 ngày hay 90 ngày? Có cần phát sinh giao dịch hay chỉ cần đăng nhập?
• "Doanh thu" — gộp VAT? Trừ hoàn trả? Theo ngày đặt hay ngày ghi nhận?
• "Số dư bình quân" — bình quân theo ngày, theo tháng, hay đơn giản là (đầu kỳ + cuối kỳ) / 2?

Mỗi lựa chọn đều "đúng" theo nghĩa nào đó, nhưng khi đặt cạnh nhau chúng tạo ra mâu thuẫn và làm xói mòn niềm tin vào dữ liệu. Giải pháp không phải là họp nhiều hơn, mà là định nghĩa chỉ số một lần, tập trung, và bắt mọi nơi dùng chung định nghĩa đó. Đó chính là vai trò của semantic layer.

Semantic Layer và Metric Layer

Semantic layer (tầng ngữ nghĩa) là một lớp trung gian nằm giữa kho dữ liệu (DWH) và các công cụ tiêu thụ (dashboard, báo cáo, notebook). Nó dịch các bảng và cột kỹ thuật thô thành những khái niệm kinh doanh mà mọi người hiểu chung: thay vì viết lại SUM(balance)/COUNT(...) ở mỗi nơi, bạn chỉ gọi tên casa_ratio đã được định nghĩa sẵn.

Metric layer là phần lõi của semantic layer: nơi mọi metric và KPI được khai báo một lần với công thức, tử số, mẫu số, dimension cho phép và quy tắc tổng hợp. Mọi dashboard sau đó tham chiếu tới định nghĩa trung tâm này thay vì tự viết lại.

Lợi ích của cách tổ chức này:

• Single source of truth: chỉ có một định nghĩa duy nhất cho mỗi chỉ số. Dashboard, báo cáo tài chính và notebook đều ra cùng một con số.
• Tái sử dụng: định nghĩa một lần, dùng ở mọi nơi. Sửa công thức một chỗ, mọi báo cáo cập nhật theo.
• Nhất quán & tin cậy: giảm mâu thuẫn số liệu, tăng niềm tin của lãnh đạo vào dữ liệu.
• Dễ kiểm toán: khi cần biết "con số này tính thế nào", chỉ cần tra định nghĩa trung tâm.

Single Source of Truth và Governance cho định nghĩa metric

Single Source of Truth (SSOT) không phải là "một database duy nhất" — bạn có thể có nhiều nguồn dữ liệu. SSOT nghĩa là mỗi khái niệm chỉ có một định nghĩa được công nhận chính thức. Để duy trì SSOT cần có governance (quản trị) cho định nghĩa metric, gồm tối thiểu:

• Chủ sở hữu (owner): mỗi metric phải có một người/phòng chịu trách nhiệm về định nghĩa. Không có chủ thì không ai bảo trì.
• Định nghĩa rõ tử số / mẫu số: với mọi ratio, ghi rõ tử số đếm cái gì, mẫu số đếm cái gì, loại trừ những gì.
• Phiên bản (versioning): khi đổi công thức, ghi lại lý do và thời điểm để báo cáo cũ vẫn giải thích được.
• Từ điển chỉ số (metric dictionary): tài liệu sống mô tả mọi KPI, đồng nghĩa, đơn vị, nguồn dữ liệu.
• Quy trình phê duyệt: thêm/sửa KPI quan trọng cần qua kiểm tra, tránh "mỗi người tự đẻ ra một KPI".

Một mẹo thực tế: nếu hai phòng cần hai cách tính "doanh thu" khác nhau, đừng ép họ dùng chung. Hãy đặt hai cái tên khác nhau (ví dụ gross_revenue và net_revenue), mỗi cái có định nghĩa riêng minh bạch. Mâu thuẫn xảy ra khi hai định nghĩa che giấu dưới cùng một cái tên, không phải khi chúng tồn tại song song một cách rõ ràng.

Ví dụ thực tế: định nghĩa KPI ngân hàng

Ngành ngân hàng là nơi việc định nghĩa chỉ số sai có thể dẫn tới sai lệch nghiêm trọng trong báo cáo cho cơ quan quản lý. Dưới đây là các KPI cốt lõi, nêu rõ tử số/mẫu số:

Lưu ý rằng tất cả các tỷ lệ trên đều là ratio metric không cộng được: NIM toàn ngân hàng không phải là trung bình NIM của từng chi nhánh, mà phải gộp tử số và mẫu số toàn hệ thống rồi mới chia.

Minh họa "số khách hàng hoạt động" trên schema sandbox

KPI "số khách hàng hoạt động" là ví dụ tuyệt vời cho việc định nghĩa phải rõ ràng. Ở đây ta định nghĩa: khách hàng hoạt động = có ít nhất một giao dịch (qua tài khoản của họ). Lưu ý chuỗi liên kết customers → accounts (account_no...) → transactions (account_id).

▶ Chạy được trong SQL Builder — Đếm số khách hàng hoạt động (có phát sinh giao dịch):

SELECT COUNT(DISTINCT c.id) AS active_customers
FROM customers c
JOIN accounts a ON a.customer_id = c.id
JOIN transactions t ON t.account_id = a.id;

▶ Chạy được trong SQL Builder — Đếm tổng số khách hàng theo thành phố (dimension = city, metric = số khách hàng):

SELECT city, COUNT(id) AS num_customers
FROM customers
GROUP BY city
ORDER BY num_customers DESC;

▶ Chạy được trong SQL Builder — Một ratio metric kiểu CASA đơn giản hóa: tỷ lệ tiền vào (credit) trên tổng giá trị giao dịch — minh họa nguyên tắc gộp tử/mẫu trước khi chia:

SELECT ROUND(
         SUM(CASE WHEN kind = 'credit' THEN amount ELSE 0 END) * 100.0
         / NULLIF(SUM(amount), 0), 2) AS credit_pct
FROM transactions;

NULLIF(..., 0) ở mẫu số là một thói quen phòng vệ quan trọng: nó tránh lỗi chia cho 0 khi chưa có dữ liệu, đồng thời trả về NULL (đúng nghĩa "chưa xác định") thay vì làm hỏng cả báo cáo.

Tóm tắt

Metric trả lời "đo bao nhiêu", dimension trả lời "chia theo cái gì". KPI là metric được nâng tầm vì gắn mục tiêu chiến lược, đo được, có ngưỡng và hành động được (khung SMART), và nên cân bằng giữa chỉ số dẫn (leading) và chỉ số trễ (lagging). Cần phân biệt metric cộng được, bán cộng được và tỷ lệ — đặc biệt không bao giờ trung bình các tỷ lệ con. Bẫy lớn nhất của BI là một cái tên ẩn chứa nhiều định nghĩa, gây mâu thuẫn số liệu; lời giải là semantic layer / metric layer định nghĩa chỉ số một lần, tập trung, tạo nên single source of truth, kèm governance rõ ràng (chủ sở hữu, tử/mẫu, phiên bản). Các KPI ngân hàng như CASA, NIM, NPL, CIR và số khách hàng hoạt động cho thấy tầm quan trọng của việc nêu rõ tử số và mẫu số.

Tự kiểm tra

1. Phân biệt metric và dimension; trong câu "tổng số dư theo loại tiền tệ", đâu là metric, đâu là dimension?
2. Vì sao không được tính NIM toàn ngân hàng bằng cách lấy trung bình NIM của các chi nhánh? Cách đúng là gì?
3. Một KPI tốt cần thỏa mãn những tiêu chí nào? Nêu sự khác nhau giữa leading và lagging indicator kèm ví dụ.
4. Semantic layer / metric layer giải quyết vấn đề "mâu thuẫn số liệu" như thế nào, và nó tạo ra single source of truth ra sao?
5. Khi hai phòng cần hai cách tính "doanh thu" khác nhau, nên xử lý thế nào để vừa minh bạch vừa tránh mâu thuẫn?

Use case thực tế

Tại NCB, Khối Bán lẻ và Khối Tài chính từng báo hai con số CASA ratio khác nhau trong cùng một cuộc họp quý: một bên 22%, một bên 18% (số liệu minh hoạ). Truy vết cho thấy không ai tính sai — hai bên dùng hai định nghĩa mẫu số khác nhau. Khối Bán lẻ lấy tử số là số dư tiền gửi không kỳ hạn, mẫu số chỉ gồm huy động từ khách hàng cá nhân; Khối Tài chính lấy mẫu số là tổng tiền gửi huy động (gồm cả tiền gửi của tổ chức và định chế tài chính). Cùng cái tên "CASA", hai ngữ nghĩa.

Cách xử lý theo đúng bài học: thay vì họp để "chốt ai đúng", nhóm BI đưa định nghĩa lên metric layer tập trung. Họ khai báo hai chỉ số tên khác nhau và minh bạch: casa_ratio_retail (mẫu số = huy động cá nhân) và casa_ratio_total (mẫu số = tổng huy động), mỗi chỉ số ghi rõ tử số/mẫu số, chủ sở hữu và loại trừ. Mọi dashboard sau đó tham chiếu tới định nghĩa trung tâm thay vì tự viết SUM(...)/SUM(...). Vì CASA là ratio metric không cộng được, báo cáo toàn hàng luôn gộp tử số và mẫu số toàn hệ thống rồi mới chia, không bao giờ trung bình CASA của từng chi nhánh. Sau một quý áp dụng, số liệu CASA trong họp lãnh đạo về đúng một con số duy nhất cho mỗi định nghĩa, và mâu thuẫn "cùng tên, khác số" biến mất.

Ghi nhớ

• Metric trả lời "đo bao nhiêu", dimension trả lời "chia theo cái gì"; mọi báo cáo BI là sự kết hợp của hai thứ này.
• Phân biệt additive (cộng theo mọi chiều), semi-additive (như số dư — không cộng theo thời gian) và ratio/non-additive (như NIM, NPL, CASA) để tránh tổng hợp sai.
• Không bao giờ trung bình các tỷ lệ con để ra tỷ lệ tổng — luôn gộp tử số và mẫu số trước rồi mới chia.
• KPI là metric gắn mục tiêu chiến lược, đo được, có ngưỡng, hành động được và có thời hạn (khung SMART); cần cân bằng leading (chỉ số dẫn) và lagging (chỉ số trễ).
• Bẫy lớn nhất của BI là một cái tên ẩn nhiều định nghĩa — nguồn gốc của "mâu thuẫn số liệu", vốn là lỗi ngữ nghĩa chứ không phải lỗi kỹ thuật.
• Semantic layer / metric layer định nghĩa mỗi chỉ số một lần, tập trung, để mọi nơi dùng chung — tạo nên single source of truth.
• SSOT cần governance: chủ sở hữu, tử/mẫu rõ ràng, versioning, từ điển chỉ số và quy trình phê duyệt.
• Khi hai phòng cần hai cách tính, hãy đặt hai cái tên khác nhau minh bạch thay vì ép chung một tên.

Nguồn tham khảo

• Robert S. Kaplan & David P. Norton — "The Balanced Scorecard: Translating Strategy into Action", Harvard Business School Press, 1996 (khung KPI gắn mục tiêu chiến lược, cân bằng leading/lagging).
• Ralph Kimball & Margy Ross — "The Data Warehouse Toolkit", 3rd ed., Wiley (khái niệm additive / semi-additive / non-additive facts).
• George T. Doran — "There's a S.M.A.R.T. Way to Write Management's Goals and Objectives", Management Review, 1981 (nguồn gốc khung SMART).
• dbt Semantic Layer & MetricFlow — dbt Documentation (định nghĩa metric tập trung, tái sử dụng).
• Looker — Measure and dimension types (LookML) (khai báo metric/dimension trong semantic layer).

Đọc tiếp

BI 5 — OLAP