BI 12 — Case study: Xây dựng Dashboard ngân hàng

Mở đầu: từ một yêu cầu mơ hồ đến một sản phẩm dùng được

Đây là bài tổng hợp của cả series. Thay vì học từng khái niệm rời rạc, chúng ta sẽ đi xuyên suốt một dự án thật: xây dựng dashboard điều hành cho ban lãnh đạo một ngân hàng. Mọi thứ đã học — chuỗi giá trị dữ liệu (BI 1), mô hình chiều (BI 3), định nghĩa KPI (BI 4), nguyên tắc trực quan hoá (BI 6) và quản trị (BI 8) — sẽ được ráp lại thành một quy trình bảy bước có thể tái sử dụng cho bất kỳ dự án BI nào.

Bài toán bắt đầu rất quen thuộc. Tổng giám đốc nói: "Tôi muốn một màn hình duy nhất để mỗi sáng nhìn vào là biết ngân hàng đang khoẻ hay yếu." Cụ thể, ban lãnh đạo cần theo dõi: huy động (tiền gửi), dư nợ (cho vay), CASA ratio (tỷ lệ tiền gửi không kỳ hạn), NPL (tỷ lệ nợ xấu), và khách hàng mới — tất cả phải bóc tách được theo chi nhánh và theo thời gian.

Một yêu cầu như vậy nghe đơn giản nhưng ẩn chứa hàng chục quyết định thiết kế. Nếu nhảy thẳng vào kéo-thả biểu đồ, bạn sẽ tạo ra một dashboard rối rắm mà không ai tin. Chúng ta làm ngược lại: bắt đầu từ con người, kết thúc ở vận hành.

Bước 1 — Xác định khán giả và câu hỏi

Sai lầm phổ biến nhất là thiết kế dashboard trước khi biết ai sẽ dùng nó. Mỗi khán giả có một mức độ chi tiết và một loại quyết định khác nhau.

Trong case study này, khán giả là ban điều hành: tổng giám đốc, các phó tổng và giám đốc khối. Họ không có thời gian; họ cần câu trả lời trong vài giây, không cần đào sâu vào từng giao dịch. Quyết định của họ mang tính chiến lược: phân bổ vốn, đặt chỉ tiêu cho chi nhánh, can thiệp khi rủi ro tăng.

Trước khi vẽ bất cứ thứ gì, hãy viết ra các câu hỏi nghiệp vụ mà dashboard phải trả lời. Đây là hợp đồng giữa bạn và người dùng:

• Tổng huy động và dư nợ tháng này là bao nhiêu, tăng hay giảm so với tháng trước?
• Chi nhánh nào đang dẫn đầu và chi nhánh nào tụt lại về huy động?
• CASA ratio toàn hàng có đạt mục tiêu không? Chi nhánh nào kéo tỷ lệ xuống?
• NPL đang ở mức nào và xu hướng có xấu đi không?
• Mỗi tháng có bao nhiêu khách hàng mới, đến từ thành phố/chi nhánh nào?

Nguyên tắc: nếu một biểu đồ không trả lời câu hỏi nào trong danh sách, nó không có chỗ trên dashboard này. Danh sách câu hỏi cũng quyết định mức độ chi tiết — ban điều hành xem theo tháng và theo chi nhánh, không xem theo từng tài khoản.

Bước 2 — Định nghĩa KPI rõ ràng

Đây là bước quan trọng nhất và cũng bị xem nhẹ nhất. Một KPI chỉ đáng tin khi tử số và mẫu số được định nghĩa chính xác, thống nhất ở mọi nơi (liên hệ BI 4). "CASA ratio" mà mỗi phòng tính một kiểu thì dashboard vô giá trị. Hãy lập một bảng định nghĩa và để nghiệp vụ ký duyệt.

Vài cạm bẫy khi định nghĩa KPI

• "Còn hiệu lực" nghĩa là gì? Khoản vay đã tất toán có tính vào dư nợ không? Phải nêu rõ điều kiện lọc.
• Số dư tại thời điểm nào? Số dư cuối kỳ, bình quân ngày, hay snapshot cuối tháng? Mỗi cách cho con số khác nhau.
• Đơn vị tiền tệ. Nếu có nhiều loại tiền, phải quy đổi về VND theo tỷ giá nào và tại thời điểm nào.
• Múi giờ và ranh giới kỳ. Một giao dịch lúc 23h59 ngày cuối tháng thuộc kỳ nào — câu trả lời phải nhất quán.

Khi bảng này được ký duyệt, nó trở thành single source of truth cho mọi con số sau này.

Bước 3 — Mô hình dữ liệu

Câu hỏi nghiệp vụ ("theo chi nhánh, theo thời gian") chính là lời mời gọi của mô hình chiều (star schema — liên hệ BI 3). Ta tách dữ liệu thành fact (sự kiện đo lường được) và dimension (góc nhìn để cắt lát).

Ở đây có hai fact bổ trợ nhau:

• FACT số dư (snapshot): chụp số dư cuối mỗi ngày/tháng cho từng tài khoản. Đây là loại fact "trạng thái tích luỹ" — dùng để tính huy động, dư nợ, CASA, NPL. Không cộng dồn snapshot theo thời gian (cộng số dư của 30 ngày là vô nghĩa); chỉ lấy giá trị tại điểm cuối kỳ.
• FACT giao dịch (transaction): mỗi dòng là một lần tiền vào/ra. Dùng để tính dòng tiền, doanh số, và để giải thích vì sao số dư thay đổi.

Các dimension dùng chung: dim thời gian (ngày → tháng → quý → năm, cho phép drill-down), dim chi nhánh (chi nhánh → vùng → toàn hàng), dim khách hàng (phân khúc, thành phố, ngày mở). Việc mọi fact dùng chung các dimension này (conformed dimensions) là điều kiện để so sánh nhất quán giữa các biểu đồ.

Bước 4 — Bố cục dashboard

Bố cục tốt tuân theo nguyên tắc trực quan hoá (BI 6) và phản ánh cách mắt người đọc: từ tổng quan đến chi tiết, từ trái-trên xuống phải-dưới. Ta chia màn hình thành ba tầng.

Tầng 1 — KPI cards (cái nhìn 3 giây)

Hàng trên cùng là các thẻ KPI lớn: mỗi thẻ một con số to, kèm % thay đổi so với kỳ trước và một mũi tên/màu (xanh tốt, đỏ xấu). Đây là nơi ban điều hành nhìn đầu tiên. Không quá 5-6 thẻ.

Tầng 2 — Xu hướng theo thời gian

Câu hỏi "tăng hay giảm" cần biểu đồ đường theo 12 tháng. Huy động và dư nợ chung một biểu đồ để so sánh; CASA và NPL ở biểu đồ riêng vì là tỷ lệ phần trăm. Biểu đồ đường là lựa chọn chuẩn cho dữ liệu theo thời gian (BI 6); tránh dùng biểu đồ tròn cho xu hướng.

Tầng 3 — Chi tiết drill-down

Câu hỏi "chi nhánh nào" cần biểu đồ cột ngang xếp hạng chi nhánh theo huy động, và một bảng cho phép drill xuống chi nhánh → khách hàng. Bộ lọc thời gian và chi nhánh đặt ở đầu dashboard, áp dụng cho toàn bộ.

Nguyên tắc xuyên suốt: một biểu đồ — một thông điệp, chọn loại biểu đồ theo bản chất dữ liệu, và giữ bảng màu nhất quán (một màu cho huy động, một màu cho dư nợ ở mọi nơi).

Bước 5 — Truy vấn nguồn

Để minh hoạ cách lấy dữ liệu, ta dùng sandbox với schema đơn giản:

• customers(id, full_name, city, created_at)
• accounts(id, customer_id, account_no, balance, currency)
• transactions(id, account_id, amount, kind ['credit'|'debit'], created_at)

Trong sandbox này, accounts.balance đóng vai trò snapshot số dư, customers.city đóng vai trò "chi nhánh", và transactions là dòng tiền. Dưới đây là vài truy vấn nền tảng cho các KPI.

Tổng huy động theo loại tiền (tương tự "huy động theo loại tiền tệ"):

-- ▶ Chạy được trong SQL Builder
SELECT currency, SUM(balance) AS tong_so_du
FROM accounts
GROUP BY currency
ORDER BY tong_so_du DESC;

Số khách hàng theo thành phố (tương tự "khách hàng theo chi nhánh"):

-- ▶ Chạy được trong SQL Builder
SELECT city, COUNT(id) AS so_khach_hang
FROM customers
GROUP BY city
ORDER BY so_khach_hang DESC;

Dòng tiền vào và ra (credit = vào, debit = ra):

-- ▶ Chạy được trong SQL Builder
SELECT kind, SUM(amount) AS tong_tien
FROM transactions
GROUP BY kind;

Top khách hàng theo tổng số dư (ghép accounts với customers):

-- ▶ Chạy được trong SQL Builder
SELECT c.full_name, c.city, SUM(a.balance) AS tong_so_du
FROM customers AS c
JOIN accounts AS a ON a.customer_id = c.id
GROUP BY c.full_name, c.city
ORDER BY tong_so_du DESC;

Khách hàng mới theo tháng (chuỗi thời gian cho biểu đồ đường):

-- ▶ Chạy được trong SQL Builder
SELECT to_char(created_at, 'YYYY-MM') AS thang, COUNT(id) AS kh_moi
FROM customers
GROUP BY thang
ORDER BY thang;

Mỗi truy vấn ở trên ánh xạ trực tiếp tới một ô trên dashboard: truy vấn đầu cho thẻ "huy động theo loại tiền", truy vấn thứ hai cho biểu đồ cột "theo chi nhánh", và truy vấn cuối cho đường "khách hàng mới theo tháng". Trong hệ thống thật, các câu này sẽ chạy trên view/fact đã mô hình hoá ở Bước 3 chứ không trên bảng nguồn thô — nhưng logic là như nhau.

Bước 6 — RLS theo chi nhánh

Ban điều hành nhìn được toàn hàng, nhưng giám đốc chi nhánh chỉ được nhìn dữ liệu chi nhánh mình. Đây là Row-Level Security (RLS) — một phần của quản trị dữ liệu (BI 8).

Cách triển khai điển hình:

1. Lập một bảng ánh xạ user_branch(user_email, branch_id) xác định mỗi người dùng thuộc chi nhánh nào.
2. Định nghĩa một luật lọc áp tự động lên mọi fact: branch_id = current_user_branch().
3. Gán vai trò cho cấp lãnh đạo để bỏ qua bộ lọc (nhìn toàn hàng).

Điểm mấu chốt: RLS được áp ở tầng mô hình/ngữ nghĩa, không phải ở từng biểu đồ. Nhờ vậy cùng một dashboard tự động hiển thị dữ liệu khác nhau tuỳ người đăng nhập — giám đốc Hà Nội thấy số Hà Nội, giám đốc HCM thấy số HCM, không cần làm hai bản. Hãy luôn kiểm thử RLS bằng cách đăng nhập giả lập từng vai trò trước khi phát hành.

Bước 7 — Refresh và vận hành

Một dashboard đẹp mà số liệu cũ thì còn tệ hơn không có. Vận hành gồm ba câu hỏi.

Tần suất làm mới (refresh). Ban điều hành xem theo ngày, nên refresh một lần mỗi sáng sớm là đủ (ví dụ 5h sáng, sau khi pipeline đêm hoàn tất). KPI rủi ro như NPL có thể chỉ cần snapshot cuối ngày. Không phải mọi thứ cần real-time — real-time tốn kém và thường không đổi quyết định.

Thứ tự phụ thuộc. Dashboard chỉ làm mới sau khi fact và dimension đã nạp xong. Lịch refresh phải đứng sau job ETL trong chuỗi điều phối, nếu không bạn sẽ hiển thị dữ liệu nửa vời.

Giám sát và tin cậy. Thêm một dòng "dữ liệu cập nhật lúc HH:MM" trên dashboard để người dùng biết độ tươi. Đặt cảnh báo khi refresh thất bại hoặc khi KPI nhảy bất thường (ví dụ huy động giảm 30% trong một đêm — gần như chắc chắn là lỗi dữ liệu, không phải kinh doanh).

Sơ đồ trên khép lại toàn bộ luồng: từ hệ thống nguồn, qua ETL ban đêm, vào kho dữ liệu đã mô hình hoá, qua lớp ngữ nghĩa áp KPI và RLS, đến dashboard mà người dùng cuối nhìn thấy. Mỗi bước trong bài này tương ứng một mắt xích trong sơ đồ.

Tóm tắt

• Dự án BI thành công bắt đầu từ con người và câu hỏi, không phải từ biểu đồ. Bảy bước: khán giả → KPI → mô hình → bố cục → truy vấn → RLS → vận hành.
• Định nghĩa KPI (tử/mẫu, điều kiện lọc, thời điểm) là nền móng tin cậy; lập bảng và để nghiệp vụ ký duyệt.
• Mô hình chiều với fact số dư (snapshot) + fact giao dịch và các conformed dimension cho phép cắt lát nhất quán theo thời gian/chi nhánh/khách hàng.
• Bố cục ba tầng (KPI card → xu hướng → drill-down) dẫn mắt người đọc và chọn biểu đồ theo bản chất dữ liệu.
• RLS ở tầng ngữ nghĩa giúp một dashboard phục vụ nhiều cấp; refresh + giám sát đảm bảo số liệu luôn tươi và đáng tin.

Tự kiểm tra

1. Vì sao phải xác định khán giả và viết danh sách câu hỏi trước khi thiết kế biểu đồ?
2. Viết công thức tử/mẫu cho CASA ratio và NPL ratio; nêu một cạm bẫy khi định nghĩa "dư nợ còn hiệu lực".
3. Tại sao không được cộng dồn các snapshot số dư theo thời gian, trong khi giao dịch thì cộng dồn được?
4. Cho schema sandbox, viết một câu SELECT tính tổng số dư theo từng thành phố (chi nhánh).
5. RLS theo chi nhánh nên được áp ở tầng nào và vì sao điều đó tốt hơn lọc ở từng biểu đồ?
6. Vì sao lịch refresh dashboard phải đứng sau job ETL, và bạn sẽ hiển thị thông tin gì để người dùng tin vào độ tươi của dữ liệu?

Đọc tiếp

• Quay lại để ôn nền tảng tư duy BI: BI 1 — Business Intelligence là gì.
• Để hiểu sâu các câu truy vấn nguồn ở Bước 5, hãy xem mục SQL — cách viết JOIN, GROUP BY, hàm cửa sổ và tối ưu truy vấn.
• Để hiểu cách dữ liệu đến được kho (ETL đêm, pipeline, điều phối) ở Bước 7, xem mục Data Engineering.

Use case thực tế

Bối cảnh (minh hoạ). Tại NCB, ban điều hành yêu cầu một dashboard điều hành duy nhất để theo dõi sức khoẻ toàn hàng mỗi sáng. Đội BI áp đúng bảy bước trong bài. Ở Bước 2, cạm bẫy lộ ra ngay: khối Nguồn vốn và khối Rủi ro đang tính CASA ratio theo hai cách khác nhau — một bên lấy số dư cuối kỳ, một bên lấy bình quân ngày — nên hai báo cáo lệch nhau khoảng 1,5 điểm phần trăm (ước lượng minh hoạ). Đội BI lập bảng định nghĩa KPI, chốt CASA ratio = Σ số dư tiền gửi không kỳ hạn cuối tháng / Tổng huy động cuối tháng, và để cả hai khối ký duyệt; từ đó mọi con số về một mối.

Triển khai. Ở Bước 3, họ dựng FACT số dư dạng snapshot cuối ngày cho từng tài khoản và FACT giao dịch, dùng chung dim thời gian, dim chi nhánh, dim khách hàng. NPL ratio lấy dư nợ nhóm 3-4-5 theo phân loại nợ, đặt cạnh ngưỡng cảnh báo nội bộ (ví dụ minh hoạ: 3%). Ở Bước 6, RLS theo bảng user_branch giúp giám đốc chi nhánh Hà Nội chỉ thấy số Hà Nội, trong khi phó tổng thấy toàn hàng — cùng một dashboard, không cần làm hai bản.

Kết quả (minh hoạ). Sau khi lịch refresh 5h sáng được đặt sau job ETL đêm và thêm dòng "dữ liệu cập nhật lúc HH:MM", cuộc họp giao ban rút ngắn vì mọi người nhìn cùng một con số đã được thống nhất định nghĩa.

Ghi nhớ

• Dự án BI bắt đầu từ con người và câu hỏi nghiệp vụ, không phải từ biểu đồ; nếu một biểu đồ không trả lời câu hỏi nào trong danh sách thì không có chỗ trên dashboard.
• Định nghĩa KPI (tử/mẫu, điều kiện lọc, thời điểm đo, đơn vị tiền) phải được lập bảng và nghiệp vụ ký duyệt — đó là single source of truth.
• Dùng mô hình chiều: FACT số dư (snapshot) không cộng dồn theo thời gian, FACT giao dịch thì cộng dồn được; các conformed dimension cho phép cắt lát nhất quán.
• Bố cục ba tầng: KPI card (cái nhìn 3 giây) → xu hướng theo thời gian → chi tiết drill-down; một biểu đồ một thông điệp, màu nhất quán.
• Mỗi truy vấn nguồn ánh xạ trực tiếp tới một ô trên dashboard; trong hệ thống thật chạy trên view/fact đã mô hình hoá chứ không trên bảng thô.
• Áp RLS ở tầng ngữ nghĩa để một dashboard phục vụ nhiều cấp; luôn kiểm thử bằng cách đăng nhập giả lập từng vai trò.
• Refresh + giám sát: lịch refresh đứng sau job ETL, hiển thị thời điểm cập nhật, cảnh báo khi refresh lỗi hoặc KPI nhảy bất thường.

Nguồn tham khảo

• Ralph Kimball, Margy Ross — The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (Wiley) — star schema, fact/dimension, conformed dimensions, snapshot fact.
• Stephen Few — Information Dashboard Design: Displaying Data for At-a-Glance Monitoring (Analytics Press) — nguyên tắc thiết kế dashboard, KPI card, chọn biểu đồ.
• Stephen Few — Show Me the Numbers: Designing Tables and Graphs to Enlighten (Analytics Press) — trực quan hoá bảng và biểu đồ.
• Basel Committee on Banking Supervision — BCBS 239: Principles for effective risk data aggregation and risk reporting (Bank for International Settlements) — khung tổng hợp và báo cáo dữ liệu rủi ro cho ngân hàng.
• Ngân hàng Nhà nước Việt Nam — Thông tư 11/2021/TT-NHNN về phân loại tài sản có và trích lập dự phòng rủi ro (cơ sở phân loại nợ nhóm 1-5, nền tảng tính NPL).