Bốn cách quản lý dữ liệu chủ
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 2 trong 6 của chương Dữ liệu chủ và danh tính, chương 6 của khóa học Data Architect. Mỗi mô-đun có thể đọc độc lập. Trước: Một nguồn sự thật cho mỗi thuộc tính · Tiếp theo: Khớp, gộp và giữ lại
Câu hỏi mô-đun này trả lời: Các tổ chức quản lý dữ liệu chủ thế nào, và kiểu nào phù hợp?
Mô-đun 1 nói thẩm quyền được giao theo từng thuộc tính. Giờ: chúng ta làm gì khi những thuộc tính đó cùng lúc nằm trong nhiều hệ thống? Thông tin khách hàng trong Salesforce, ERP, hệ thống thanh toán, hỗ trợ, có thể Data 360, có thể một kho dữ liệu, mỗi nơi có phiên bản riêng. Đó là bài toán mà quản lý dữ liệu chủ (MDM) cố giải quyết, và MDM không phải là một kiến trúc duy nhất. Bạn sẽ nghe bốn khuôn mẫu: registry, hợp nhất (consolidation), cùng tồn tại (coexistence) và tập trung (centralized). Chúng không phải là thiết lập sản phẩm. Chúng là bốn câu trả lời cho một câu hỏi: tầng quản lý dữ liệu chủ có bao nhiêu thẩm quyền?
Bắt đầu từ bài toán, không phải sản phẩm
Phần tiêu đề “Bắt đầu từ bài toán, không phải sản phẩm ”Người ta nghe MDM và bắt đầu đi mua một sản phẩm MDM. Tôi sẽ bắt đầu từ bài toán. Chúng ta chỉ cần biết rằng nhiều bản ghi là cùng một khách hàng? Chúng ta cần một cái nhìn kết hợp cho phân tích? Chúng ta cần quyết định giá trị nào có thẩm quyền và đẩy chúng ngược lại các hệ thống khác? Hay chúng ta muốn một hệ thống trung tâm tạo dữ liệu chủ cho tất cả mọi người? Những yêu cầu rất khác nhau, những kiến trúc rất khác nhau.
Registry: cho tôi biết ai là ai
Phần tiêu đề “Registry: cho tôi biết ai là ai ”Khuôn mẫu nhẹ nhất. Một registry (sổ đăng ký) không thay thế các nguồn. ERP giữ khách hàng của nó, Salesforce giữ tài khoản của nó, hệ thống thanh toán giữ khách hàng của nó, và registry xác định rằng những bản ghi này đại diện cho cùng một thực thể: tài khoản Salesforce 001…, khách hàng ERP SAP-43821 và khách hàng thanh toán BILL-9127 thuộc về một khách hàng. Các nguồn ở nguyên chỗ và không bị ghi đè. Giờ câu “cho tôi xem mọi thứ chúng ta biết về khách hàng này” có câu trả lời.
Nhưng hãy để ý những gì registry không trả lời. Salesforce nói 123 Main Street, ERP nói 125, hệ thống thanh toán nói “123 Main St., Suite 200”. Registry biết chúng thuộc về nhau. Nó không quyết định cái nào nên thay đổi. Liên kết không phải là quản lý.
Theo kinh nghiệm của tôi, registry là chuẩn mực trong các dự án Salesforce, rồi đến hợp nhất và cùng tồn tại; MDM tập trung thuần túy thì hiếm. Registry phổ biến vì nó không xâm lấn. Bạn không phải thiết kế lại mọi hệ thống vận hành trước khi có được giá trị. Salesforce tiếp tục làm việc của nó, ERP tiếp tục làm việc của nó, và bạn thêm một tầng danh tính. Đó là một thay đổi nhỏ hơn nhiều so với việc bảo mọi hệ thống “bạn không còn kiểm soát dữ liệu khách hàng nữa; hệ thống trung tâm mới này kiểm soát”.
Sổ đăng ký trả lời: những bản ghi nào thuộc về cùng một thực thể?
Hợp nhất: gom dữ liệu lại
Phần tiêu đề “Hợp nhất: gom dữ liệu lại ”Hợp nhất lấy dữ liệu từ nhiều nguồn và kết hợp chúng thành một biểu diễn trung tâm, cho báo cáo, phân tích, phân khúc, thông tin khách hàng. Một kho dữ liệu là ví dụ quen thuộc: Salesforce gửi khách hàng, ERP gửi số liệu tài chính, hệ thống thanh toán gửi các khoản thanh toán, và cuối cùng nghiệp vụ có thể phân tích khách hàng qua các hệ thống. Các nguồn vẫn tồn tại và có thể vẫn có thẩm quyền. Hướng đi quan trọng: dữ liệu chảy vào hệ thống hợp nhất, vốn thường không đẩy các thay đổi đã được quản lý chủ ngược lại. Một bức tranh tốt hơn về khách hàng, mà không trở thành bên có thẩm quyền vận hành đối với nó.
Registry và hợp nhất rất dễ bị nhầm lẫn. Sự khác biệt là cái gì được tập trung: registry tập trung danh tính (“những thứ này thuộc về nhau”); hợp nhất tập trung nhiều dữ liệu hơn (“gom các thuộc tính lại để chúng ta dùng được”). Không cái nào nói “hệ thống trung tâm này giờ là bên quản lý chủ và mọi ứng dụng phải chấp nhận giá trị của nó”.
Hợp nhất gom dữ liệu lại mà không lấy đi quyền sở hữu của các nguồn.
Cùng tồn tại: quyết định, rồi gửi ngược lại
Phần tiêu đề “Cùng tồn tại: quyết định, rồi gửi ngược lại ”Trong cùng tồn tại, tầng quản lý dữ liệu chủ có thẩm quyền thật sự. Dữ liệu vẫn nằm trong nhiều hệ thống vận hành, nhưng quy trình MDM quyết định giá trị được quản lý chủ và phát hành nó ngược lại. Salesforce, ERP và hệ thống thanh toán mỗi bên có một tên pháp lý khác nhau; quy trình MDM xác định tên được quản trị và phân phối nó cho cả ba. Các hệ thống cùng tồn tại, nhưng chúng hội tụ về giá trị được quản lý chủ.
Đó là một hình thức MDM mạnh hơn nhiều. Nó không nói “những thứ này thuộc về nhau”; nó nói “với thuộc tính này, đây là giá trị doanh nghiệp sử dụng”. Điều đó đòi hỏi nhiều hơn việc khớp: quy tắc nghiệp vụ, quyền sở hữu, quy tắc giữ lại, tích hợp hai chiều, xử lý lỗi và quản trị, vì phải có ai đó quyết định vì sao một giá trị thắng.
Cùng tồn tại không chỉ liên kết các bản ghi. Nó quyết định các giá trị được quản lý chủ và gửi chúng trở lại.
Tập trung: bên quản lý chủ tạo ra sự thật
Phần tiêu đề “Tập trung: bên quản lý chủ tạo ra sự thật ”Khuôn mẫu mạnh nhất. Trong MDM tập trung, dữ liệu chủ được quản trị được tạo và duy trì trong bên quản lý chủ trung tâm rồi phân phối cho mọi bên khác. Thay vì mỗi hệ thống tự tạo khách hàng và MDM đối chiếu chúng sau đó, bạn tạo khách hàng được quản trị trong bên quản lý chủ, rồi gửi nó đến Salesforce, ERP và hệ thống thanh toán. Quản trị rất mạnh, và thay đổi rất lớn: các quy trình hiện có tự tạo khách hàng, người dùng có quy trình làm việc của họ, các tích hợp giả định việc tạo tại chỗ, và các đơn vị kinh doanh có thể còn chưa thống nhất khách hàng là gì. Đó là lý do nó hiếm trong các bản đồ Salesforce mà tôi gặp. Nó có thể đúng. Đó là một quyết định lớn hơn nhiều so với việc cài đặt một công cụ.
MDM tập trung chuyển việc tạo và thẩm quyền vào bên quản lý chủ.
Bốn kiểu đặt cạnh nhau
Phần tiêu đề “Bốn kiểu đặt cạnh nhau ”| Kiểu | Cái gì được tập trung | Các nguồn có còn không? | Có đẩy giá trị được quản trị ngược lại không? |
|---|---|---|---|
| Registry | Danh tính và liên kết | Có | Thường là không |
| Hợp nhất | Danh tính cộng dữ liệu kết hợp | Có | Thường là không |
| Cùng tồn tại | Danh tính, dữ liệu và các quyết định quản lý chủ | Có | Có |
| Tập trung | Việc tạo và thẩm quyền | Có, với vai trò bên tiêu thụ | Có |
Càng xuống dưới bảng, tầng quản lý dữ liệu chủ càng có nhiều thẩm quyền, và tổ chức thường phải thay đổi nhiều hơn.
Kiến thức hay ra thi. Hãy nắm bốn kiểu triển khai MDM: sổ đăng ký (registry) (liên kết danh tính; các nguồn giữ dữ liệu của mình), hợp nhất (gom dữ liệu lại, thường để phân tích), cùng tồn tại (quyết định các giá trị được quản lý chủ và phát hành chúng ngược lại các nguồn) và tập trung (bên quản lý chủ tạo ra dữ liệu; các nguồn sử dụng nó).
Vì vậy không có chuyện “tập trung là trưởng thành nhất, nên ai cũng phải đến đó”. Hãy chọn khuôn mẫu nhẹ nhất giải quyết được bài toán. Cần biết các bản ghi thuộc về nhau? Hãy nghĩ đến registry. Một cái nhìn kết hợp cho phân tích? Hợp nhất. Giá trị được quản trị đồng bộ ngược lại nhiều hệ thống vận hành? Cùng tồn tại. Một quy trình tạo và kiểm soát dữ liệu chủ cho mọi bên? Tập trung.
Data 360 nằm ở đâu?
Phần tiêu đề “Data 360 nằm ở đâu? ”Data 360 xây dựng hồ sơ hợp nhất qua nhiều nguồn, nghe rất giống MDM, và nó giải quyết được một phần bài toán. Phân giải danh tính của nó khớp các hồ sơ nguồn thành một danh tính hợp nhất và giữ liên kết ngược về các bản ghi nguồn (Data 360 Architecture (opens in a new tab), tiếng Anh). Điều đó khiến nó gần nhất với một registry. Nó cũng có thể hiển thị các giá trị đã được đối chiếu trên hồ sơ hợp nhất. Nhưng điều đó không biến nó thành một hệ thống bản ghi vàng tập trung ghi đè lên các nguồn. Một cái nhìn hợp nhất không tự động là một bản ghi doanh nghiệp được quản lý chủ. Mô-đun 4 nói trọn về sự khác biệt đó.
Một mô hình chung không phải là một sự thật chung
Phần tiêu đề “Một mô hình chung không phải là một sự thật chung ”Bạn cũng sẽ nghe đến mô hình dữ liệu chuẩn tắc (canonical data model). Account của Salesforce, business partner của ERP và customer của hệ thống thanh toán đều ánh xạ vào một khái niệm doanh nghiệp đã thống nhất, Khách hàng, với các mã định danh và thuộc tính đã thống nhất, để mỗi tích hợp không phải hiểu hình dạng của mọi hệ thống khác. Mô hình dữ liệu của Data 360 là một ví dụ về việc hài hòa hóa các nguồn thành những khái niệm chung. Nhưng một mô hình chuẩn tắc trả lời làm sao biểu diễn thứ này một cách nhất quán? MDM trả lời làm sao nhận diện, quản trị và quản lý chủ nó qua các hệ thống? Ánh xạ cả ba hệ thống hoàn hảo vào một hình dạng Khách hàng, và Salesforce vẫn nói 123 Main Street trong khi ERP nói 125. Bạn đã giải quyết cấu trúc, không phải thẩm quyền. Hài hòa hóa và quản lý dữ liệu chủ không thể thay thế cho nhau.
Một doanh nghiệp, nhiều khuôn mẫu
Phần tiêu đề “Một doanh nghiệp, nhiều khuôn mẫu ”Vì vậy “Steve Trucking cần MDM” không phải là một yêu cầu. Cho cái gì? Đối tác bán lẻ, trung tâm phân phối, tổ giao hàng, xe tải, Người nhận là những miền khác nhau với những bên có thẩm quyền khác nhau: Đối tác bán lẻ được quản trị trong Salesforce và ERP tài chính, danh tính xe tải từ FleetLink, mỗi Người nhận do một đối tác cung cấp cho mỗi lần giao hàng. Các miền khác nhau có thể dùng những khuôn mẫu khác nhau, và trong một miền, các thuộc tính có thể có những bên có thẩm quyền khác nhau. Vì vậy đừng vẽ một hộp ghi nhãn MDM ở giữa sơ đồ rồi gọi là đã giải quyết xong. Hãy hỏi chiếc hộp đó làm gì.
Kiểu quản lý cũng thay đổi tích hợp. Registry cần liên kết danh tính; hợp nhất cần các luồng vào đáng tin cậy; cùng tồn tại cần dữ liệu theo cả hai chiều; tập trung cần phân phối từ bên quản lý chủ cộng với các biện pháp kiểm soát ngăn các hệ thống khác tạo ra sự thật đối địch. Khi thẩm quyền tăng, sự phối hợp cũng tăng, và việc xử lý lỗi cũng vậy: nếu MDM thay đổi tên pháp lý và ERP từ chối nó thì sao? Đó là lý do cùng tồn tại và tập trung không phải là “registry có thêm tính năng”. Chúng mang những trách nhiệm vận hành khác nhau.
MDM là một quyết định nghiệp vụ
Phần tiêu đề “MDM là một quyết định nghiệp vụ ”Điểm quan trọng nhất: MDM về cơ bản không phải là một quyết định công nghệ. Đó là một quyết định về thẩm quyền. Ai tạo khách hàng, ai được thay đổi nó, ai quyết định giá trị nào thắng, những hệ thống nào phải chấp nhận nó, chuyện gì xảy ra khi chúng bất đồng. Một công cụ có thể hiện thực những quyết định đó; nó không thể khiến tổ chức đồng thuận về chúng. Đó là lý do một dự án MDM có thể có công nghệ xuất sắc mà vẫn thất bại: đội kỹ thuật đã giải quyết việc khớp, còn nghiệp vụ chưa bao giờ giải quyết quyền sở hữu.
Bài học chung tôi đã học một cách khó khăn: khi nhiều hệ thống cùng quản lý chủ một dữ liệu, Salesforce không thể đối chiếu những gì chúng không đồng thuận. Khi một công ty chạy hai ERP, tôi hỏi họ giữ hai hệ thống đồng bộ như thế nào. Nếu họ không làm được, Salesforce cũng không làm được. Mô-đun 5 kể câu chuyện đó (Một khách hàng, hai ERP).
Kiến trúc sư quyết định gì ở đây
Phần tiêu đề “Kiến trúc sư quyết định gì ở đây ”- Bài toán cần liên kết danh tính, dữ liệu kết hợp, giá trị được quản lý chủ đẩy ngược lại, hay việc tạo tập trung.
- Khuôn mẫu nào phù hợp với từng miền dữ liệu, thay vì một khuôn mẫu cho cả doanh nghiệp.
- Tầng quản lý dữ liệu chủ được trao bao nhiêu thẩm quyền, và những hệ thống nào phải chấp nhận các quyết định của nó.
- Có cần một mô hình chuẩn tắc không, mà không nhầm lẫn hài hòa hóa với thẩm quyền.
- Khuôn mẫu được chọn thay đổi hướng tích hợp, quyền sở hữu và việc xử lý lỗi thế nào.
Khi ai đó đặt một hộp MDM lên sơ đồ, hãy hỏi nó làm gì. Nó có biết những bản ghi nào thuộc về nhau không? Có kết hợp dữ liệu của chúng không? Có quyết định giá trị nào thắng không? Có đẩy những quyết định đó ngược lại không? Có tạo ra dữ liệu ngay từ đầu không? Các câu trả lời cho bạn biết bạn thực sự có kiến trúc nào, và thẩm quyền nằm ở đâu.
Tìm hiểu thêm
Phần tiêu đề “Tìm hiểu thêm ”- Salesforce Architects, Data 360 Architecture (opens in a new tab) (tiếng Anh), kiểm tra ngày 2026-10-14.