Chiến lược org là một quyết định bản đồ

🌐 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)

Hình ảnh được tạo bằng AI

Được dịch bằng AI. Cộng đồng chưa xem xét. Đọc bằng tiếng Anh

Mô-đun 5 trong 6 của chương Hiểu dữ liệu doanh nghiệp, chương 4 của khóa học Data Architect. Mỗi mô-đun có thể đọc độc lập. Trước: Vẽ bản đồ hệ thống · Tiếp theo: Bản đồ hệ thống của Steve Trucking

Câu hỏi mô-đun này trả lời: Một org hay nhiều org, và nó chạy ở đâu?

Khi dạy các ứng viên CTA, tôi nói với họ rằng quyết định lớn nhất trong một tình huống đến trong năm hay mười phút đầu tiên: chúng ta đang xử lý bao nhiêu org Salesforce? Một org lớn? Các org theo vùng cho Bắc Mỹ, EMEA và APAC? Các org riêng cho từng đơn vị kinh doanh? Một org đặc biệt cho một quốc gia có quy định riêng? Và gắn liền với nó: các org đó chạy ở đâu?

Đây không phải chi tiết quản trị. Chúng thay đổi nơi dữ liệu nằm, các tích hợp, báo cáo, danh tính, và cách mọi người trên khắp thế giới tiếp cận hệ thống. Đó là lý do tôi coi chiến lược org là một quyết định bản đồ, và lý do tôi đưa ra nó đầu tiên.

Bắt đầu với một org

Lập trường xuất phát của tôi rất đơn giản: bắt đầu với một org. Không phải vì một org luôn đúng, mà vì tôi cần một lý do để thêm org khác. Một org cho tôi một chỗ cho dữ liệu khách hàng dùng chung, một mô hình bảo mật, một chỗ để triển khai, một bộ tích hợp, một chỗ để báo cáo. Và một org vẫn có thể hỗ trợ các đơn vị kinh doanh, quốc gia, quy trình, loại bản ghi, ứng dụng, mô hình chia sẻ và trải nghiệm khác nhau.

Vì vậy tôi không thêm một org vì châu Âu làm việc hơi khác một chút, hay một bộ phận có quy trình bán hàng riêng, hay các đơn vị kinh doanh không ưa nhau. Đó là những yêu cầu, không phải ranh giới org. Câu hỏi là: lực nào đủ mạnh để biện minh cho một org khác?

Nhiều org có cái giá của nó

Tách một org thành ba (Bắc Mỹ, châu Âu, châu Á–Thái Bình Dương) và bạn không vẽ ra ba chiếc hộp gọn gàng; bạn tạo ra những câu hỏi mới. Một khách hàng toàn cầu nằm ở đâu? Nếu nó hoạt động ở hai vùng thì sao: hai bản sao, và bản nào sở hữu nó? Làm sao báo cáo toàn cầu? ERP có tích hợp với cả ba không, kho dữ liệu có nhận ba nguồn cấp không, nhà cung cấp danh tính có kết nối với cả ba không? Chúng ta có triển khai cùng một chức năng ba lần và giữ ba mô hình dữ liệu thống nhất không? Nếu một tác tử cần cái nhìn toàn cầu về một khách hàng, nó hỏi org nào?

Hãy quay lại bản đồ hệ thống ở mô-đun 4. Một hộp Salesforce trở thành ba, và mọi mũi tên phải vẽ lại. Nhiều org không sai. Nó không bao giờ miễn phí.

Tìm những ranh giới thực sự

Điều gì có thể biện minh cho một org khác? Những ranh giới đủ thật để định hình kiến trúc: nơi cư trú dữ liệu, quy định, tách biệt pháp lý, những mô hình vận hành thực sự khác nhau, một thương vụ mua lại chưa hợp nhất, một ràng buộc lưu trữ theo vùng, cách quản trị rất khác nhau, đôi khi là quy mô hay sự cô lập. Danh sách này chưa đầy đủ. Điểm mấu chốt là phân biệt “những nhóm này khác nhau” với “những nhóm này cần một ranh giới kiến trúc”. Ngưỡng thứ hai cao hơn nhiều.

Địa lý không tự động là một chiến lược org

“Chúng tôi hoạt động ở 30 quốc gia, nên chúng tôi cần 30 org.” Không. Địa lý quan trọng khi nó mang theo một yêu cầu kiến trúc. Một công ty có thể có người dùng khắp thế giới trên một kiến trúc chung. Vì vậy tôi không đếm quốc gia; tôi hỏi cái gì đi kèm chúng. Dữ liệu được phép lưu ở đâu? Được phép xử lý ở đâu? Có giới hạn nào về việc chuyển dữ liệu cá nhân qua biên giới không? Có cam kết hợp đồng nào về nơi cư trú dữ liệu không? Một vùng có cần một dịch vụ hay nơi lưu trữ Salesforce khác không? “Có một văn phòng ở Đức” tự nó là chưa đủ.

Nơi lưu trữ là một phần của bản vẽ

Ở đây nền tảng hiện đại làm cho bản đồ hệ thống thú vị hơn. Hyperforce chạy Salesforce trên hạ tầng đám mây công cộng ở các vùng trên khắp thế giới, cho khách hàng nhiều lựa chọn và quyền kiểm soát hơn về nơi dữ liệu của họ cư trú (Salesforce Hyperforce: General Information and FAQ (opens in a new tab), tiếng Anh). Vì vậy khi tôi ghi nhãn một hộp là “Salesforce, châu Âu”, vị trí đó có thể quan trọng.

Nhưng hãy chính xác. Chọn nơi một org sống không phải là lời hứa rằng mọi byte của mọi dịch vụ đều ở lại đó. Salesforce bảo khách hàng xem tài liệu về tin cậy và tuân thủ cho Hyperforce, bao gồm các bên xử lý phụ bổ sung cho những dịch vụ họ mua (cùng nguồn). Vì vậy đừng nói “chúng tôi ở trên Hyperforce tại quốc gia X, nên mọi thứ ở lại quốc gia X”. Hãy biết bạn thực sự đang dùng những dịch vụ nào, và bạn đang đáp ứng yêu cầu nào. Và hãy để ý thứ bạn chọn: khu vực, không phải đám mây bên dưới nó. Hyperforce chạy trên AWS, có thêm Google Cloud từ cuối năm 2026, và Salesforce quyết định một org nằm trên nhà cung cấp nào; khách hàng có lý do pháp lý được ghi nhận để tránh một nhà cung cấp thì trao đổi với nhóm phụ trách tài khoản của mình (cùng nguồn).

Đừng đóng vai luật sư

Đây cũng là nơi kiến trúc sư cần biết vai trò của mình. Nếu ai đó nói: “Luật quyền riêng tư châu Âu yêu cầu một org riêng”, tôi sẽ không chấp nhận một cách mù quáng. Tôi cũng sẽ không tự phong mình làm luật sư của công ty và tuyên bố rằng không phải vậy. Tôi sẽ hỏi: chúng ta đang đáp ứng yêu cầu cụ thể nào? Nơi dữ liệu được lưu, nơi nó được xử lý, chuyển giao qua biên giới, ai có thể truy cập để hỗ trợ, một hợp đồng, chính sách nội bộ? Rồi tôi làm việc với bộ phận quyền riêng tư, bảo mật, tuân thủ và pháp chế để biến yêu cầu đó thành kiến trúc. Đừng bịa ra yêu cầu pháp lý, và đừng phớt lờ chúng. Hãy chuyển dịch chúng.

Khi châu Âu có org riêng

Đây là một ranh giới tôi gặp trong các tình huống thực tế. Một công ty có hiện diện lớn ở Mỹ và hiện diện lớn ở châu Âu: hai cơ sở khách hàng lớn, hai bộ phận kinh doanh và dịch vụ, và một chương trình bảo vệ quyền riêng tư ở châu Âu xây quanh GDPR. GDPR không nói “bạn cần một org Salesforce riêng”. Nó đặt ra các quy tắc cho dữ liệu cá nhân, bao gồm khi nào được phép chuyển dữ liệu ra khỏi EU (GDPR, Chương V (opens in a new tab)). Nhưng công ty này, cùng với các nhóm quyền riêng tư và pháp lý của mình, quyết định rằng dữ liệu cá nhân của khách hàng châu Âu nên nằm trong một org được lưu trữ ở châu Âu, do nhóm châu Âu vận hành, theo cơ chế quản trị châu Âu. Đó là một yêu cầu thật, và đó là yêu cầu của họ, không phải của tôi.

Giờ “một org toàn cầu lớn” không còn là sở thích nữa. Có một ranh giới trên bản đồ hệ thống, Salesforce AMER và Salesforce EMEA, và tôi phải vẽ nó. Và org thứ hai không bao giờ chỉ là thêm một chiếc hộp.

Click to enlarge

Hai org, AMER và EMEA. Màu hổ phách là những gì org thứ hai thêm vào: không phải thêm một chiếc hộp, mà là mọi mũi tên thêm một lần nữa.

Đi lại các mũi tên lần nữa

Với hơn một org, hãy đi lại bản đồ hệ thống. ERP có gửi sản phẩm đến mọi org không? Mỗi org có gửi đơn hàng trở lại không? Khách hàng được quản lý chủ ở đâu, và dữ liệu của họ có được vượt qua các vùng không? Tầng tích hợp là toàn cầu hay theo vùng? Nhà cung cấp danh tính nào đăng nhập cho người dùng nào? Dữ liệu phân tích đi đâu?

Ba nơi cho thấy cái giá nhanh nhất:

Báo cáo. CEO muốn một pipeline toàn cầu. Trong một org, đó là một báo cáo Salesforce. Trong ba org, đó là một bài toán báo cáo doanh nghiệp: sao chép, gửi vào kho dữ liệu, liên kết dữ liệu? Nó phải cập nhật đến đâu, và các org có định nghĩa “pipeline” giống nhau không? Phân tích nằm ở đâu đi theo dữ liệu nằm ở đâu, và nếu bạn cố ý tách dữ liệu vận hành, bạn phải thiết kế cách thông tin phân tích được gom lại với nhau.

Dữ liệu chủ. Một khách hàng toàn cầu mua hàng ở Mỹ, Đức và Nhật Bản. Ba org, nên có lẽ là ba Tài khoản. Làm sao biết đó là cùng một công ty? Mã định danh toàn cầu là gì, và ai sở hữu nó? Nếu một vùng đổi địa chỉ, thay đổi có nên lan ra không? Thuộc tính nào là toàn cầu và thuộc tính nào theo vùng? Chiến lược org không giải quyết danh tính; nó thay đổi bài toán danh tính. Đó là chương 6.

Tích hợp. Một org: Salesforce, tầng tích hợp, ERP. Ba org: ba kết nối vào tầng tích hợp, có thể một org có nơi lưu trữ và kết nối riêng, một số luồng dùng chung, một số theo vùng, một số dữ liệu được phép vượt qua và một số thì không. Ngay cả mạng cũng có thể thay đổi: nếu doanh nghiệp cần kết nối riêng chuyên dụng vào Hyperforce (trên AWS, Salesforce khuyến nghị AWS Direct Connect; cùng FAQ về Hyperforce), mỗi org và nơi lưu trữ trên bản vẽ là thêm một kết nối cần lên kế hoạch. Nơi một org chạy có thể thay đổi cách phần còn lại của doanh nghiệp tiếp cận nó.

Một org hay nhiều org là quyết định bạn đưa ra ngay bây giờ, từ đầu, trên bản đồ hệ thống. Cách các org sau đó chia sẻ dữ liệu (Salesforce Connect giữa các org, tích hợp giữa chúng, Data 360) là phần cơ chế, và chương 14, Một org hay nhiều org? (coming soon), trình bày điều đó.

Nếu bạn thiết kế toàn bộ mô hình dữ liệu và kiến trúc tích hợp rồi mới nghe “nhân tiện, cái này phải là ba org”, bạn không chỉ điều chỉnh nhỏ. Bạn đã thay đổi kiến trúc. Đó là lý do quyết định này đến trước.

Đừng tách chỉ để các hộp nhỏ hơn

Một org lớn có cảm giác phức tạp: nhiều đơn vị, đối tượng, người dùng, tích hợp. Ai đó nói: “Chẳng phải gọn gàng hơn nếu mỗi bên có org riêng sao?” Bản vẽ có thể gọn gàng hơn. Doanh nghiệp thì có thể không. Bạn đã đổi sự phức tạp bên trong lấy sự phức tạp phân tán: đồng bộ hóa, dữ liệu trùng lặp, danh tính giữa các org, báo cáo toàn cầu, nhiều quy trình phát hành, tích hợp và tự động hóa bị nhân đôi, và việc quản trị trên tất cả những thứ đó. Đôi khi đó vẫn là sự đánh đổi đúng. Nhưng tách biệt không giống với đơn giản.

Và một org cũng không miễn phí. Quản trị dùng chung quan trọng hơn, các đội có thể ảnh hưởng lẫn nhau, ranh giới bảo mật cần thiết kế cẩn thận, mô hình dữ liệu phải phục vụ nhiều nhóm, việc phát hành cần phối hợp, và các quy định theo vùng có thể ràng buộc tất cả mọi người. Vì vậy đây không phải là “Steve nói luôn luôn một org”. Khuynh hướng xuất phát của tôi là một org; rồi tôi tìm yêu cầu đủ mạnh để khiến tôi rời khỏi nó.

Làm cho quyết định hiện rõ

Nếu chiến lược org quan trọng, đừng vẽ một đám mây Salesforce chung chung. Hãy vẽ các org và ghi nhãn chúng (AMER, EMEA, bất cứ thứ gì là thật), ghi chú yêu cầu về nơi lưu trữ hay nơi cư trú dữ liệu đằng sau mỗi org, và đi qua các kết nối. Một kiến trúc sư khác phải thấy được vì sao mỗi ranh giới tồn tại. Nếu tôi không giải thích được vì sao có ba hộp Salesforce, tôi chưa hoàn tất quyết định.

Steve Trucking chạy một org, tại Mỹ, và không có gì trong bản mô tả đòi hỏi org khác. Nhưng hãy nhớ mô-đun này cho dự án cuối khóa: một thương vụ mua lại đến cùng org riêng của nó chính là loại ranh giới thử thách những câu hỏi này.

Ngoài kỳ thi: AI thay đổi điều gì. Một tác tử có thể làm cho ranh giới org trở nên vô hình với người dùng. Bên dưới, kiến trúc vẫn phải quyết định tác tử được hỏi org hay hệ thống nào, dữ liệu nào được vượt qua các vùng, và câu trả lời nào là có thẩm quyền. AI có thể giấu sự phức tạp trong trải nghiệm; nó không xóa bỏ việc quản trị hay ranh giới.

Kiến trúc sư quyết định gì ở đây

• Có lý do kiến trúc thực sự cho hơn một org không, thay vì giải quyết những khác biệt bên trong một org.
• Mỗi org chạy ở đâu, và yêu cầu nào về nơi cư trú dữ liệu, quy định, hợp đồng hay nghiệp vụ đặt nó ở đó.
• Dữ liệu nào được vượt qua ranh giới org và vùng, dữ liệu chủ có thẩm quyền ở đâu, và danh tính toàn cầu hoạt động thế nào.
• Tích hợp, danh tính, phân tích và báo cáo thay đổi thế nào khi một hộp Salesforce trở thành nhiều hộp.
• Lợi ích của sự tách biệt có đáng với kiến trúc phân tán mà nó tạo ra không.

Khi đọc một tình huống, tôi tìm quyết định này đầu tiên: một org hay nhiều org, lưu trữ ở đâu, và bị buộc bởi điều gì? Trả lời được những câu đó, phần còn lại của bản đồ hệ thống bắt đầu thành hình.

Tìm hiểu thêm

• Salesforce Help, Salesforce Hyperforce: General Information, FAQ, Migration Guide, and Security Overview (opens in a new tab) (tiếng Anh), kiểm tra ngày 2026-10-14.
• EUR-Lex, Regulation (EU) 2016/679, the General Data Protection Regulation (opens in a new tab) (tiếng Anh), Chương V (chuyển dữ liệu cá nhân sang nước thứ ba), kiểm tra ngày 2026-10-14.