Mở đầu — vì sao bài này quan trọng
Bạn đã đi qua gần trọn khóa học: từ vẽ ERD, chuẩn hóa, thiết kế physical model, cho tới các pattern nâng cao. Bạn biết cách tạo ra một schema đẹp. Nhưng có một sự thật phũ phàng mà nhiều BA (Business Analyst) và cả kỹ sư dữ liệu học được sau vài năm đi làm: một schema đẹp không tự nó tạo ra dữ liệu đáng tin. Cái quyết định dữ liệu trong công ty có được tin tưởng, có được dùng để ra quyết định hay không, chính là data governance — quản trị dữ liệu.
Hãy hình dung thế này. Một ngân hàng có bảng customers được thiết kế hoàn hảo về mặt kỹ thuật. Nhưng phòng Tín dụng nhập số điện thoại theo một kiểu, phòng Chăm sóc khách hàng nhập kiểu khác, còn hệ thống core banking lại lấy từ nguồn thứ ba. Khi ban giám đốc hỏi "chúng ta có bao nhiêu khách hàng đang hoạt động?", ba phòng ban đưa ra ba con số khác nhau. Schema không sai. Cái sai là không ai định nghĩa "khách hàng đang hoạt động" nghĩa là gì, ai được sửa dữ liệu đó, và tuân theo tiêu chuẩn nào.
Đó chính là khoảng trống mà data governance lấp đầy. Với vai trò BA, bạn thường là người đứng giữa nghiệp vụ và kỹ thuật — nên bạn chính là người phù hợp nhất để khởi động và duy trì governance. Bài này cho bạn nền tảng để hiểu và bắt đầu làm điều đó một cách thực tế, không lý thuyết suông.
Khái niệm cốt lõi
Data governance là gì?
Data governance là tập hợp các chính sách (policies), quy trình (processes), vai trò (roles) và tiêu chuẩn (standards) giúp một tổ chức quản lý dữ liệu như một tài sản. Nói ngắn gọn: nó trả lời bốn câu hỏi:
- Ai được phép truy cập, tạo, sửa, xóa dữ liệu nào? (roles & responsibilities)
- Cái gì được coi là đúng — dữ liệu phải đạt tiêu chuẩn nào? (quality & standards)
- Như thế nào — quy trình để thay đổi định nghĩa, cấu trúc, hoặc xử lý dữ liệu? (processes)
- Theo luật nào — chúng ta phải tuân thủ quy định gì về bảo mật, riêng tư? (compliance)
- Data governance là "luật lệ và người ra luật" — mang tính chiến lược, ai chịu trách nhiệm, quy tắc là gì.
- Data management là "thực thi" — công việc kỹ thuật hằng ngày: backup, ETL, mô hình hóa (chính là những gì bạn đã học ở các bài trước).
Bốn trụ cột của governance
1. Chính sách và quy trình (Policies + Processes)
Chính sách là tài liệu quy định thành văn: ví dụ "Mọi số CMND/CCCD phải được mã hóa khi lưu trữ", "Không được xóa cứng dữ liệu giao dịch, chỉ được soft-delete". Quy trình là cách chính sách được thực thi: ví dụ quy trình xin quyền truy cập bảng lương gồm ba bước phê duyệt.
2. Vai trò và trách nhiệm (Roles + Responsibilities)
Đây là phần dễ bị bỏ quên nhất nhưng lại quan trọng nhất. Ba vai trò kinh điển:
- Data Owner (chủ sở hữu dữ liệu): thường là lãnh đạo nghiệp vụ (ví dụ Giám đốc Kinh doanh sở hữu dữ liệu khách hàng). Người này chịu trách nhiệm cuối cùng và ra quyết định về việc dữ liệu được dùng thế nào.
- Data Steward (người quản lý/chăm sóc dữ liệu): thường là BA hoặc chuyên viên nghiệp vụ. Đây là người thực thi hằng ngày — định nghĩa thuật ngữ, giám sát chất lượng, xử lý tranh chấp về định nghĩa. Rất có thể chính bạn.
- Data Custodian (người trông giữ kỹ thuật): thường là DBA hoặc kỹ sư dữ liệu, lo phần lưu trữ, an ninh, backup ở tầng hệ thống.
Governance đặt ra ngưỡng: dữ liệu phải "đủ tốt" đến mức nào để dùng được. Ví dụ: "trường email khách hàng phải hợp lệ ≥ 95%". Về riêng tư, governance phân loại dữ liệu (data classification): Công khai / Nội bộ / Nhạy cảm / Bí mật, và quy định cách xử lý từng loại.
4. Tuân thủ (Compliance)
Ở Việt Nam, mốc quan trọng là Nghị định 13/2023/NĐ-CP về Bảo vệ dữ liệu cá nhân (PDPD) và Luật Bảo vệ dữ liệu cá nhân có hiệu lực từ 2026. Governance đảm bảo công ty tuân thủ: có sự đồng ý (consent) của người dùng, có quyền được xóa dữ liệu, có nhật ký truy cập.
Data catalog và business glossary
Hai công cụ nền tảng của governance mà BA hay chạm tới:
- Business glossary (từ điển thuật ngữ nghiệp vụ): định nghĩa thống nhất "khách hàng đang hoạt động", "doanh thu thuần", "đơn hàng hoàn tất"... để cả công ty hiểu giống nhau. Đây là mở rộng của Data Dictionary bạn đã học, nhưng ở tầng nghiệp vụ.
- Data catalog: danh mục liệt kê các nguồn dữ liệu, bảng, cột, ai sở hữu, độ nhạy cảm, và nguồn gốc dữ liệu (data lineage — dữ liệu này chảy từ đâu tới đâu).
Tình huống thực tế
Tình huống 1 — Ngân hàng số và "khách hàng ma"
Một ngân hàng số tại TP.HCM (giả định gọi là TienViet Bank) có 2,3 triệu tài khoản trên hệ thống. Khi báo cáo lên Ngân hàng Nhà nước, phòng Vận hành báo 2,3 triệu; phòng Marketing lại báo 1,8 triệu "khách hàng hoạt động". Chênh lệch 500.000 khiến ban lãnh đạo hoang mang trước kỳ kiểm toán.
Điều tra ra: không có định nghĩa thống nhất về "active customer". Marketing coi active là "có đăng nhập trong 90 ngày"; Vận hành coi mọi tài khoản chưa đóng là active. Ngoài ra, có hàng chục nghìn tài khoản test và tài khoản trùng do một khách mở nhiều lần.
Cách xử lý: Ngân hàng lập một hội đồng dữ liệu (data governance council), chỉ định Data Owner là Giám đốc Khối Khách hàng cá nhân, và một BA làm Data Steward. Họ đưa ra định nghĩa chính thức trong business glossary: "Khách hàng hoạt động = có ít nhất một giao dịch tài chính trong 90 ngày gần nhất, không tính tài khoản có flag is_test = true". Con số cuối cùng chốt là 1,95 triệu, được cả tổ chức chấp nhận.
Bài học: Vấn đề không nằm ở database mà ở việc thiếu định nghĩa thống nhất và thiếu người chịu trách nhiệm. Một dòng định nghĩa trong glossary có giá trị hơn một câu SQL phức tạp.
Tình huống 2 — Sàn thương mại điện tử và Nghị định 13
Một sàn TMĐT Đông Nam Á (giả định gọi là ShopFast) mở rộng vào Việt Nam năm 2024. Đội kỹ thuật lưu số điện thoại, địa chỉ, lịch sử mua hàng của 4 triệu người dùng Việt trong một data warehouse dùng chung, ai trong công ty cũng query được để làm phân tích.
Khi Nghị định 13/2023 siết chặt, đội Pháp chế phát hiện ba rủi ro: (1) không có bản ghi consent rõ ràng cho việc dùng dữ liệu vào mục đích marketing; (2) nhân viên ở nước ngoài truy cập được dữ liệu cá nhân người Việt mà không kiểm soát; (3) không có cơ chế để người dùng yêu cầu xóa dữ liệu.
Cách xử lý: ShopFast triển khai governance theo tầng. Phân loại dữ liệu: gắn nhãn PII (Personally Identifiable Information) cho số điện thoại, địa chỉ, CCCD. Áp dụng masking — nhà phân tích chỉ thấy 090**678 thay vì số đầy đủ, trừ khi có nhu cầu hợp lệ và được phê duyệt. Xây bảng consent_records liên kết với users để lưu người dùng đồng ý mục đích nào, thời điểm nào. Thêm quy trình "right to erasure": khi khách yêu cầu xóa, một job sẽ ẩn danh hóa (anonymize) dữ liệu thay vì để tràn lan.
Bài học: Governance không chỉ là giấy tờ — nó dẫn thẳng tới các quyết định thiết kế schema (bảng consent, cột phân loại, cơ chế masking). BA hiểu governance sẽ thiết kế model "sạch" ngay từ đầu thay vì chắp vá về sau với chi phí gấp nhiều lần.
Tình huống 3 — Chuỗi bán lẻ và cái giá của "mỗi phòng một Excel"
Một chuỗi bán lẻ mỹ phẩm (giả định Bella Cosmetics) có 60 cửa hàng. Mỗi cửa hàng tự quản lý tồn kho bằng file Excel riêng, đặt tên sản phẩm mỗi nơi một kiểu: "Son đỏ 01", "SON DO 01", "son-do-mã01". Khi công ty muốn làm báo cáo tồn kho toàn hệ thống, không cách nào gộp được — cùng một sản phẩm hiện lên như ba mặt hàng khác nhau.
Cách xử lý: Công ty áp dụng master data management (MDM) — một nhánh của governance. Họ tạo một danh mục sản phẩm chuẩn (master product catalog) với mã SKU duy nhất, và ban hành quy định: mọi cửa hàng phải chọn sản phẩm từ danh mục chung, không được tự gõ tay. Một Data Steward ở trụ sở duyệt mọi yêu cầu thêm sản phẩm mới.
Bài học: Khi dữ liệu master (khách hàng, sản phẩm, nhà cung cấp) không được quản trị tập trung, mọi báo cáo phía sau đều sai. Governance ở đây tiết kiệm cho Bella hàng trăm giờ đối soát mỗi quý.
Hướng dẫn từng bước
Nếu bạn được giao nhiệm vụ khởi động governance ở một tổ chức nhỏ hoặc một dự án, đây là lộ trình thực tế:
Bước 1 — Xác định phạm vi và dữ liệu quan trọng. Đừng cố quản trị mọi thứ. Bắt đầu từ dữ liệu "critical": thường là khách hàng, sản phẩm, giao dịch. Liệt kê 5–10 thực thể quan trọng nhất.
Bước 2 — Chỉ định vai trò. Với mỗi nhóm dữ liệu, xác định Data Owner (lãnh đạo nghiệp vụ), Data Steward (thường là bạn — BA), và Data Custodian (DBA). Viết rõ ai làm gì. Không có tên người cụ thể thì governance chỉ là khẩu hiệu.
Bước 3 — Xây business glossary. Bắt đầu với 20–30 thuật ngữ hay gây tranh cãi nhất. Mỗi mục gồm: tên thuật ngữ, định nghĩa, công thức tính (nếu có), ai sở hữu, ngày cập nhật. Dùng chung một nơi (Confluence, Notion, hoặc bảng trong DB).
Bước 4 — Phân loại dữ liệu. Gắn nhãn mỗi trường: Công khai / Nội bộ / Nhạy cảm / PII. Đặc biệt đánh dấu dữ liệu cá nhân theo Nghị định 13 để biết cái gì cần bảo vệ.
Bước 5 — Đặt tiêu chuẩn chất lượng. Với vài trường quan trọng, đặt ngưỡng đo được: "email hợp lệ ≥ 95%", "trùng lặp khách hàng < 1%". Định kỳ đo và báo cáo.
Bước 6 — Thiết lập quy trình thay đổi. Ai muốn thêm bảng mới, đổi định nghĩa thuật ngữ, cấp quyền truy cập PII — phải qua bước phê duyệt nào? Viết ra một quy trình đơn giản, một trang là đủ để bắt đầu.
Bước 7 — Bắt đầu nhỏ, chứng minh giá trị, rồi mở rộng. Governance chết vì tham vọng quá lớn ngay từ đầu. Chọn một "quick win" (như tình huống định nghĩa active customer), làm cho ra kết quả, rồi lấy đó thuyết phục lãnh đạo đầu tư thêm.
Lỗi thường gặp & mẹo
Lỗi 1 — Coi governance là dự án IT thuần túy. Governance là chuyện của nghiệp vụ trước, kỹ thuật sau. Nếu để một mình phòng IT làm, các định nghĩa sẽ thiếu ngữ cảnh kinh doanh và không ai nghiệp vụ tuân theo. Mẹo: luôn có Data Owner là người nghiệp vụ ký duyệt.
Lỗi 2 — Viết chính sách 100 trang không ai đọc. Tài liệu càng dài càng ít người dùng. Mẹo: một trang chính sách rõ ràng, thực thi được, tốt hơn một cuốn sổ tay đồ sộ nằm im.
Lỗi 3 — Không có công cụ đo lường. Nếu bạn đặt tiêu chuẩn "chất lượng dữ liệu tốt" mà không đo được, nó vô nghĩa. Mẹo: mọi tiêu chuẩn phải có con số và cách đo — ví dụ một query đếm số bản ghi vi phạm chạy hằng tuần.
Lỗi 4 — Bỏ qua data lineage. Khi báo cáo sai, không ai biết dữ liệu đến từ đâu để sửa. Mẹo: ghi lại nguồn gốc cho các bảng báo cáo quan trọng, dù chỉ là một sơ đồ đơn giản.
Lỗi 5 — Governance chỉ là "cảnh sát nói không". Nếu steward chỉ biết từ chối, mọi người sẽ né tránh. Mẹo: định vị governance như dịch vụ hỗ trợ — giúp mọi người tìm và tin dữ liệu nhanh hơn, chứ không phải rào cản.
Mẹo vàng cho BA: Business glossary chính là cầu nối tự nhiên giữa vai trò BA của bạn và governance. Bạn vốn đã dành thời gian làm rõ thuật ngữ với stakeholder — hãy hệ thống hóa nó lại thành glossary chính thức, và bạn đã bước một chân vào vai trò Data Steward.
Bài tập thực hành
Bài tập 1 — Chỉ định vai trò. Với một hệ thống bạn quen thuộc (ví dụ hệ thống bán hàng của một cửa hàng), hãy liệt kê 5 nhóm dữ liệu quan trọng. Với mỗi nhóm, gán tên (giả định) cho Data Owner, Data Steward, Data Custodian và mô tả một câu trách nhiệm của mỗi người.
Bài tập 2 — Viết business glossary. Chọn 5 thuật ngữ dễ gây hiểu nhầm trong một nghiệp vụ (ví dụ: "doanh thu", "khách hàng mới", "đơn hoàn tất", "sản phẩm hết hàng", "khách hàng VIP"). Viết định nghĩa chính thức cho mỗi thuật ngữ, kèm công thức tính nếu có.
Bài tập 3 — Phân loại dữ liệu và compliance. Cho một bảng customers gồm các cột: id, full_name, phone, email, cccd_number, date_of_birth, loyalty_points, created_at. Hãy phân loại mỗi cột theo mức độ nhạy cảm (Công khai / Nội bộ / PII), chỉ ra cột nào thuộc phạm vi điều chỉnh của Nghị định 13/2023, và đề xuất một biện pháp bảo vệ (masking, mã hóa, kiểm soát truy cập) cho từng cột nhạy cảm.
Bài tập 4 (nâng cao) — Quy trình một trang. Viết một quy trình phê duyệt (dạng các bước đánh số) cho tình huống: một nhà phân tích muốn xin quyền truy cập đầy đủ vào số điện thoại khách hàng (không masking) để làm chiến dịch SMS. Ai phê duyệt? Điều kiện gì? Ghi lại ở đâu?
Tóm tắt
Data governance là bộ khung gồm chính sách, quy trình, vai trò và tiêu chuẩn để tổ chức quản lý dữ liệu như một tài sản đáng tin cậy. Nó khác với data management: governance đặt ra "làm gì và tại sao", management lo "làm như thế nào".
Những điểm cần nhớ:
- Bốn trụ cột: policies/processes, roles/responsibilities, quality/privacy standards, compliance.
- Ba vai trò cốt lõi: Data Owner (nghiệp vụ chịu trách nhiệm), Data Steward (thực thi hằng ngày — thường là BA), Data Custodian (kỹ thuật).
- Hai công cụ nền tảng BA hay chạm: business glossary và data catalog (kèm data lineage).
- Ở Việt Nam, tuân thủ Nghị định 13/2023/NĐ-CP về bảo vệ dữ liệu cá nhân là yêu cầu bắt buộc, ảnh hưởng trực tiếp tới cách bạn thiết kế schema (bảng consent, phân loại PII, masking).
- Governance thành công khi bắt đầu nhỏ, có con số đo được, và định vị như dịch vụ hỗ trợ chứ không phải rào cản.