Quản trị được thiết kế vào org
Cũng có bằng 28 ngôn ngữ khác
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Mô-đun 1 trong 6 của chương Chất lượng và quản trị dữ liệu, chương 5 của khóa học Data Architect. Mỗi mô-đun có thể đọc độc lập. Tiếp theo: Ngăn dữ liệu xấu
Câu hỏi mô-đun này trả lời: Quản trị dữ liệu có ý nghĩa gì với một kiến trúc sư, và ai làm gì?
Khi nghe đến quản trị dữ liệu, người ta nghĩ đến các cuộc họp: ủy ban, chính sách, tiêu chuẩn, một tài liệu giải thích ai phải làm gì với dữ liệu. Tất cả những thứ đó có thể là một phần của chương trình quản trị. Là kiến trúc sư, tôi quan tâm đến một câu hỏi khác: chính sách được thực thi ở đâu?
Nếu chính sách nói chỉ bộ phận Tài chính được thay đổi một trường, cái gì thực thi điều đó? Nếu nó nói ERP sở hữu bản ghi khách hàng pháp lý, cái gì ngăn ai đó trong Salesforce thay đổi nó? Nếu nó nói tổ giao hàng chỉ thấy địa chỉ của Người nhận cho các điểm dừng của chính họ, chỉ trong ngày, cái gì thực sự làm cho điều đó thành sự thật? Nếu nó nói giữ cái này bảy năm, cái gì lưu trữ hoặc xóa nó sau bảy năm? Một chính sách không có điểm thực thi phần lớn chỉ là một mong ước. Quản trị trở thành kiến trúc khi những quyết định đó được xây vào hệ thống.
Quản trị không bao giờ kết thúc
Phần tiêu đề “Quản trị không bao giờ kết thúc ”Hãy để tôi nói điều này sớm: bạn không làm xong việc quản trị. Tôi đã thấy nó lúc lên lúc xuống. Một công ty đặt sự chú ý thật sự vào chất lượng dữ liệu, và mọi thứ cải thiện. Sự chú ý chuyển đi chỗ khác, và chất lượng trượt xuống. Một tích hợp mới đi vào hoạt động, một đơn vị kinh doanh thay đổi quy trình, ai đó nhập một tệp, công ty mua lại một công ty khác, một tác tử bắt đầu ghi bản ghi, và vấn đề lại thay đổi. Mục tiêu không phải là một trạng thái hoang đường nơi mọi bản ghi hoàn hảo mãi mãi. Mà là giữ dữ liệu đủ đáng tin cậy cho nghiệp vụ và ngăn lại phần tệ nhất của dữ liệu xấu. Đó là công việc liên tục.
Khi Salesforce phần lớn đứng một mình, quản trị nghĩa là làm sạch dữ liệu ở một chỗ. Khi nó là một nút trong bản đồ hệ thống của chương 4, việc đó khó hơn, và cần thiết hơn. Giờ khách hàng nằm trong Salesforce, ERP, kho dữ liệu, hệ thống đối tác, Data 360. Ai sở hữu nó? Ai được thay đổi nó? Bản sao nào có thẩm quyền, thuộc tính nào được di chuyển, chúng được giữ bao lâu, và ai chịu trách nhiệm khi chúng sai? Đó không phải là câu hỏi cấu hình. Đó là những câu hỏi quản trị trở thành cấu hình.
Chủ sở hữu bản ghi không phải là chủ sở hữu dữ liệu
Phần tiêu đề “Chủ sở hữu bản ghi không phải là chủ sở hữu dữ liệu ”Hãy bắt đầu với từ chủ sở hữu, vì Salesforce làm nó gây nhầm lẫn. Mở một tài khoản và bạn thấy một Owner: chẳng hạn một nhân viên kinh doanh. Nhân viên đó có sở hữu dữ liệu khách hàng không? Không nhất thiết. Trên Salesforce, một bản ghi trên đối tượng có chủ sở hữu thuộc về một người dùng hay một hàng đợi; chủ sở hữu có toàn quyền truy cập, và chủ sở hữu điều khiển việc giao việc và chia sẻ qua phân cấp vai trò và quy tắc chia sẻ (Sharing and Record Access Features (opens in a new tab), tiếng Anh). Đó là quyền sở hữu bản ghi: một cơ chế của nền tảng.
Chủ sở hữu dữ liệu là một thứ khác: người hay bộ phận chịu trách nhiệm giải trình về dữ liệu như một tài sản nghiệp vụ. Tài chính có thể sở hữu thông tin khách hàng pháp lý, Vận hành sở hữu trạng thái giao hàng, Nhân sự sở hữu dữ liệu nhân viên. Salesforce thậm chí cho bạn chỗ để ghi lại điều đó: trường phân loại Data Owner trên mỗi trường (Data Classification Metadata Fields (opens in a new tab), tiếng Anh).
Ở Steve Trucking, tài khoản của một Đối tác bán lẻ có thể thuộc sở hữu của giám đốc kinh doanh quản lý đối tác đó. Nhưng danh tính pháp lý của đối tác được bộ phận Tài chính quản trị và quản lý chủ trong ERP tài chính. Kinh doanh, dịch vụ, vận hành và cổng thông tin đối tác đều cần tài khoản đó; không điều nào trong đó có nghĩa là giám đốc kinh doanh được thay đổi danh tính pháp lý của đối tác một khi Tài chính đã thiết lập nó. Tôi đã thấy các đội nhìn trường Owner và cho rằng mình đã giải quyết xong quyền sở hữu dữ liệu. Chưa đâu. Giao bản ghi không phải là trách nhiệm giải trình nghiệp vụ.
Chủ sở hữu, người quản lý dữ liệu, người vận hành
Phần tiêu đề “Chủ sở hữu, người quản lý dữ liệu, người vận hành ”Ba vai trò quản trị, ba công việc khác nhau.
Chủ sở hữu dữ liệu đặt chính sách. Họ trả lời dữ liệu có nghĩa là gì, ai được tạo và thay đổi nó, nó phải chính xác đến đâu, nó được giữ bao lâu, ai được thấy nó, hệ thống nào có thẩm quyền, và chuyện gì xảy ra khi nó sai. Kiến trúc sư không nên tự bịa ra những câu trả lời đó. Đó là một trong những lập trường vững chắc nhất của tôi: chủ sở hữu đặt chính sách; kiến trúc sư thực thi nó. Nếu Tài chính nói tên pháp lý chỉ được thay đổi qua quy trình ERP một khi khách hàng đã hoạt động, đó là một quyết định quản trị. Làm cho nó đúng một cách máy móc là việc của tôi.
Người quản lý dữ liệu giữ cho nó vận hành. Người quản lý dữ liệu (data steward) gần gũi với sức khỏe hằng ngày của dữ liệu: theo dõi các tín hiệu chất lượng, điều tra bản trùng, giải quyết ngoại lệ, điều phối việc sửa lỗi, duy trì định nghĩa, phát hiện quy trình cứ liên tục tạo ra dữ liệu xấu. Người quản lý dữ liệu còn đảm nhận hai việc nữa. Khi hai nhóm bất đồng về ý nghĩa của một trường, ai sở hữu nó hay ai được xem nó, người quản lý dữ liệu đưa tranh chấp đến chủ sở hữu và theo quyết định đến cùng. Và người quản lý dữ liệu xây dựng năng lực hiểu dữ liệu (data literacy): giúp những người nhập và sử dụng dữ liệu hiểu nó có nghĩa là gì và vì sao các quy tắc tồn tại. Một người quản lý dữ liệu cần nhiều hơn một cái tên trên sơ đồ tổ chức. Họ cần thời gian, khả năng quan sát, một quy trình, và thẩm quyền để các vấn đề được sửa. Nếu không, “người quản lý dữ liệu” trở thành trách nhiệm thứ tám của ai đó, được xem xét mỗi quý một lần.
Người vận hành chạy hệ thống. Quản trị viên, đội nền tảng, đội bảo mật: bất kỳ ai vận hành công nghệ lưu trữ và xử lý dữ liệu. Chủ sở hữu nói chỉ những vai trò này được thấy nó; người vận hành (custodian) vận hành các biện pháp kiểm soát làm cho điều đó thành sự thật. Tên gọi ít quan trọng hơn việc làm rõ từng trách nhiệm giải trình, và trong một tổ chức nhỏ, một người có thể kiêm hai vai.
Chương trình vận hành ra sao
Phần tiêu đề “Chương trình vận hành ra sao ”Các chương trình quản trị thường có ba dạng. Tập trung: một nhóm viết chính sách và tiêu chuẩn cho mọi lĩnh vực. Cách này nhất quán, và có thể trở thành nút thắt cổ chai, xa những người trực tiếp làm việc. Liên kết (federated, phi tập trung): mỗi lĩnh vực, như tài chính, bán hàng hay vận hành, tự quản trị dữ liệu của mình trong khuôn khổ một vài quy tắc chung. Cách này gần với công việc, và các định nghĩa trôi dạt khác nhau giữa các lĩnh vực. Kết hợp (hybrid): một nhóm trung tâm nhỏ sở hữu các tiêu chuẩn và định nghĩa dùng chung, còn chủ sở hữu và người quản lý dữ liệu của từng lĩnh vực tự vận hành dữ liệu của mình. Phần lớn doanh nghiệp tôi từng thấy rốt cuộc đều nằm đâu đó trong mô hình kết hợp. Với kiến trúc sư, dạng chương trình trả lời một câu hỏi thực tế: ai phê duyệt một chính sách trước khi tôi thực thi nó, và các định nghĩa dùng chung nằm ở đâu?
Kiến thức hay ra thi. Hãy biết ba cách vận hành một chương trình quản trị, tập trung, liên kết (phi tập trung) và kết hợp, và mỗi cách có ý nghĩa gì với việc ai đặt chính sách và các định nghĩa dùng chung nằm ở đâu.
Hãy để RACI xứng đáng với chỗ của nó
Phần tiêu đề “Hãy để RACI xứng đáng với chỗ của nó ”Một RACI (ai Thực hiện, ai Chịu trách nhiệm giải trình, ai được Tham vấn và ai được Thông báo) có ích, nhưng không phải một bảng tính khổng lồ được làm ra vì quản trị “yêu cầu phải có”. Tôi muốn nó trả lời các câu hỏi kiến trúc, bắt đầu với ba câu từ chương 4 (Bốn câu hỏi đằng sau các phân loại): dữ liệu được tạo ở đâu, được sửa ở đâu, và được tham chiếu ở đâu? Đó thường là những hệ thống khác nhau. Lấy một sản phẩm: ERP tạo ra nó, Salesforce tham chiếu nó, cổng thông tin hiển thị nó, kho dữ liệu phân tích nó. Giờ nghiệp vụ thay đổi ý nghĩa của “sản phẩm đang hoạt động”. Thay đổi bắt đầu ở đâu, ai phê duyệt, nó lan ra thế nào, và bản sao nào là chỉ đọc? Nếu bạn không trả lời được, bạn chưa có quản trị. Bạn có các bản sao. Một RACI tốt phơi bày chính xác sự mơ hồ đó.
Quản trị phải trở nên máy móc
Phần tiêu đề “Quản trị phải trở nên máy móc ”Nghiệp vụ nói chỉ Tài chính được thay đổi tên pháp lý của khách hàng. Tôi không muốn câu trả lời kiến trúc là “chúng ta sẽ đưa vào đào tạo”. Đào tạo có ích; nó không phải là thực thi. Có thể đó là quyền truy cập cấp trường, một quy tắc xác thực, một trường chỉ tích hợp được ghi, hoặc một quy trình có kiểm soát thay vì sửa trực tiếp. Cơ chế tùy thuộc vào yêu cầu, nhưng phải có một cơ chế:
| Chính sách quản trị | Chủ sở hữu quyết định | Điểm thực thi khả dĩ |
|---|---|---|
| ERP sở hữu danh tính khách hàng pháp lý | Tài chính | Trường chỉ tích hợp ghi, quyền, quy tắc xác thực |
| Chỉ người có nhu cầu mới thấy dữ liệu cá nhân | Quyền riêng tư, bảo mật | Chia sẻ, quyền, truy cập trường |
| Mã định danh khách hàng là duy nhất | Chủ sở hữu nghiệp vụ | ID bên ngoài duy nhất, quy tắc trùng lặp |
| Bản ghi được quản trị không được tạo thủ công | Chủ sở hữu dữ liệu | Quyền, tự động hóa, tích hợp |
| Dữ liệu nhạy cảm có thời hạn lưu giữ xác định | Quyền riêng tư, pháp chế | Một quy trình lưu giữ hoặc xóa |
| Các thay đổi quan trọng phải chứng minh được | Tuân thủ | Lịch sử trường, nhật ký kiểm toán |
| Nguồn gốc dữ liệu luôn xác định được | Chủ sở hữu dữ liệu | Một trường nguồn, siêu dữ liệu dòng dõi |
Tôi cố ý nói điểm thực thi khả dĩ. Đây không phải là bảng chọn tính năng. Đó là thứ tự tư duy: chính sách là gì, ai sở hữu nó, và cái gì trong kiến trúc làm cho nó thành sự thật?
Chủ sở hữu đặt chính sách; kiến trúc sư thực thi nó.
Đừng dựa vào hành vi tốt
Phần tiêu đề “Đừng dựa vào hành vi tốt ”“Không bao giờ được thay đổi ID khách hàng của ERP.” Ai cũng biết điều đó, cho đến khi có người làm: do vô tình, qua một lần nạp dữ liệu, qua tự động hóa, qua một tích hợp, qua một tác tử. Nếu thay đổi nó sẽ làm hỏng dữ liệu doanh nghiệp, “xin đừng” không phải là biện pháp kiểm soát. Hãy xây biện pháp kiểm soát. Tin tưởng, nhưng kiểm chứng. Con người, tích hợp, tự động hóa và AI đều mắc lỗi, nên kiến trúc nên giả định rằng sớm muộn sẽ có thứ gì đó thử làm điều chính sách cấm. Khi đó chuyện gì xảy ra?
Quản trị vượt qua ranh giới hệ thống
Phần tiêu đề “Quản trị vượt qua ranh giới hệ thống ”Quay lại bản đồ hệ thống. ERP sở hữu khách hàng; Salesforce, kho dữ liệu và một nền tảng dữ liệu khách hàng giữ bản sao; một đối tác nhận một phần. Chính sách áp dụng cho hệ thống nào? Tất cả. Salesforce có thể chặn đúng việc đổi tên pháp lý trong khi một tích hợp để một hệ thống phía sau ghi đè nó. Salesforce có thể xóa dữ liệu cá nhân mà kho dữ liệu vẫn còn giữ. Một trường được phân loại là nhạy cảm trong Salesforce có thể rơi vào một trường văn bản chưa phân loại ở chỗ khác. Quản trị không thể dừng ở rìa org, vì dữ liệu không dừng ở đó. Đó là lý do chương 4 đến trước: bản đồ hệ thống cho bạn biết quản trị phải vươn xa đến đâu.
Quản trị vừa đủ, không phải mọi thứ
Phần tiêu đề “Quản trị vừa đủ, không phải mọi thứ ”Thất bại ngược lại cũng thật không kém. Chúng ta phát hiện quản trị quan trọng, nên khóa mọi thứ lại: không ai được tạo, mọi thay đổi đều cần phê duyệt. Dữ liệu được quản trị, và không ai làm được việc của mình. Quản trị nghĩa là biện pháp kiểm soát phù hợp cho dữ liệu: chặt với một số, nhẹ với một số khác. Một số bản ghi có thể được tạo tự do, một số cần phê duyệt; một số trường gần như ai cũng sửa được, một số chỉ tích hợp được sửa. Mô-đun tiếp theo đi vào thực tế chính xác điều đó.
Và vì quản trị không bao giờ kết thúc, việc thực thi cần phản hồi. Bản trùng có đang tăng không? Các trường bắt buộc có đang đầy rác không? Tích hợp có đang thất bại, người dùng có đang tìm cách lách, ngoại lệ có đang tăng, người quản lý dữ liệu có đang dành cả ngày cho một vấn đề không? Những tín hiệu đó cho bạn biết thiết kế có đang hoạt động không, và đôi khi cho biết biện pháp kiểm soát, hoặc chính sách, cần thay đổi.
Ngoài kỳ thi: AI thay đổi điều gì. Quản trị có một bên tiêu thụ mới: tác tử. Chủ sở hữu dữ liệu vẫn quyết định cái gì được dùng và dùng cho việc gì; kiến trúc sư vẫn làm cho nó thực thi được. Điều thay đổi là tốc độ và quy mô. Một tác tử đọc, kết hợp và hành động trên dữ liệu được quản trị nhanh hơn con người rất nhiều, nên một chính sách chỉ tồn tại trong tài liệu còn bảo vệ được ít hơn nữa.
Kiến trúc sư quyết định gì ở đây
Phần tiêu đề “Kiến trúc sư quyết định gì ở đây ”- Ai chịu trách nhiệm giải trình cho từng miền dữ liệu quan trọng, và điều đó khác với quyền sở hữu bản ghi thế nào.
- Ai quản lý dữ liệu và ai vận hành nó với vai trò người vận hành.
- Dữ liệu quan trọng được tạo, sửa, tham chiếu và quản lý chủ ở đâu trên bản đồ hệ thống.
- Điểm thực thi nào làm cho mỗi chính sách quan trọng đúng một cách máy móc.
- Kiến trúc cho thấy quản trị đang hoạt động, hay bắt đầu trượt, như thế nào.
Khi nghe một yêu cầu quản trị, tôi chuyển dịch nó. “ERP sở hữu cái này.” “Chỉ những người này được thấy cái này.” “Chúng ta cần chứng minh ai đã thay đổi cái này.” “Giữ cái này bảy năm.” Mỗi lần: hãy cho tôi thấy điểm thực thi. Kiến trúc sư không quyết định chính sách. Chúng ta thiết kế hệ thống thực thi nó. Đó là nơi quản trị thôi là một tài liệu và trở thành kiến trúc.
Tìm hiểu thêm
Phần tiêu đề “Tìm hiểu thêm ”- Salesforce Help, Sharing and Record Access Features (opens in a new tab) (tiếng Anh), kiểm tra ngày 2026-10-14.
- Salesforce Help, Data Classification Metadata Fields (opens in a new tab) (tiếng Anh), kiểm tra ngày 2026-10-14.