BI 11 — Self-Service BI & Quản trị

Trong các bài trước, chúng ta đã xây dựng nền móng kỹ thuật của một hệ thống BI: mô hình dữ liệu, kho dữ liệu, ETL/ELT, semantic layer và dashboard. Nhưng có một nghịch lý kinh điển: bạn bỏ công sức xây dựng hệ thống BI tập trung, đẹp đẽ, nhưng rồi đội kinh doanh vẫn xuất dữ liệu ra Excel rồi tự làm báo cáo riêng. Mỗi phòng ban báo cáo một con số khác nhau cho cùng một chỉ tiêu. Cuộc họp biến thành tranh cãi xem "số của ai đúng".

Bài này nói về cách giải quyết nghịch lý đó: làm sao để người dùng nghiệp vụ tự phục vụ (self-service) mà không phá vỡ tính nhất quán và bảo mật. Đây là phần "quản trị" (governance) — thường bị xem nhẹ nhưng lại quyết định một hệ thống BI sống được lâu hay chết yểu sau sáu tháng.

Self-Service BI là gì

Self-Service BI là mô hình cho phép người dùng nghiệp vụ — chuyên viên kinh doanh, trưởng phòng tín dụng, nhân viên marketing — tự tạo báo cáo, dashboard và phân tích mà không cần chờ đội IT/Data viết SQL hay dựng báo cáo cho từng yêu cầu.

Trước đây, mọi yêu cầu báo cáo đều đi qua một hàng đợi (queue) ở bộ phận IT. Người dùng gửi ticket, chờ vài ngày đến vài tuần, nhận lại một file. Nếu hiểu sai ý hay cần điều chỉnh nhỏ, lại gửi ticket mới. Đội IT thì luôn quá tải với hàng trăm yêu cầu ad-hoc.

Self-service đảo ngược điều này: IT/Data lo phần hạ tầng và dữ liệu nền (curated data), còn người dùng tự kéo-thả để tạo ra cái họ cần. Các công cụ như Power BI, Tableau, Looker, Metabase đều được thiết kế quanh ý tưởng này.

Lợi ích và rủi ro

Self-service không phải liều thuốc tiên. Nó là con dao hai lưỡi.

Rủi ro lớn nhất và kinh điển nhất là "spreadmart" (ghép từ spreadsheet + data mart): mỗi cá nhân hoặc phòng ban tự duy trì một "kho dữ liệu" rời rạc trong Excel với logic tính toán riêng. Khi sếp hỏi "tổng dư nợ tháng này là bao nhiêu", ba phòng đưa ra ba con số. Không phải vì ai gian lận, mà vì mỗi người định nghĩa "dư nợ" khác nhau: có người tính cả nợ đã tất toán giữa tháng, có người loại trừ nợ nội bộ, có người dùng tỷ giá cuối ngày, người khác dùng tỷ giá bình quân.

Trong ngân hàng, còn một rủi ro nghiêm trọng hơn: bảo mật dữ liệu khách hàng. Nếu một chuyên viên có thể tự kéo toàn bộ danh sách khách hàng VIP kèm số dư rồi xuất ra file gửi đi, đó là vi phạm bảo mật và có thể vi phạm pháp luật (quy định bảo vệ dữ liệu cá nhân, bí mật thông tin khách hàng theo quy định của NHNN).

Mô hình cân bằng: Governed Self-Service

Lời giải không phải là cấm tự phục vụ (quay về thời IT làm tất, hàng đợi tắc nghẽn), cũng không phải buông lỏng hoàn toàn (hỗn loạn spreadmart). Lời giải là governed self-service — tự phục vụ trong khuôn khổ.

Ý tưởng cốt lõi: tách bạch hai lớp trách nhiệm.

• Lớp dữ liệu nền (do Data/IT quản): nguồn sự thật duy nhất, các dataset/model đã được kiểm chứng, semantic layer với định nghĩa chỉ tiêu chuẩn hóa, phân quyền và bảo mật. Người dùng không được sửa lớp này.
• Lớp khám phá (do người dùng tự làm): trên nền dữ liệu đã chuẩn hóa đó, người dùng tự do kéo-thả, tạo biểu đồ, dashboard, phân tích ad-hoc.

Như vậy người dùng vẫn tự do, nhưng tự do trên một nền móng đã được kiểm soát. Họ không định nghĩa lại "dư nợ" — họ dùng chỉ tiêu "Dư nợ" đã được chứng nhận. Họ không tự kết nối thẳng vào core banking — họ dùng dataset đã được lọc và phân quyền.

Điểm mấu chốt trong sơ đồ: dữ liệu đi từ nguồn qua semantic layer, được đóng gói thành dataset chứng nhận, áp dụng phân quyền/RLS, rồi mới đến tay người dùng. Báo cáo người dùng tự tạo ban đầu là "nháp"; chỉ những báo cáo qua quy trình duyệt mới được "chứng nhận" và dùng chung.

Dataset chứng nhận và Semantic Layer dùng chung

Dataset chứng nhận (Certified)

Trong các nền tảng BI hiện đại, "chứng nhận" (certification/endorsement) là một nhãn chính thức gắn lên dataset hoặc báo cáo, báo hiệu: "Đây là nguồn đã được kiểm chứng, bạn có thể tin tưởng dùng cho quyết định."

Một dataset chứng nhận thường có đặc điểm:

• Được một đội ngũ chịu trách nhiệm (data steward / data owner) phê duyệt.
• Có tài liệu mô tả: nguồn gốc, logic tính toán, lịch refresh, người liên hệ.
• Logic chỉ tiêu khớp với định nghĩa chuẩn của tổ chức.
• Được giám sát chất lượng (data quality) định kỳ.

Người dùng khi tìm dataset sẽ thấy huy hiệu "Certified" và ưu tiên dùng nó thay vì tự kết nối nguồn thô. Đây là cơ chế "lái" hành vi mềm — không cấm, nhưng định hướng người dùng đến nguồn đúng.

Semantic Layer — nguồn sự thật duy nhất

Đây là nơi ý tưởng của bài BI 4 (semantic layer / mô hình ngữ nghĩa) phát huy giá trị trong bối cảnh quản trị. Semantic layer là lớp trung gian định nghĩa các chỉ tiêu (measures), chiều (dimensions) và quan hệ một lần duy nhất, để mọi báo cáo dùng chung.

Ví dụ chỉ tiêu "Tỷ lệ nợ xấu (NPL)" được định nghĩa một lần trong semantic layer:

NPL = (Dư nợ nhóm 3 + nhóm 4 + nhóm 5) / Tổng dư nợ

Mọi dashboard — của phòng tín dụng, của ban kiểm soát rủi ro, của báo cáo lên ban lãnh đạo — đều tham chiếu cùng định nghĩa này. Không ai có cơ hội tự gõ lại công thức và lỡ tay tính sai. Đó chính là single source of truth: một định nghĩa, một con số, áp dụng nhất quán toàn tổ chức.

Khi định nghĩa cần thay đổi (ví dụ NHNN cập nhật cách phân loại nợ), ta chỉ sửa ở semantic layer, và toàn bộ báo cáo cập nhật theo. Không phải đi sửa từng file Excel rải rác.

Phân quyền và Row-Level Security (RLS)

Bảo mật là phần không thể thỏa hiệp, đặc biệt trong ngân hàng. Có hai cấp độ kiểm soát cần phân biệt.

Row-Level Security (RLS) — bảo mật theo dòng

RLS kiểm soát người dùng nào được thấy dòng dữ liệu nào trong cùng một dataset. Kịch bản kinh điển: chi nhánh A chỉ được thấy dữ liệu của chi nhánh A, chi nhánh B chỉ thấy của B, còn giám đốc vùng thấy cả vùng.

Cơ chế hoạt động: ta định nghĩa một vai trò (role) với một bộ lọc (filter) được áp dụng tự động dựa trên danh tính người dùng đang đăng nhập.

Ví dụ logic RLS (mô tả khái niệm, cú pháp tùy nền tảng):

-- Vai trò "Chi nhánh"
-- Bộ lọc áp lên bảng GiaoDich:
[MaChiNhanh] = LOOKUPVALUE(
    AnhXa_NguoiDung[MaChiNhanh],
    AnhXa_NguoiDung[Email], USERPRINCIPALNAME()
)

Diễn giải: khi user [email protected] mở dashboard, hệ thống lấy email của họ, tra trong bảng ánh xạ ra mã chi nhánh (giả sử CN001), rồi tự động thêm điều kiện WHERE MaChiNhanh = 'CN001' vào mọi truy vấn. Người dùng không cần biết bộ lọc tồn tại — họ chỉ thấy dữ liệu của mình, một cách trong suốt.

Cách triển khai RLS hiệu quả là dùng bảng ánh xạ người dùng (user-mapping table): một bảng nối email/tài khoản với phạm vi dữ liệu được phép xem (chi nhánh, vùng, phòng ban, nhóm khách hàng). Khi nhân sự thay đổi, ta chỉ sửa bảng ánh xạ — không phải sửa từng báo cáo.

Một số kiểu RLS thường gặp trong ngân hàng:

• Theo chi nhánh/vùng: giám đốc chi nhánh chỉ xem khách hàng và giao dịch của chi nhánh mình.
• Theo phân khúc khách hàng: đội phụ trách KHCN không xem được dữ liệu khách hàng doanh nghiệp.
• Theo cấp bậc (phân cấp tổ chức): cấp trên thấy được tổng hợp của cấp dưới, dùng bảng phân cấp (hierarchy) để xác định phạm vi.

Object-Level Security (OLS) — bảng/cột

RLS giấu dòng, còn Object-Level Security (OLS) giấu nguyên cả đối tượng — bảng hoặc cột — khỏi người dùng không có quyền. Ví dụ: cột SoCMND, SoDienThoai, DiaChi của khách hàng chỉ hiển thị với vai trò "Tuân thủ"; với người dùng thường, các cột này thậm chí không tồn tại trong mô hình họ thấy.

Phân biệt nhanh:

• RLS: "Bạn thấy bảng khách hàng, nhưng chỉ những dòng thuộc chi nhánh bạn."
• OLS: "Bạn không hề thấy cột số CMND tồn tại."

Trong ngân hàng, hai lớp này thường kết hợp: RLS giới hạn phạm vi khách hàng theo chi nhánh, OLS che các trường định danh nhạy cảm (PII) trừ khi có quyền đặc biệt.

Vòng đời báo cáo

Một báo cáo không nên "sinh ra rồi sống mãi mãi". Để tránh hỗn loạn dashboard rác, mỗi báo cáo nên đi qua một vòng đời rõ ràng:

1. Phát triển (Development): người tạo xây dựng báo cáo trong không gian cá nhân hoặc workspace dev. Tự do thử nghiệm, không ảnh hưởng ai.
2. Kiểm thử (Test/UAT): chia sẻ cho một nhóm nhỏ nghiệp vụ để rà soát logic, đối chiếu số liệu với nguồn đã biết. Bước này bắt buộc với báo cáo quan trọng.
3. Publish: đưa lên môi trường dùng chung (production workspace), cấp quyền cho đối tượng phù hợp.
4. Chứng nhận (Certify): data steward rà soát lần cuối và gắn nhãn "Certified". Lúc này báo cáo trở thành nguồn chính thức.
5. Vận hành & giám sát: theo dõi sử dụng, hiệu năng, độ chính xác. Cập nhật khi định nghĩa thay đổi.
6. Loại bỏ (Retire/Deprecate): báo cáo không còn dùng (ít lượt xem, trùng lặp, nghiệp vụ thay đổi) được gắn nhãn "deprecated" và sau đó gỡ bỏ.

Bước loại bỏ thường bị quên, nhưng nó quan trọng: một môi trường có 500 dashboard mà chỉ 50 cái được dùng thực sự sẽ khiến người dùng lạc lối, không biết tin cái nào. Định kỳ "dọn rác" giúp giữ hệ thống sạch và đáng tin.

Data Catalog và Discovery

Khi có hàng trăm dataset và báo cáo, vấn đề chuyển từ "thiếu dữ liệu" thành "không tìm thấy / không biết tin cái nào". Data catalog (danh mục dữ liệu) giải quyết điều này: một nơi tập trung để tìm kiếm, mô tả và hiểu các tài sản dữ liệu.

Một catalog tốt cung cấp:

• Tìm kiếm (discovery): gõ "nợ xấu" và thấy ngay dataset/báo cáo liên quan.
• Mô tả (metadata): mỗi dataset có giải thích ý nghĩa, nguồn gốc, người sở hữu.
• Dòng dõi dữ liệu (data lineage): chỉ tiêu này lấy từ bảng nào, qua phép biến đổi nào — giúp truy vết khi nghi ngờ số sai.
• Nhãn tin cậy: certified / promoted / deprecated.

Catalog biến tài sản dữ liệu từ "kiến thức nằm trong đầu vài người" thành tài sản chung có thể tự khám phá.

Đào tạo và Data Literacy

Công cụ tốt và quản trị chặt vẫn vô nghĩa nếu người dùng không biết đọc dữ liệu. Data literacy — năng lực đọc, hiểu và phản biện dữ liệu — là yếu tố con người quyết định thành bại của self-service.

Cần đào tạo người dùng nghiệp vụ về:

• Cách dùng dataset chứng nhận thay vì tự kết nối nguồn thô.
• Hiểu định nghĩa chỉ tiêu chuẩn (đừng tự bịa lại "doanh thu").
• Phân biệt tương quan và nhân quả, tránh kết luận vội từ biểu đồ.
• Ý thức bảo mật: không xuất dữ liệu khách hàng ra ngoài hệ thống có kiểm soát.

Đầu tư vào con người thường mang lại hiệu quả cao hơn đầu tư thêm vào công cụ.

Vận hành: Refresh, hiệu năng và quota

Phần cuối cùng nhưng thiết thực hằng ngày là vận hành.

• Lịch refresh: dataset cần được cập nhật theo nhịp phù hợp (theo giờ, cuối ngày, theo thời gian thực). Phải giám sát để phát hiện refresh thất bại — một dashboard hiển thị số liệu cũ mà người dùng tưởng là mới còn nguy hiểm hơn không có dashboard.
• Giám sát hiệu năng dashboard: dashboard mở chậm sẽ khiến người dùng bỏ. Theo dõi thời gian tải, tối ưu mô hình (giảm cột thừa, dùng aggregate), tránh truy vấn nặng vào giờ cao điểm.
• Quota và tài nguyên: giới hạn dung lượng workspace, số lần refresh, tài nguyên tính toán để một báo cáo "ngốn tài nguyên" không làm chậm cả hệ thống. Quota cũng là cách nhẹ nhàng khuyến khích người dùng dọn dẹp tài sản không dùng.

Bối cảnh ngân hàng

Tổng hợp lại trong bối cảnh ngân hàng, governed self-service đặc biệt nhạy cảm vì:

• Dữ liệu khách hàng (số dư, giao dịch, PII) là thông tin bí mật theo luật. RLS + OLS không phải tính năng "nice to have" mà là yêu cầu tuân thủ bắt buộc.
• Số liệu báo cáo NHNN phải tuyệt đối nhất quán — semantic layer và dataset chứng nhận đảm bảo mọi báo cáo dùng cùng định nghĩa NPL, CAR, dư nợ.
• Audit trail: ai xem gì, ai sửa gì, khi nào — cần được ghi lại để phục vụ kiểm toán nội bộ và thanh tra.
• Phân tách môi trường: dev/test/prod tách biệt để thử nghiệm không chạm vào dữ liệu thật của khách hàng.

Tóm tắt

Self-service BI cho phép người dùng nghiệp vụ tự tạo báo cáo, mang lại tốc độ và giảm tải cho IT, nhưng đi kèm rủi ro spreadmart, số liệu mâu thuẫn và lỗ hổng bảo mật. Lời giải là governed self-service: tách lớp dữ liệu nền (do Data/IT kiểm soát qua semantic layer và dataset chứng nhận) khỏi lớp khám phá (do người dùng tự do thao tác). Bảo mật được đảm bảo bằng Row-Level Security (giới hạn dòng theo chi nhánh/phạm vi) và Object-Level Security (che bảng/cột nhạy cảm). Báo cáo cần đi qua vòng đời rõ ràng từ phát triển đến loại bỏ, được hỗ trợ bởi data catalog, đào tạo data literacy và vận hành chặt chẽ (refresh, hiệu năng, quota). Trong ngân hàng, các cơ chế này không chỉ là tốt mà là yêu cầu tuân thủ bắt buộc.

Tự kiểm tra

1. Sự khác nhau cốt lõi giữa "buông lỏng self-service" và "governed self-service" là gì?
2. "Spreadmart" là gì và tại sao nó nguy hiểm cho tính nhất quán số liệu?
3. Giải thích cơ chế RLS giúp chi nhánh A chỉ thấy dữ liệu chi nhánh A — vai trò của bảng ánh xạ người dùng?
4. Phân biệt Row-Level Security và Object-Level Security qua một ví dụ ngân hàng.
5. Liệt kê các giai đoạn trong vòng đời báo cáo và giải thích tại sao bước "loại bỏ" lại quan trọng.
6. Vì sao dataset chứng nhận và semantic layer cùng phục vụ mục tiêu "single source of truth"?

Đọc tiếp

BI 12 — Case study Dashboard ngân hàng