Trực quan hoá 8 — Thực hành dashboard ngân hàng

13 thg 7, 2026 2 lượt xem
#banking
#bi
#dashboard
#practice
#data-visualization

Trực quan hoá 8 — Thực hành dashboard ngân hàng

Bảy bài trước dạy từng nguyên lý riêng: tri giác thị giác, chọn biểu đồ đúng, thiết kế màu, thiết kế dashboard, kể chuyệncạm bẫy & đạo đức. Bài cuối này không thêm lý thuyết mới — nó ghép tất cả lại và bắt chúng phải làm việc cùng nhau trên ba dashboard ngân hàng thật: điều hành, rủi rovận hành/giao dịch.

Với mỗi dashboard ta đi qua đúng một khung sáu bước, theo thứ tự bắt buộc: (1) khán giả & câu hỏi → (2) KPI/metric chọn → (3) chart phù hợp → (4) bố cục → (5) màu → (6) thông điệp. Thứ tự này quan trọng: dashboard phải được thiết kế ngược từ nhu cầu ra quyết định, không phải lắp ráp từ dữ liệu có sẵn. Ai bắt đầu bằng "ta có bảng gì" thay vì "người dùng cần trả lời câu gì" sẽ luôn ra một trang chi chít chart mà không ai dùng.

Khung sáu bước — vì sao theo đúng thứ tự này

Mỗi bước dựa vào bước trước. Chọn KPI khi chưa biết khán giả là chọn mù. Chọn chart khi chưa chốt KPI là vẽ trang trí. Đổ màu trước khi có bố cục là tô son cho một cấu trúc lệch. Và bước cuối — rà cạm bẫy — là vòng lặp: phát hiện lie factor lệch thì quay lại chọn lại chart, không phải sửa màu cho đẹp.


Dashboard 1 — ĐIỀU HÀNH (Ban lãnh đạo)

1. Khán giả & câu hỏi

Khán giả là Ban điều hành / HĐQT: người bận, xem trên màn hình lớn trong họp hoặc trên điện thoại, có 5 giây cho ấn tượng đầu. Câu hỏi họ mang tới: "Ngân hàng đang khoẻ hay yếu, so với kế hoạch và so với kỳ trước? Có gì cần can thiệp ngay không?" Đây là dashboard strategic — nhịp cập nhật theo tháng/quý, ưu tiên trạng thái so mục tiêu hơn chi tiết vận hành (phân loại theo thiết kế dashboard).

2. KPI chọn

Chọn tối đa 7–9 chỉ số cốt lõi, mỗi cái là một quyết định — không dồn 30 metric. Nhóm theo trụ tài chính (định nghĩa chi tiết xem Metrics & KPI):

KPIÝ nghĩaĐi kèm
Tổng tài sảnQuy mô ngân hàngXu hướng 12 tháng
Huy động / Tín dụngNguồn vốn & sử dụng vốnTăng trưởng YoY, so kế hoạch
CASA (%)Tỷ trọng tiền gửi không kỳ hạn — chi phí vốn rẻSo mục tiêu
NIM (%)Net Interest Margin — biên lãi thuầnXu hướng
CIR (%)Cost-to-Income Ratio — hiệu quả chi phíSo mục tiêu (thấp là tốt)
Tỷ lệ nợ xấu (NPL %)Chất lượng tài sảnSo trần 3%
CAR (%)Capital Adequacy Ratio — an toàn vốnSo trần quy định ≥ 8%

3. Chart phù hợp

  • Big number (BAN — Big-Ass Number) cho mỗi KPI: con số hiện tại, to, kèm delta so kỳ trước và mũi tên. Đây là chart mắt đọc nhanh nhất.
  • Sparkline nhỏ ngay dưới mỗi big number: xu hướng 12 điểm, không cần trục — chỉ để thấy hình dạng đang lên hay xuống.
  • Bullet chart cho các KPI có mục tiêu (huy động, tín dụng, CIR): thanh giá trị so vạch mục tiêu — thay cho gauge tốn chỗ.
  • Line chart cho tổng tài sản / huy động / tín dụng theo 12–24 tháng, so cùng kỳ.

Không pie, không 3D, không gauge tròn (xem lý do ở chọn biểu đồ đúng).

4. Bố cục

Bố cục theo inverted pyramid và luồng đọc F/Z: thông điệp quan trọng nhất góc trên trái.

5. Màu

Màu phải có nghĩa, không trang trí (theo thiết kế màu): xanh = đạt/tốt, hổ phách = cảnh báo, đỏ = vượt ngưỡng xấu. NPL vượt trần → đỏ; CAR dưới ngưỡng → đỏ. Nền xám trung tính, chỉ một màu thương hiệu cho điểm nhấn. Bảng màu phải accessible: không dựa chỉ vào đỏ/xanh (mù màu đỏ-lục ~8% nam giới) — kèm icon mũi tên hoặc dấu ✓/✗ để phân biệt không cần màu.

6. Thông điệp

Tiêu đề dashboard mang thông điệp, không phải nhãn: thay vì "Báo cáo điều hành Q2/2026", viết "Huy động đạt 96% kế hoạch, NPL trong ngưỡng — chi phí (CIR) cần theo dõi" (kỹ thuật tiêu đề mang thông điệp ở kể chuyện). Annotation ngay tại điểm bất thường: nếu CIR nhích lên, chú thích "CIR tăng do đầu tư hạ tầng số, kế hoạch giảm từ Q4".

SQL nền — tổng số dư & tăng trưởng theo currency

Big number "tổng huy động" và phân tách theo loại tiền chạy trên một truy vấn gộp đơn giản:

-- ▶ Chạy được
SELECT currency,
       COUNT(*)                         AS so_tai_khoan,
       ROUND(SUM(balance)::numeric, 2)  AS tong_so_du,
       ROUND(AVG(balance)::numeric, 2)  AS so_du_tb
FROM accounts
GROUP BY currency
ORDER BY tong_so_du DESC;

Đây là dữ liệu nền cho ô big number (tổng SUM(balance)) và cho một bar nhỏ tách theo currency. Lưu ý ép ::numeric trước ROUNDSUM/AVG trên cột NUMERIC vẫn cần định kiểu rõ để ROUND(v, 2) nhận đúng overload — thói quen an toàn tránh lỗi hàm.


Dashboard 2 — RỦI RO (Khối QLRR)

1. Khán giả & câu hỏi

Khán giả là cán bộ và lãnh đạo Quản lý rủi ro, có nền kỹ thuật, xem hằng ngày, cần đào sâu. Câu hỏi: "Rủi ro tín dụng đang tập trung ở đâu? Phân khúc/chi nhánh nào xấu đi? Có tín hiệu cảnh báo sớm nào không?" Đây là dashboard analytical — cho phép lọc, drill-down, so sánh.

2. KPI/metric chọn

  • Phân bố dư nợ theo nhóm nợ (nhóm 1–5 theo Thông tư phân loại) — nền tảng đánh giá chất lượng.
  • Tỷ lệ NPL theo phân khúc (bán lẻ / SME / doanh nghiệp lớn) và theo chi nhánh.
  • Tập trung tín dụng: top khách hàng/ngành chiếm tỷ trọng dư nợ — rủi ro tập trung.
  • Cảnh báo sớm (Early Warning): số khoản chuyển nhóm nợ xấu hơn, nợ quá hạn mới phát sinh, tỷ lệ nợ tái cơ cấu.

3. Chart phù hợp

  • Stacked bar / 100% stacked cho phân bố nhóm nợ theo chi nhánh — thấy cơ cấu và tỷ trọng nhóm 3–5.
  • Bar ngang xếp thứ tự cho NPL theo phân khúc/chi nhánh (dễ xếp hạng hơn pie — tri giác).
  • Heatmap chi nhánh × nhóm nợ: ô đỏ đậm = điểm nóng.
  • Bar top-N cho tập trung tín dụng theo ngành/khách hàng.
  • KPI card có ngưỡng cho cảnh báo sớm, đổi màu khi vượt.

Tránh choropleth theo số tuyệt đối — luôn chuẩn hoá thành tỷ lệ NPL (nợ xấu / tổng dư nợ), nếu không bản đồ chỉ vẽ lại nơi nào dư nợ lớn (cạm bẫy #10 ở bài 7).

4. Bố cục

Tổng quan trên cùng (tổng NPL, tỷ lệ nhóm 3–5), phân rã theo phân khúc và chi nhánh ở giữa, bảng cảnh báo sớm chi tiết dưới cùng — theo inverted pyramid: tổng → phân rã → chi tiết. Bộ lọc (thời gian, phân khúc, chi nhánh) đặt trên cùng bên trái, áp dụng cho cả trang.

5. Màu

Dùng thang tuần tự (sequential) cho mức độ rủi ro: nhạt = an toàn, đậm = rủi ro cao — một màu, không cầu vồng. Chỉ nhóm nợ xấu (3–5) và các ô vượt ngưỡng mới được màu cảnh báo nổi bật; phần lành mạnh giữ xám/nhạt để không cạnh tranh chú ý. Tránh nghịch lý Simpson: NPL tổng có thể đẹp trong khi mọi phân khúc xấu đi do dịch cơ cấu — nên luôn hiển thị cả phân rã, không chỉ số gộp (cạm bẫy #9).

6. Thông điệp

Tiêu đề nêu phát hiện: "NPL toàn hàng 2,1% dưới trần, nhưng phân khúc SME tại 3 chi nhánh phía Nam đang tăng nhanh". Cảnh báo sớm luôn kèm ngưỡng và mốc so sánh — con số trần trụi ("42 khoản chuyển nhóm") vô nghĩa nếu không có baseline ("42 vs trung bình 15/tháng").

SQL nền — phân bố số dư (proxy phân bố rủi ro)

Sandbox không có cột nhóm nợ; ta minh hoạ phân bố số dư theo dải — cùng kỹ thuật dùng cho phân bố nhóm nợ trên hệ thống thật:

-- ▶ Chạy được
SELECT CASE
         WHEN balance < 0            THEN '1. Âm (thấu chi)'
         WHEN balance < 10000000     THEN '2. < 10 triệu'
         WHEN balance < 100000000    THEN '3. 10-100 triệu'
         WHEN balance < 1000000000   THEN '4. 100 triệu - 1 tỷ'
         ELSE                             '5. >= 1 tỷ'
       END                                 AS dai_so_du,
       COUNT(*)                            AS so_tai_khoan,
       ROUND(SUM(balance)::numeric, 2)     AS tong_so_du
FROM accounts
GROUP BY dai_so_du
ORDER BY dai_so_du;

Bảng này nuôi một bar xếp theo dải hoặc histogram — cho thấy dư nợ/số dư tập trung ở dải nào. Trên hệ thống thật, thay balance bằng nhóm nợ để ra đúng chart "phân bố dư nợ theo nhóm".


Dashboard 3 — VẬN HÀNH / GIAO DỊCH

1. Khán giả & câu hỏi

Khán giả là đội vận hành / trung tâm giám sát (NOC), xem trên màn hình treo tường real-time, cần phát hiện sự cố trong vài giây. Câu hỏi: "Hệ thống giao dịch có đang chạy khoẻ không? Kênh nào lỗi/chậm? Có cần can thiệp ngay?" Đây là dashboard operational — nhịp cập nhật giây/phút, ưu tiên tình trạng hiện tạicảnh báo, không phải xu hướng dài hạn.

2. KPI/metric chọn

  • Khối lượng giao dịch (TPS/phút) theo kênh (ATM, Internet Banking, Mobile, POS, chuyển khoản liên ngân hàng).
  • Tỷ lệ giao dịch thành công (%) theo kênh — chỉ số sức khoẻ số một.
  • Độ trễ (latency) trung bình và P95/P99 — trung bình che giấu đuôi chậm.
  • Cảnh báo (alert): kênh có tỷ lệ lỗi vượt ngưỡng, độ trễ vượt SLA, khối lượng bất thường (tăng vọt = tấn công / giảm sốc = sự cố).

3. Chart phù hợp

  • Big number + trạng thái cho tổng TPS và tỷ lệ thành công tổng, đổi màu theo ngưỡng.
  • Line chart real-time (cuộn theo thời gian) cho TPS và latency theo kênh — thấy đột biến ngay.
  • Bảng trạng thái kênh với đèn xanh/vàng/đỏ mỗi kênh.
  • Bar so tỷ lệ lỗi giữa các kênh.
  • Với latency, hiển thị P95/P99, không chỉ trung bình (trung bình che đuôi — một dạng "tổng hợp che giấu").

4. Bố cục

Trạng thái tổng (đèn hệ thống) trên cùng — trả lời "khoẻ hay không" trong 3 giây; chi tiết theo kênh ở giữa; log cảnh báo cuộn dưới cùng. Vì xem từ xa: font lớn, ít chữ, tương phản cao. Tối giản trang trí — mỗi pixel phải phục vụ giám sát.

5. Màu

Quy ước đèn giao thông nhất quán tuyệt đối: xanh = OK, vàng = cần chú ý, đỏ = sự cố. Nền tối (dark) cho màn hình treo tường 24/7, giảm mỏi mắt và làm đèn cảnh báo nổi bật. Kèm hình dạng/icon để không phụ thuộc mỗi màu (accessible). Khi mọi thứ OK, dashboard phải tĩnh và xanh — bất kỳ đốm đỏ nào lập tức bắt mắt.

6. Thông điệp

Ở dashboard vận hành, "thông điệp" chính là trạng thái tức thời + cảnh báo hành động được: không kể chuyện dài, mà "Kênh Mobile: tỷ lệ thành công tụt còn 94% (SLA 99%) — điều tra ngay". Annotation gắn với sự kiện: đánh dấu thời điểm triển khai/sự cố trên đường latency.

SQL nền — số giao dịch theo kind & ngày

Line real-time và bar theo kênh dựa trên đếm giao dịch phân theo loại và thời gian:

-- ▶ Chạy được
SELECT kind,
       DATE(created_at)                     AS ngay,
       COUNT(*)                             AS so_giao_dich,
       ROUND(SUM(amount)::numeric, 2)       AS tong_tien
FROM transactions
GROUP BY kind, DATE(created_at)
ORDER BY ngay DESC, so_giao_dich DESC;

Trục X = ngay, mỗi kind một đường (line) hoặc một nhóm cột — chính là hình dạng dữ liệu cho biểu đồ khối lượng giao dịch theo kênh. Trên hệ thống thật thêm cột status để tính tỷ lệ thành công; ở sandbox ta minh hoạ phần khối lượng.


Chọn công cụ theo bối cảnh

Cùng thiết kế, khác công cụ hiện thực. Chọn theo bối cảnh tổ chức, không theo mốt:

Công cụHợp khiĐiểm mạnhLưu ý
Power BIĐã dùng hệ sinh thái Microsoft, người dùng nghiệp vụ tự làmDAX mạnh, chia sẻ dễ, học nhanh — xem thiết kế report Power BIBản quyền theo user; hạ tầng cloud/gateway
SupersetMuốn mã nguồn mở, đội có kỹ thuật, cần nhúng & mở rộngMiễn phí, SQL-first, nhiều chart, nhúng linh hoạt (xem BI mã nguồn mở)Cần vận hành tự chủ, đường cong dốc hơn
MetabaseCần triển khai nhanh, người dùng hỏi đáp tự phục vụCực dễ dùng, cài nhanh, "hỏi câu hỏi" không cần SQLÍt tuỳ biến sâu; chart nâng cao hạn chế

Nguyên tắc: dashboard điều hành (ít người, cần đẹp & chia sẻ mượt) hợp Power BI/Metabase; dashboard rủi ro (SQL nặng, đội kỹ thuật) hợp Superset; dashboard vận hành real-time thường cần công cụ giám sát chuyên biệt (Grafana) hơn công cụ BI truyền thống, vì BI thường không tối ưu cho refresh theo giây.

Quy trình xây dashboard & lặp với người dùng

Điểm mấu chốt: wireframe trước, dữ liệu sau. Đừng đổ 20 chart rồi hỏi người dùng thích cái nào — hãy hỏi họ cần quyết định gì, phác vài phương án trên giấy, rồi mới dựng. Đo lượt dùng sau phát hành và mạnh dạn bỏ chart không ai xem: dashboard thừa còn tệ hơn thiếu vì nó làm loãng chú ý.

Checklist chất lượng trước khi phát hành

Chạy qua trước khi bất kỳ dashboard nào rời tay bạn:

  • Mục đích: mỗi dashboard trả lời một bộ câu hỏi rõ của một khán giả xác định — không phải "tổng hợp mọi thứ".
  • 5-second rule: người dùng nắm thông điệp chính trong 5 giây? Quan trọng nhất ở góc trên trái?
  • Chart đúng loại: bar từ 0, không pie/3D cho nhiều hạng mục, dùng đúng chart cho đúng câu hỏi (bài 3).
  • KPI có ngữ cảnh: mỗi con số kèm baseline/mục tiêu/delta và dấu tốt-xấu — không số trần trụi.
  • Màu có nghĩa & accessible: màu mã hoá trạng thái nhất quán; không dựa chỉ đỏ/xanh; đủ tương phản (bài 4).
  • Bố cục phân cấp: tổng → phân rã → chi tiết; nhóm liên quan gần nhau; căn lưới (bài 5).
  • Tiêu đề mang thông điệp + annotation tại điểm bất thường (bài 6).
  • Rà cạm bẫy (bài 7): trục Y, dual axis, choropleth tuyệt đối, Simpson, cherry-picking — lie factor ≈ 1.
  • Nguồn & thời điểm chốt dữ liệu ghi rõ; định nghĩa KPI thống nhất.
  • Hiệu năng: tải trong ngưỡng chấp nhận; refresh đúng nhịp (giây cho vận hành, ngày/tháng cho điều hành).
  • Mobile/màn hình đích: hiển thị đúng trên thiết bị người dùng thật sẽ xem.

Use case thực tế

Bối cảnh. Khối Kinh doanh yêu cầu "một dashboard điều hành huy động". Bản đầu do một BA tự dựng: 22 chart, 4 pie, hai bảng dài, tiêu đề "Dashboard Huy Động 2026", màu cầu vồng. Ban điều hành xem 10 phút vẫn không trả lời được "tháng này có đạt kế hoạch không".

Áp khung sáu bước.

  1. Khán giả & câu hỏi: phỏng vấn thành viên Ban điều hành → ba câu duy nhất: đạt kế hoạch huy động chưa, CASA đi đâu, chi phí vốn thế nào.
  2. KPI: cắt từ 22 xuống 6 — huy động vs KH, tăng trưởng YoY, CASA %, chi phí vốn, tỷ trọng theo kỳ hạn, top nguồn.
  3. Chart: 4 pie → bullet + bar ngang xếp thứ tự; hai bảng dài → một sparkline + một line 24 tháng.
  4. Bố cục: hàng 1 = huy động vs KH (câu hỏi số một, góc trên trái); hàng 2 = CASA & chi phí vốn; hàng 3 = phân rã kỳ hạn.
  5. Màu: bỏ cầu vồng, còn xám nền + một màu thương hiệu + xanh/hổ phách cho đạt/chưa đạt, kèm icon.
  6. Thông điệp: tiêu đề đổi thành "Huy động đạt 96% kế hoạch, CASA giảm 1,2 điểm % — chi phí vốn nhích lên", annotation tại điểm CASA rơi.

Rà cạm bẫy. Phát hiện bar tăng trưởng dùng trục Y cắt (từ 90%) → phóng đại → đưa về 0. Bản đồ huy động theo tỉnh theo số tuyệt đối → chuẩn hoá theo dân số/số khách.

Kết quả. Từ 22 chart còn 6 khối, một màn hình, một thông điệp. Ban điều hành nắm tình hình trong 5 giây, và câu chuyện CASA giảm được nhìn thấy ngay — dẫn tới một quyết định thật (đẩy sản phẩm tài khoản thanh toán lương). Số liệu nền cho các ô chạy trên đúng ba truy vấn kiểu như phần SQL ở trên: tổng số dư theo currency, phân bố theo dải, đếm giao dịch theo ngày.

Tổng kết series

Tám bài đã đi từ nền tảng tới thực hành: vì sao trực quan hoá hiệu quả (bài 1) và cơ chế tri giác khiến nó hoạt động (bài 2); chọn chart (bài 3) và màu (bài 4) đúng; gom thành dashboard (bài 5) và câu chuyện (bài 6); tránh cạm bẫy & giữ đạo đức (bài 7); và bài này ghép tất cả vào ba dashboard ngân hàng thật. Sợi chỉ xuyên suốt: bắt đầu từ người dùng và câu hỏi, để tri giác dẫn dắt lựa chọn kỹ thuật, và giữ lie factor ≈ 1. Trực quan hoá không phải trang trí số — nó là cầu nối giữa dữ liệu và quyết định, và trong ngân hàng, quyết định đó chi phối vốn, rủi ro và niềm tin.

Ghi nhớ

  • Luôn thiết kế ngược từ khán giả & câu hỏi, đi đúng khung: khán giả → KPI → chart → bố cục → màu → thông điệp → rà cạm bẫy.
  • Ba loại dashboard, ba tư duy khác nhau: điều hành (strategic, big number + so mục tiêu), rủi ro (analytical, phân rã & drill-down), vận hành (operational, real-time + cảnh báo).
  • Dashboard điều hành: ≤ 7–9 KPI, mỗi cái có baseline/mục tiêu; big number + sparkline + bullet; NPL so trần 3%, CAR so ≥ 8%.
  • Dashboard rủi ro: luôn phân rã theo phân khúc/chi nhánh (tránh Simpson), choropleth phải chuẩn hoá tỷ lệ, thang màu tuần tự cho mức rủi ro.
  • Dashboard vận hành: đèn xanh/vàng/đỏ nhất quán, nền tối cho màn hình 24/7, hiển thị P95/P99 không chỉ trung bình, thông điệp = cảnh báo hành động được.
  • Chọn công cụ theo bối cảnh: Power BI (hệ sinh thái MS, self-service), Superset (mã nguồn mở, SQL-first), Metabase (nhanh, dễ); real-time thường cần Grafana hơn BI truyền thống.
  • Wireframe trước, dữ liệu sau; prototype tối giản, demo cho người dùng tự thao tác, lặp; đo lượt dùng và mạnh dạn bỏ chart không ai xem.
  • Chạy checklist chất lượng trước khi phát hành: mục đích, 5-second rule, chart đúng, KPI có ngữ cảnh, màu accessible, bố cục phân cấp, thông điệp, rà cạm bẫy, nguồn, hiệu năng.
  • Sợi chỉ xuyên suốt series: bắt đầu từ câu hỏi, để tri giác dẫn kỹ thuật, giữ lie factor ≈ 1 — trực quan hoá là cầu nối dữ liệu và quyết định.

Bài viết liên quan

Phân biệt ước lượng điểm và ước lượng khoảng, cách xây khoảng tin cậy (CI) bằng margin of error z*·SE / t*·SE, đánh đổi mức 90/95/99%, và cách DIỄN GIẢI ĐÚNG khoảng tin cậy (95% CI không phải xác suất tham số nằm trong khoảng). Có CI cho trung bình và cho tỷ lệ, ảnh hưởng của cỡ mẫu, cùng ví dụ ngân hàng về tỷ lệ nợ xấu và số dư trung bình.

13 thg 7, 2026 4

Kimball dimensional modeling: bảng fact/dimension, star vs snowflake, grain, và Slowly Changing Dimension.

13 thg 7, 2026 3

Khối OLAP, các thao tác drill-down/roll-up/slice & dice/pivot, OLAP vs OLTP và ROLAP/MOLAP/HOLAP.

13 thg 7, 2026 3

Từ nguồn dữ liệu qua ETL/ELT vào Data Warehouse, Data Mart đến dashboard; staging, ODS, batch vs streaming.

13 thg 7, 2026 3