Phân cấp và dữ liệu hai chiều
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 5 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: Bản đồ không phải là quyết định · Tiếp theo: Điểm kiểm tra 1: Steve Trucking
Câu hỏi mô-đun này trả lời: Làm sao quản lý dữ liệu mà nhiều hơn một hệ thống duy trì?
Kiến trúc dễ dàng: ERP sở hữu khách hàng, Salesforce nhận một bản sao, xong. Các doanh nghiệp thật không gọn gàng như vậy. ERP sở hữu khách hàng pháp lý và Salesforce sở hữu quan hệ bán hàng; một bộ phận sống trong SAP, một bộ phận được mua lại sống trong một ERP khác; khách hàng tiềm năng chỉ tồn tại trong Salesforce. Rồi ai đó muốn người dùng Salesforce cập nhật một trường do ERP kiểm soát, và các mũi tên bắt đầu chỉ theo cả hai chiều. Như tôi hay nói khi dạy phần này: “Thứ khó nhất là các luồng hai chiều.” Không phải vì gửi dữ liệu theo cả hai chiều khó về mặt kỹ thuật, mà vì một khi cả hai hệ thống cùng tham gia vào việc thay đổi, bạn phải cực kỳ chính xác về thẩm quyền.
Dữ liệu hai chiều không có nghĩa là hai bên quản lý chủ
Phần tiêu đề “Dữ liệu hai chiều không có nghĩa là hai bên quản lý chủ ”ERP sở hữu địa chỉ thanh toán, được sao chép vào Salesforce. Một nhân viên kinh doanh biết từ khách hàng rằng nó đã thay đổi, và nghiệp vụ muốn họ cập nhật nó mà không phải rời Salesforce. Hợp lý. Giờ dữ liệu chảy ERP → Salesforce và Salesforce → ERP. Salesforce giờ có cùng sở hữu địa chỉ thanh toán không? Không. Hướng của một tích hợp không quyết định thẩm quyền. Nhân viên kinh doanh không đang thay đổi bản sao của Salesforce. Về mặt kiến trúc, họ đang yêu cầu thay đổi giá trị có thẩm quyền. Bạn không thay đổi trường của ERP; bạn đang yêu cầu thay đổi nó. Salesforce là giao diện; ERP vẫn là bên quản lý chủ.
Điều đó thay đổi thiết kế. Nếu Salesforce sở hữu trường đó, lưu là xong. Nếu ERP sở hữu nó, “lưu” có nghĩa là Salesforce gửi địa chỉ đề xuất, ERP xác thực và chấp nhận nó, cập nhật bản chủ của mình, và gửi lại giá trị có thẩm quyền. Chỉ khi đó giá trị được quản trị mới thay đổi: yêu cầu → xác thực → chấp nhận → phát hành, không phải “cập nhật cả hai hệ thống và hy vọng chúng luôn đồng bộ”.
Một tích hợp hai chiều không tạo ra thẩm quyền hai chiều.
Khi bên quản lý chủ nói không
Phần tiêu đề “Khi bên quản lý chủ nói không ”ERP từ chối thay đổi: khách hàng không còn hoạt động, địa chỉ vi phạm một quy tắc ERP, người dùng không được thay đổi địa chỉ pháp lý, ERP đang ngừng hoạt động, hoặc ai đó đã thay đổi khách hàng trong lúc đó. Nếu Salesforce đã hiển thị địa chỉ mới, giờ chúng ta có hai sự thật, và mô-đun 1 đã cho chúng ta biết bên nào thắng: ERP. Vì vậy kiến trúc cần một trạng thái cho đã yêu cầu, chưa được chấp nhận: một giá trị đề xuất riêng, một cờ “thay đổi đang chờ”, hoặc chờ xác nhận trước khi hiển thị. Cơ chế tùy thuộc vào trường hợp sử dụng. Quy tắc thì không: đừng bao giờ để một yêu cầu bị từ chối biến thành sự thật cạnh tranh.
Vòng lặp và xung đột
Phần tiêu đề “Vòng lặp và xung đột ”Đây là một trường hợp kinh điển. ERP cập nhật Salesforce; tích hợp của Salesforce thấy một thay đổi và gửi nó đến ERP; ERP thấy một cập nhật và gửi nó trở lại. Bạn đã xây một vòng lặp rất tốn kém. Thiết kế hai chiều tốt biết một thay đổi bắt đầu từ đâu, bên quản lý chủ đã chấp nhận nó chưa, và đây là một thay đổi nghiệp vụ mới hay chỉ là tiếng vọng của một thay đổi đã được xử lý: mã định danh nguồn, dấu thời gian, siêu dữ liệu tích hợp, xử lý lũy đẳng (idempotent). Chương Tích hợp đi sâu. Nguyên tắc dữ liệu chủ thì đơn giản: hãy biết bạn đang khởi tạo một thay đổi hay phản chiếu một thay đổi.
Rồi đến xung đột. Bạn đã gặp một trường hợp ở chương 5: một nhân viên kinh doanh yêu cầu Steve’s Plumbing LLC trong khi ai đó trong ERP gõ Steve’s Plumbing L.L.C. (Bảo vệ bản ghi được quản trị). Đây là một trường hợp khác. Salesforce đề xuất 125 Main Street; gần như cùng lúc một người dùng ERP đổi nó thành 130. Bên nào thắng? Không có câu trả lời kỹ thuật chung cho mọi trường hợp. Có thể ERP luôn thắng vì nó sở hữu trường; có thể yêu cầu của Salesforce vào một hàng đợi xem xét; có thể thay đổi được chấp nhận sau cùng thắng; có thể ERP từ chối mọi cập nhật mà giá trị ban đầu đã thay đổi. Đó là xử lý đồng thời, nhưng bên dưới là một quyết định về thẩm quyền, và không khuôn mẫu tích hợp nào cứu được bạn nếu chưa ai quyết định ai được thực hiện thay đổi có thẩm quyền.
Và một trường đơn lẻ là trường hợp đơn giản. Một địa chỉ gồm tên đường, thành phố, mã bưu chính. Salesforce gửi một tên đường mới trong khi ERP vừa đổi thành phố. Bạn có để tên đường đi qua một mình không? Hay bạn xem địa chỉ là một giao dịch, để các trường cùng đi với nhau hoặc không trường nào đi, và từ chối toàn bộ thay đổi? Hãy quyết định những trường nào đi theo nhóm trước lần xung đột đầu tiên, chứ không phải sau đó.
Bất cứ khi nào thấy một tích hợp hai chiều, tôi hỏi chuyện gì xảy ra khi cả hai bên thay đổi cùng một dữ liệu? Nếu câu trả lời là “chuyện đó chắc sẽ không xảy ra”, chúng ta chưa xong. Bên nào thắng, chúng ta từ chối, xếp hàng đợi, so sánh phiên bản, hay xem xét? Trường đó có nên sửa được ở cả hai nơi không? Đôi khi thiết kế hai chiều tốt nhất là bỏ đi một chiều cho một thuộc tính nhất định: Salesforce được yêu cầu; chỉ ERP phát hành giá trị đã được chấp nhận. Dữ liệu vẫn di chuyển theo cả hai chiều, nhưng chỉ một hệ thống quản lý chủ trường đó. Sự khác biệt đó là tất cả.
Phân cấp cũng là dữ liệu chủ
Phần tiêu đề “Phân cấp cũng là dữ liệu chủ ”Các quan hệ cũng có thể là dữ liệu chủ. Một công ty mẹ toàn cầu với các khu vực Bắc Mỹ và châu Âu, mỗi khu vực có các công ty con theo quốc gia: bản thân phân cấp mang ý nghĩa. Ai là công ty mẹ? Công ty con nào nằm dưới pháp nhân nào? Những tài khoản nào được tổng hợp lên khách hàng toàn cầu? Điều đó điều khiển báo cáo, lãnh thổ, định giá, hợp đồng, rủi ro tín dụng, dịch vụ, quyền truy cập dữ liệu và phân tích. Một phân cấp có thể quan trọng ngang với các bản ghi trong nó, và nó cần cùng mức quản trị. (Kỳ thi có nêu việc quản lý phân cấp; rất dễ quên.)
Trên Salesforce, phân cấp tài khoản được xây bằng trường Parent Account. Chế độ xem phân cấp trong Lightning hiển thị tối đa 2.000 tài khoản, và chỉ những tài khoản người dùng được phép thấy; tài khoản cá nhân không được hỗ trợ trong phân cấp; và Account Site phân biệt các địa điểm của một công ty (Considerations for Using Account Hierarchy (opens in a new tab), tiếng Anh). Nhưng trường Parent Account không trả lời câu hỏi kiến trúc: ai sở hữu phân cấp?
Kiến thức hay ra thi. Hãy nắm những điều cơ bản về phân cấp tài khoản: nó được xây bằng Parent Account; giao diện Lightning hiển thị tối đa 2.000 tài khoản, chỉ những tài khoản người dùng được phép thấy; tài khoản cá nhân không được hỗ trợ; và Account Site phân biệt các địa điểm của một công ty.
Một phân cấp, nhiều bên quản lý chủ
Phần tiêu đề “Một phân cấp, nhiều bên quản lý chủ ”Theo kinh nghiệm của tôi, phân cấp được quản lý chủ chia tách. Các pháp nhân Bắc Mỹ đến từ SAP, các pháp nhân châu Âu từ một ERP khác, khách hàng tiềm năng mới được xây trong Salesforce, và một công ty con được mua lại chưa được chuyển đổi. Ai sở hữu phân cấp? Còn tùy vào nhánh. Mỗi ERP kiểm soát nhánh của mình; Salesforce kiểm soát các quan hệ khách hàng tiềm năng cho đến khi chúng được chuyển đổi. Đó là một kiến trúc hợp lệ, miễn là mọi người biết ranh giới nằm ở đâu. Hãy quyết định theo từng nhánh.
Thẩm quyền đối với phân cấp có thể được giao theo từng nhánh.
Vì vậy đừng để trường Parent Account che giấu thẩm quyền. Một người dùng đổi công ty mẹ cho một công ty con trong Salesforce. Về kỹ thuật thì quá dễ. Về kiến trúc, họ vừa thay đổi cấu trúc pháp lý của công ty sao? Nếu ERP quản lý chủ nhánh đó, có lẽ là không, nên Salesforce nên chặn nó, hoặc biến nó thành một yêu cầu thay đổi. Hoặc có thể Salesforce hợp lệ giữ một phân cấp thương mại trong khi ERP giữ phân cấp pháp lý. Khi đó có lẽ chúng hoàn toàn không nên là cùng một quan hệ.
Một công ty có thể có nhiều phân cấp hợp lệ: pháp lý, thanh toán, bán hàng, dịch vụ, địa lý. Công ty mẹ toàn cầu ký hợp đồng, các khu vực tự nhận dịch vụ, việc thanh toán đi qua một pháp nhân tài chính dùng chung, bộ phận kinh doanh quản lý theo khu vực. Phân cấp nào là thật? Tất cả; chúng trả lời những câu hỏi khác nhau. Sai lầm là giả định rằng chỉ có một. Phải có thẩm quyền rõ ràng cho mỗi loại quan hệ: nguyên tắc thuộc tính của mô-đun 1, áp dụng cho các quan hệ.
Và không phải quan hệ cha-con nào cũng là dữ liệu chủ. Gom các lần giao hàng hôm nay vào một tuyến là một quan hệ, nhưng nó mang tính giao dịch, một sự kiện vận hành. Một phân cấp khách hàng mô tả một quan hệ nghiệp vụ bền vững. Cả hai đều trông như cha-con trong mô hình; chúng không chung một vòng đời. Hãy hỏi quan hệ đó có nghĩa là gì và ý nghĩa đó kéo dài bao lâu.
Một khách hàng, hai ERP
Phần tiêu đề “Một khách hàng, hai ERP ”Khi dạy phần này, tôi hỏi cả lớp: ai đã từng làm với một khách hàng có một Salesforce và nhiều hơn một ERP? Lần nào cũng có người giơ tay. Hỏi tại sao, thì hóa ra các ERP được chia theo vùng (một cho Bắc Mỹ, một cho châu Âu), theo chức năng (một công ty ống nước mua một công ty điện, và mỗi bên giữ ERP riêng của mình), hoặc đơn giản là do lịch sử: doanh nghiệp được mua lại, và chưa ai chuyển đổi nó.
Lấy Steve’s Plumbing làm khách hàng. Công ty kinh doanh ở Bắc Mỹ, nên ERP Bắc Mỹ có một bản ghi khách hàng cho nó. Rồi công ty mở văn phòng ở Munich, và ERP châu Âu tạo một bản ghi khách hàng riêng, với mã khách hàng riêng. Cùng một công ty, hai bản ghi, hai ID. Tôi thể hiện điều đó trong một org Salesforce như thế nào? Tôi đã thấy ba cách.
Một phân cấp tài khoản. Steve’s Plumbing là tài khoản cha, với Steve’s Plumbing North America và Steve’s Plumbing Europe là các tài khoản con, mỗi tài khoản con đại diện cho bản ghi của một ERP. Điểm vướng: các tài khoản con thực ra không còn là Steve’s Plumbing nữa. Chúng là Steve’s Plumbing kinh doanh tại một vùng, và như chúng ta vừa thấy, một phân cấp mang ý nghĩa.
Các tài khoản ngang hàng. Hai tài khoản đặt cạnh nhau, mỗi tài khoản có một trường cho biết nó thuộc về ERP nào: một mã công ty, một vùng. Không có gì bị che giấu. Cái giá xuất hiện ở báo cáo: để thấy Steve’s Plumbing trên toàn thế giới, bạn cần một thứ gì đó nói rằng hai tài khoản này là cùng một công ty.
Một tài khoản, với một bản ghi con cho mỗi ERP. Một Steve’s Plumbing, và một đối tượng con có một bản ghi cho mỗi ERP, giữ ID khách hàng của ERP đó. Hai ERP hay mười. Nhân viên kinh doanh thấy một khách hàng và đặt một đơn hàng; ở hậu trường, các flow quyết định mỗi dòng đi đến ERP nào: việc điện đến ERP điện, việc ống nước đến ERP ống nước. Nhưng giờ bạn phải quyết định ERP nào là chính cho các giá trị dùng chung, như tên và địa chỉ, và chuyện gì xảy ra khi khách hàng có trong ERP này mà không có trong ERP kia.
Một khách hàng, hai ERP: ba cách thể hiện trong Salesforce.
Hãy hỏi họ giữ các ERP đồng bộ như thế nào
Phần tiêu đề “Hãy hỏi họ giữ các ERP đồng bộ như thế nào ”Vậy chọn cách nào? Trước hết: nhân viên kinh doanh nên thấy bao nhiêu phần cấu trúc ERP? Nếu họ luôn biết rằng Bắc Mỹ và châu Âu là hai mảng kinh doanh riêng, vì họ đăng nhập vào ERP này hoặc ERP kia, thì đừng giấu điều đó khỏi họ. Hãy mang cấu trúc đó vào Salesforce dưới dạng các tài khoản ngang hàng. Nếu nghiệp vụ muốn một Steve’s Plumbing duy nhất trước mắt đội kinh doanh, bạn đang hướng tới một tài khoản với một bản ghi con cho mỗi ERP.
Rồi đến câu hỏi thực sự quyết định, và nó không được quyết định trong Salesforce. Tôi hỏi khách hàng: các bạn giữ hai bản ghi đó đồng bộ giữa các ERP của mình như thế nào? Không phải những thứ cục bộ của từng ERP, như số dư; đó là dữ liệu giao dịch. Ý tôi là dữ liệu chủ: tên pháp lý, các địa chỉ. Nếu họ có một đội giữ hai ERP đồng bộ, chúng ta có thể gộp chúng thành một tài khoản. Nếu họ không giữ được chúng đồng bộ trong chính các ERP của mình, làm sao họ có thể mong chúng ta giữ chúng đồng bộ trong Salesforce? Khi đó là các tài khoản ngang hàng, hoặc một phân cấp.
Hãy nhớ ERP là gì. Đó là những hệ thống khổng lồ, mất nhiều năm để triển khai, và đi kèm cách quản lý dữ liệu chủ của riêng chúng. Salesforce sẽ không điều khiển chúng. Chúng ta không được kiểm soát các ERP. Chúng ta được kiểm soát cách thể hiện chúng trong Salesforce.
MDM ở giữa
Phần tiêu đề “MDM ở giữa ”Một số khách hàng đã giải quyết chuyện này trước khi chúng ta đến. Một công ty lớn, kinh doanh nhiều năm, nhiều ERP: họ gặp vấn đề này từ lâu trước Salesforce và đặt một sản phẩm MDM chuyên dụng ở giữa để làm trung gian giữa các ERP. Đó là MDM kiểu cùng tồn tại hoặc MDM tập trung của mô-đun 2. Giờ Salesforce không tự nối với từng ERP. Nó trỏ đến một nơi, trung tâm MDM, và nhận một cách thể hiện duy nhất của khách hàng. Tuy vậy, đừng mong gặp trường hợp này thường xuyên. Bản thân chúng đã là những dự án triển khai lớn; trong ngần ấy năm, tôi chỉ làm việc với một hệ thống như vậy hai hoặc ba lần. Và ngay cả khi có trung tâm MDM, bạn vẫn có thể cần đối tượng con đó, để mỗi đơn hàng biết nó đi đến ERP nào.
MDM ở giữa: Salesforce trỏ đến một nơi.
Steve Trucking: phân cấp của ai?
Phần tiêu đề “Steve Trucking: phân cấp của ai? ”Một Đối tác bán lẻ có cấu trúc riêng: công ty mẹ, các bộ phận khu vực, trung tâm phân phối, cửa hàng. Steve Trucking có sở hữu phân cấp đó không? Không; đối tác là bên có thẩm quyền đối với tổ chức của chính họ. Nhưng Steve Trucking có thể cần cái nhìn thương mại riêng về chính những địa điểm đó, cho hợp đồng, quản lý khách hàng, dịch vụ và báo cáo, có thể là một tài khoản con cho mỗi DC dưới đối tác. Hai phân cấp hợp lệ, hai bên có thẩm quyền. Hãy đặt tên cho chúng, và đừng giả vờ một cây biểu diễn mọi quan hệ.
Làm cho ranh giới hiện rõ
Phần tiêu đề “Làm cho ranh giới hiện rõ ”Bất cứ khi nào thẩm quyền bị chia tách, tôi muốn ranh giới hiện rõ: cách đặt tên trường, siêu dữ liệu bản ghi, mã định danh hệ thống nguồn, quyền, hành vi tích hợp, tài liệu. Điều tôi không muốn là một lập trình viên phải đọc năm tích hợp để phát hiện ra “các giá trị Parent Account này đến từ SAP, trừ khách hàng tiềm năng, trừ châu Âu”. Đó không phải là một mô hình thẩm quyền bảo trì được. Nếu phân cấp được quản lý chủ chia tách, hãy tài liệu hóa sự chia tách. Nếu thẩm quyền thay đổi khi chuyển đổi, hãy tài liệu hóa sự thay đổi. Nếu Salesforce được yêu cầu nhưng không được thực hiện một thay đổi, hãy làm cho điều đó hiển nhiên trong trải nghiệm.
Trong Salesforce, điều đó bắt đầu từ một trường. Cần có một trường nói rõ đây là dữ liệu chủ: khóa của ERP, hoặc một cờ “là dữ liệu chủ”. Hãy điều khiển khả năng sửa của các trường từ trường đó, không phải từ một loại bản ghi; với Biểu mẫu động (Dynamic Forms), bạn không còn cần một loại bản ghi để hiển thị các trường của ERP ở chế độ chỉ đọc (chương 5, Mỗi luồng một loại bản ghi). Bạn có thể cho phép tạo bản ghi bên ngoài bên quản lý chủ, nhưng hãy theo dõi các lần sửa.
Ngoài kỳ thi: AI thay đổi điều gì. Một khách hàng nói với một tác tử: “hãy đổi địa chỉ thanh toán của chúng tôi thành 125 Main Street.” Trường đó ngay trong Salesforce. Tác tử có nên cập nhật nó không? Không, nếu ERP sở hữu nó. Một tác tử cần thẩm quyền ghi, không chỉ quyền truy cập trường: hành động của nó nên mã hóa con đường đã được phê duyệt, gửi một yêu cầu thay đổi và nói “tôi đã gửi thay đổi để xử lý”, chứ không báo sai “tôi đã cập nhật địa chỉ thanh toán của bạn”.
Kiến trúc sư quyết định gì ở đây
Phần tiêu đề “Kiến trúc sư quyết định gì ở đây ”- Một lần sửa trong Salesforce thay đổi dữ liệu có thẩm quyền hay yêu cầu một thay đổi từ hệ thống sở hữu nó.
- Các luồng hai chiều phân biệt thay đổi khởi tạo với tiếng vọng thế nào, và xử lý việc từ chối, xung đột, độ trễ và lỗi ra sao.
- Ai sở hữu từng phân cấp, theo từng nhánh nếu cần.
- Với một khách hàng được giữ trong nhiều ERP: một phân cấp, các tài khoản ngang hàng, hay một tài khoản với một bản ghi con cho mỗi ERP, được quyết định bởi mức độ khách hàng giữ các ERP của mình đồng bộ tốt đến đâu.
- Các phân cấp cạnh tranh có thực sự là những quan hệ hợp lệ khác nhau không: pháp lý, thanh toán, bán hàng, dịch vụ.
- Ranh giới thẩm quyền và các con đường ghi được phê duyệt được làm cho hiện rõ thế nào với người dùng, tích hợp, lập trình viên và tác tử.
Thẩm quyền được chia sẻ không phải là vấn đề. Thẩm quyền mơ hồ mới là vấn đề. Nhiều ERP có thể quản lý chủ các nhánh khác nhau, Salesforce có thể quản lý chủ một số thuộc tính và yêu cầu thay đổi các thuộc tính khác, và nhiều phân cấp có thể mô tả một doanh nghiệp. Tất cả đều hoạt động được, miễn là với mỗi thuộc tính và quan hệ quan trọng, bạn nói được ai sở hữu nó, ai được thay đổi nó, thay đổi có thẩm quyền được thực hiện ở đâu, và chuyện gì xảy ra khi các hệ thống bất đồng. Nếu không nói được, thêm một mũi tên hai chiều trên sơ đồ cũng không sửa được.
Tìm hiểu thêm
Phần tiêu đề “Tìm hiểu thêm ”- Salesforce Help, Considerations for Using Account Hierarchy (opens in a new tab) (tiếng Anh), kiểm tra ngày 2026-10-14.