Bỏ qua để đến nội dung

Vai trò và tổ chức trong data governance: CDO, data owner, data steward

Nhiều doanh nghiệp nghĩ rằng mua một phần mềm quản trị dữ liệu là xong. Thực tế ngược lại: công nghệ chỉ là một chân kiềng, hai chân còn lại — con ngườiquy trình — mới quyết định thành bại. Trong đó, con người là trụ cột quan trọng nhất. Một nền tảng tốt mà không ai chịu trách nhiệm về dữ liệu thì cũng chỉ là kho công cụ để không. Trang này giải thích ai làm gì trong một chương trình data governance: từ lãnh đạo cao nhất (CDO) tới người vận hành hằng ngày (data steward), và vì sao việc phân vai rõ ràng lại là điều kiện sống còn.

Vì sao “con người” mới là trụ cột quan trọng nhất

Phần tiêu đề “Vì sao “con người” mới là trụ cột quan trọng nhất”

Hãy hình dung một tình huống quen thuộc: phòng kinh doanh báo doanh thu quý là 120 tỷ, phòng kế toán báo 115 tỷ, ban giám đốc nhận được con số thứ ba từ hệ thống báo cáo. Ai cũng cãi nhau số của mình đúng, nhưng không ai có thẩm quyền nói số nào là chuẩn. Vấn đề ở đây không phải thiếu công cụ — mà thiếu người chịu trách nhiệm.

Data governance về bản chất là trả lời câu hỏi “ai chịu trách nhiệm về dữ liệu này” một cách có hệ thống. Khi mỗi tập dữ liệu quan trọng đều có một người chủ rõ ràng, một người vận hành cụ thể, và một cơ chế ra quyết định khi tranh chấp — thì dữ liệu mới thực sự trở thành tài sản có người trông coi. Công nghệ giúp việc trông coi đó dễ hơn, nhanh hơn, ở quy mô lớn hơn — nhưng không thay thế được người trông coi.

Một chương trình quản trị dữ liệu thường có năm nhóm vai trò, xếp từ tầm chiến lược xuống tầm vận hành:

CDO — giám đốc dữ liệu: người cầm lái

Phần tiêu đề “CDO — giám đốc dữ liệu: người cầm lái”

Là gì: CDO (Chief Data Officer) — hoặc một lãnh đạo cấp cao được giao vai trò tương đương — là người chịu trách nhiệm tổng thể cho dữ liệu của tổ chức ở cấp chiến lược. Ở doanh nghiệp Việt Nam chưa có chức danh CDO chính thức, vai trò này thường rơi vào một Phó Tổng Giám đốc phụ trách chuyển đổi số, hoặc Giám đốc Công nghệ kiêm nhiệm.

Làm gì: Đặt tầm nhìn và định hướng (“trong hai năm tới dữ liệu khách hàng phải hợp nhất và đáng tin”); bảo vệ ngân sách cho con người và nền tảng; và quan trọng nhất — tạo cam kết lãnh đạo để các phòng ban thực sự coi governance là việc bắt buộc, không phải sáng kiến của riêng phòng IT.

Vì sao quan trọng: Không có người cầm lái ở cấp đủ cao, mọi quy định quản trị đều dễ bị các phòng ban phớt lờ vì “bận việc kinh doanh”. Cam kết từ trên xuống là chất keo giữ chương trình không tan rã.

Hội đồng quản trị dữ liệu: nơi ra chính sách

Phần tiêu đề “Hội đồng quản trị dữ liệu: nơi ra chính sách”

Là gì: Hội đồng quản trị dữ liệu (data governance council / committee) là một nhóm liên phòng ban — thường gồm đại diện kinh doanh, tài chính, công nghệ, pháp chế — họp định kỳ để ra quyết định chung về dữ liệu.

Làm gì: Phê duyệt chính sách dữ liệu; quyết ưu tiên (năm nay tập trung làm sạch dữ liệu khách hàng hay dữ liệu sản phẩm trước); và đóng vai trọng tài khi hai phòng ban bất đồng về định nghĩa hay quyền sở hữu một tập dữ liệu.

Vì sao quan trọng: Dữ liệu chảy ngang qua nhiều phòng, nên nhiều quyết định không thể để một phòng đơn lẻ định đoạt. Hội đồng là nơi các bên cùng ngồi lại và quyết một lần cho cả tổ chức.

Data owner — chủ sở hữu miền dữ liệu: người chịu trách nhiệm cuối

Phần tiêu đề “Data owner — chủ sở hữu miền dữ liệu: người chịu trách nhiệm cuối”

Là gì: Data owner (chủ sở hữu dữ liệu) là người chịu trách nhiệm cuối cùng về một miền dữ liệu cụ thể — ví dụ “dữ liệu khách hàng”, “dữ liệu sản phẩm”, “dữ liệu nhân sự”. Đây thường là một lãnh đạo nghiệp vụ, không phải người IT: chủ sở hữu dữ liệu khách hàng nên là Giám đốc Kinh doanh hoặc Giám đốc Marketing, vì họ hiểu dữ liệu đó dùng để làm gì.

Làm gì: Quyết ai được truy cập dữ liệu của mình; phê duyệt định nghĩa và tiêu chuẩn cho miền đó; đặt mục tiêu chất lượng (“tỷ lệ số điện thoại khách hàng đúng định dạng phải đạt 98%”). Owner không tự tay sửa từng bản ghi — họ chịu trách nhiệm rằng việc đó được làm.

Vì sao quan trọng: Khi có người chủ rõ ràng, câu hỏi “số nào đúng” có địa chỉ để hỏi. Quyền sở hữu là nền của trách nhiệm giải trình.

Data steward — quản gia dữ liệu: người vận hành hằng ngày

Phần tiêu đề “Data steward — quản gia dữ liệu: người vận hành hằng ngày”

Là gì: Data steward (quản gia dữ liệu) là người vận hành chất lượng và metadata hằng ngày cho một miền dữ liệu, dưới sự ủy quyền của data owner. Nếu owner là “chủ nhà” chịu trách nhiệm, thì steward là “quản gia” trực tiếp chăm sóc.

Làm gì: Theo dõi và xử lý lỗi dữ liệu (phát hiện trùng lặp, thiếu thông tin, sai định dạng); bổ sung và duy trì metadata (mô tả ý nghĩa của các trường, gắn thuật ngữ nghiệp vụ); xử lý các yêu cầu thay đổi dữ liệu; và là cầu nối giữa người dùng nghiệp vụ với đội kỹ thuật.

Vì sao quan trọng: Đây là vai trò làm cho governance “sống” mỗi ngày. Nền tảng như Ataccama ONE giúp steward làm việc khả thi ở quy mô lớn: tự động phát hiện bất thường, gợi ý mô tả bằng AI, đẩy việc cần xử lý vào hàng chờ — thay vì steward phải dò tay từng bảng. Chúng tôi dành riêng một trang cho công việc này.

Là gì: Tất cả nhân viên tạo ra và sử dụng dữ liệu hằng ngày — nhân viên bán hàng nhập đơn, kế toán ghi sổ, nhân viên chăm sóc khách hàng cập nhật hồ sơ.

Làm gì: Tuân thủ quy ước nhập liệu; phản hồi khi phát hiện dữ liệu sai; và sử dụng dữ liệu một cách có trách nhiệm. Governance không phải chuyện của riêng một phòng — nó cần mọi người ở tuyến đầu cùng giữ.

Vì sao thiếu vai trò rõ ràng là lý do governance thất bại

Phần tiêu đề “Vì sao thiếu vai trò rõ ràng là lý do governance thất bại”

Đây là điểm cốt lõi cần nhấn mạnh cho người ra quyết định: phần lớn các chương trình data governance thất bại không phải vì chọn sai công cụ, mà vì không ai thực sự chịu trách nhiệm. Các dấu hiệu thường gặp:

  • “Ai cũng lo nghĩa là không ai lo.” Khi dữ liệu là “của chung”, không phòng nào nhận trách nhiệm sửa lỗi, và lỗi cứ tích tụ.
  • Giao governance cho riêng phòng IT. IT giữ hệ thống, nhưng không hiểu dữ liệu nghiệp vụ nghĩa là gì. Owner phải là người nghiệp vụ — đây là sai lầm rất dễ mắc.
  • Bổ nhiệm steward nhưng không cho thời gian. Steward kiêm nhiệm 100% việc khác thì vai trò chỉ tồn tại trên giấy.
  • Không có nơi ra quyết định. Khi hai phòng cãi nhau về một định nghĩa mà không có hội đồng phân xử, tranh chấp kéo dài vô tận.

Phân vai rõ ràng — ai sở hữu, ai vận hành, ai quyết — chính là khác biệt giữa một chương trình chạy được và một sáng kiến chết yểu.

Không có một cách tổ chức đúng cho mọi doanh nghiệp. Hai mô hình phổ biến:

  • Tập trung (centralized): Một đội governance ở trung tâm đặt ra chuẩn và kiểm soát phần lớn. Phù hợp khi tổ chức còn nhỏ, hoặc khi cần siết kỷ luật ban đầu. Ưu điểm là nhất quán; nhược điểm là dễ thành “nút thắt cổ chai” và xa rời nghiệp vụ.
  • Liên bang (federated): Một đội trung tâm đặt khung và chuẩn chung, nhưng mỗi phòng ban tự quản trị miền dữ liệu của mình theo khung đó — với owner và steward riêng. Phù hợp với doanh nghiệp lớn, nhiều phòng ban. Ưu điểm là sát nghiệp vụ và mở rộng tốt; nhược điểm là cần khung chung đủ mạnh để không “mỗi nơi một kiểu”.

Trên thực tế, nhiều doanh nghiệp Việt Nam đi theo hướng kết hợp: bắt đầu tập trung để tạo đà và kỷ luật, rồi chuyển dần sang liên bang khi đã trưởng thành.

Ví dụ Việt Nam: một ngân hàng phân vai dữ liệu khách hàng

Phần tiêu đề “Ví dụ Việt Nam: một ngân hàng phân vai dữ liệu khách hàng”

Một ngân hàng thương mại triển khai khách hàng-360 thường tổ chức như sau: Phó Tổng Giám đốc phụ trách số đóng vai CDO, bảo vệ ngân sách và cam kết toàn hàng. Hội đồng dữ liệu gồm khối Bán lẻ, khối Vận hành, khối Công nghệ và phòng Pháp chế — họp hằng tháng, ra chính sách phân loại dữ liệu nhạy cảm theo Nghị định bảo vệ dữ liệu cá nhân. Giám đốc khối Bán lẻdata owner của miền dữ liệu khách hàng, quyết định ai được xem thông tin gì. Một nhóm data steward tại khối Vận hành dùng nền tảng để hợp nhất hồ sơ trùng, chuẩn hóa số điện thoại và CCCD, xử lý hàng chờ lỗi mỗi ngày. Khi chi nhánh phát hiện một khách hàng có hai hồ sơ, họ — với tư cách người dùng nghiệp vụ — báo lên cho steward xử lý. Nhờ phân vai rõ, câu hỏi “hồ sơ nào đúng” luôn có người trả lời.

Chia sẻ: