Стратегія org — це рішення рівня ландшафту

🌐 Також доступно 28 мовами

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Зображення згенеровано ШІ

Перекладено ШІ. Спільнота ще не перевірила. Читати англійською

Модуль 5 з 6 розділу Розуміння корпоративних даних, розділ 4 курсу Data Architect. Кожен модуль самостійний. Попередній: Намалюйте системний ландшафт · Наступний: Ландшафт Steve Trucking

Питання, на яке відповідає цей модуль: Одна org чи кілька і де вона працює?

Навчаючи кандидатів у CTA, я кажу їм, що найбільше рішення в сценарії ухвалюється в перші п’ять-десять хвилин: зі скількома org Salesforce ми маємо справу? Одна велика org? Регіональні org для Північної Америки, EMEA і APAC? Окремі org для окремих підрозділів? Спеціальна org для країни з власними правилами? І з цим безпосередньо пов’язане: де ці org працюють?

Це не адміністративні дрібниці. Вони змінюють, де живуть дані, інтеграції, звітність, ідентичність і те, як люди в усьому світі дістаються до системи. Тому я вважаю стратегію org рішенням рівня ландшафту і ухвалюю його першим.

Почніть з однієї org

Моя відправна позиція проста: почніть з однієї org. Не тому, що одна org завжди правильна, а тому, що мені потрібна причина додати ще одну. Одна org дає одне місце для спільних даних клієнтів, одну модель безпеки, одне місце для розгортання, один набір інтеграцій, одне місце для звітів. І одна org усе одно може підтримувати різні підрозділи, країни, процеси, типи записів, застосунки, моделі спільного доступу й досвіди.

Тож я не додаю org через те, що Європа робить щось трохи інакше, чи в підрозділу власний процес продажів, чи підрозділи не люблять одне одного. Це вимоги, а не межі org. Запитання таке: яка сила достатньо потужна, щоб виправдати ще одну org?

Кілька org мають ціну

Розділіть одну org на три (Північна Америка, Європа, Азійсько-Тихоокеанський регіон) — і ви не намалювали три охайні прямокутники; ви створили нові запитання. Де живе глобальний клієнт? Що, як він працює у двох регіонах: дві копії, і котра ним володіє? Як хтось звітує глобально? ERP інтегрується з усіма трьома, сховище даних отримує три потоки, постачальник ідентичності з’єднується з усіма трьома? Ми розгортаємо ту саму функціональність тричі і тримаємо три моделі даних узгодженими? Якщо агентові потрібен глобальний погляд на клієнта, яку org він питає?

Поверніться до ландшафту з модуля 4. Один прямокутник Salesforce стає трьома, і кожну стрілку малюють заново. Кілька org — не помилка. Але вони ніколи не безкоштовні.

Шукайте справжні межі

Що може виправдати ще одну org? Межі, достатньо реальні, щоб формувати архітектуру: резидентність даних, регулювання, юридичне розділення, справді різні операційні моделі, поглинання, яке ще не злилося, регіональне обмеження хостингу, дуже різне врядування, іноді масштаб чи ізоляція. Перелік неповний. Суть — відрізнити «ці групи різні» від «цим групам потрібна архітектурна межа». Друга планка набагато вища.

Географія — не автоматично стратегія org

«Ми працюємо в 30 країнах, тож нам потрібно 30 org». Ні. Географія важлива, коли приносить архітектурну вимогу. Компанія може мати користувачів по всьому світу на одній спільній архітектурі. Тож я не рахую країни; я питаю, що з ними приходить. Де дозволено зберігати дані? Де їх дозволено обробляти? Чи є обмеження на переміщення персональних даних через кордони? Договірні обіцянки щодо резидентності? Чи потрібен регіону інший сервіс чи хост Salesforce? «Є офіс у Німеччині» — само по собі недостатньо.

Хостинг — частина малюнка

Тут сучасна платформа робить ландшафт цікавішим. Hyperforce запускає Salesforce на інфраструктурі публічної хмари в регіонах по всьому світу, даючи клієнтам більше вибору й контролю над тим, де зберігаються їхні дані (Salesforce Hyperforce: General Information and FAQ (opens in a new tab)). Тож коли я підписую прямокутник «Salesforce, Європа», це розташування може мати значення.

Але будьте точними. Вибір того, де живе org, — не обіцянка, що кожен байт кожного сервісу лишається там. Salesforce радить клієнтам переглядати документацію з довіри й відповідності для Hyperforce, зокрема про додаткових субпроцесорів для сервісів, які вони купують (те саме джерело). Тож не кажіть «ми на Hyperforce у країні X, тож усе лишається в країні X». Знайте, якими сервісами справді користуєтеся і яку вимогу задовольняєте. І зверніть увагу, що саме ви обираєте: регіон, а не хмару під ним. Hyperforce працює на AWS, а з кінця 2026 року й на Google Cloud, і Salesforce вирішує, на якому постачальнику стоїть org; клієнт із задокументованою регуляторною причиною уникати одного з них звертається до своєї команди акаунта (те саме джерело).

Не грайте в юриста

Тут архітекторам також треба знати свою роль. Якщо хтось каже: «Європейський закон про приватність вимагає окремої org», я не прийму це наосліп. Я й не призначу себе юристом компанії, щоб оголосити, що не вимагає. Я запитаю: яку конкретну вимогу ми задовольняємо? Де дані зберігаються, де обробляються, транскордонна передача, хто має до них доступ для підтримки, договір, внутрішня політика? Потім я працюю з фахівцями з приватності, безпеки, відповідності та юристами, щоб перетворити цю вимогу на архітектуру. Не вигадуйте юридичних вимог і не ігноруйте їх. Перекладайте їх.

Коли Європа отримує власну org

Ось межа, яку я бачу в реальних сценаріях. Компанія має велику присутність у США і велику присутність у Європі: дві великі клієнтські бази, дві команди продажів і обслуговування і європейську програму приватності, побудовану навколо GDPR. GDPR не каже «вам потрібна окрема org Salesforce». Він встановлює правила для персональних даних, зокрема коли їх можна передавати за межі ЄС (GDPR, Chapter V (opens in a new tab)). Але ця компанія разом зі своїми командами з приватності та юридичних питань вирішує, що персональні дані її європейських клієнтів мають жити в org, розміщеній у Європі, якою керує її європейська команда, за її європейським врядуванням. Це справжня вимога, і вона їхня, а не моя.

Тепер «одна велика глобальна org» — уже не вподобання. На ландшафті є межа, Salesforce AMER і Salesforce EMEA, і я мушу її намалювати. І друга org ніколи не буває просто ще одним прямокутником.

Click to enlarge

Дві org, AMER і EMEA. Бурштинове — те, що додає друга org: не ще один прямокутник, а кожна стрілка наново.

Пройдіть стрілками знову

Коли org більше однієї, пройдіть ландшафтом знову. ERP надсилає продукти в кожну org? Кожна надсилає замовлення назад? Де керуються клієнти і чи можуть їхні дані перетинати регіони? Інтеграційний шар глобальний чи регіональний? Який постачальник ідентичності впускає яких користувачів? Куди йдуть аналітичні дані?

Три місця найшвидше показують ціну:

Звітність. CEO хоче глобальну воронку. В одній org це звіт Salesforce. У трьох — це задача корпоративної звітності: реплікувати, надсилати в сховище даних, федерувати? Наскільки актуальним має бути результат і чи взагалі org однаково визначають «воронку»? Аналітика живе там, де живуть дані, і якщо ви свідомо розділили операційні дані, доведеться спроєктувати, як аналітика збирається знову.

Основні дані. Глобальний клієнт купує у США, Німеччині та Японії. Три org — отже, мабуть, три Accounts. Як знати, що це та сама компанія? Який глобальний ідентифікатор і хто ним володіє? Якщо один регіон змінює адресу, чи має це поширитися? Які атрибути глобальні, а які регіональні? Стратегія org не розв’язує ідентичність; вона змінює задачу ідентичності. Це розділ 6.

Інтеграція. Одна org: Salesforce, інтеграційний шар, ERP. Три org: три з’єднання з інтеграційним шаром, можливо одне з власним хостом і з’єднанням, деякі потоки спільні, деякі регіональні, одні дані можна передавати, інші ні. Навіть мережа може змінитися: якщо підприємству потрібне виділене приватне з’єднання з Hyperforce (на AWS Salesforce радить AWS Direct Connect; той самий FAQ про Hyperforce), кожна org і хост на малюнку — ще одне з’єднання, яке треба планувати. Те, де працює org, може змінити, як до неї дістається решта підприємства.

Одна org чи багато — це рішення, яке ви ухвалюєте зараз, на початку, на ландшафті. Як org потім обмінюються даними (міжорговий Salesforce Connect, інтеграція між ними, Data 360) — це механіка, і її розглядає розділ 14, Одна org чи кілька? (coming soon).

Якщо ви спроєктуєте всю модель даних і інтеграційну архітектуру, а лише потім почуєте «до речі, це мають бути три org», ви зробили не дрібне коригування. Ви змінили архітектуру. Ось чому рішення йде першим.

Не діліть лише для того, щоб прямокутники стали меншими

Велика org здається складною: багато підрозділів, об’єктів, користувачів, інтеграцій. Хтось каже: «А чи не було б чистіше, якби кожен мав власну org?» Малюнок, можливо, стане чистішим. Підприємство — не обов’язково. Ви обміняли внутрішню складність на розподілену: синхронізація, дубльовані дані, ідентичність між org, глобальна звітність, кілька конвеєрів випусків, дубльовані інтеграції й автоматизація і врядування над усім цим. Іноді це все одно правильний обмін. Але окремо — не те саме, що просто.

І одна org теж не безкоштовна. Спільне врядування важливіше, команди можуть впливати одна на одну, межі безпеки потребують ретельного дизайну, модель даних має обслуговувати багато груп, випуски потребують координації, а регіональні правила можуть обмежувати всіх. Тож це не «Steve каже: завжди одна org». Моя початкова схильність — одна org; потім я шукаю вимогу, достатньо сильну, щоб мене від неї зрушити.

Зробіть рішення видимим

Якщо стратегія org важлива, не малюйте узагальнену хмару Salesforce. Намалюйте org і підпишіть їх (AMER, EMEA — що є насправді), зазначте вимогу хостингу чи резидентності за кожною і пройдіть з’єднаннями. Інший архітектор має бачити, чому існує кожна межа. Якщо я не можу пояснити, чому прямокутників Salesforce три, я не завершив рішення.

Steve Trucking працює з однією org у США, і ніщо в його брифі не вимагає іншої. Але тримайте цей модуль у пам’яті для підсумкового проєкту: поглинання, що приходить із власною org, — саме той вид межі, що перевіряє ці запитання.

За межами іспиту: що змінює ШІ. Агент може зробити межу org невидимою для користувача. Під нею архітектура досі має вирішувати, яку org чи систему агент може питати, які дані можуть перетинати регіони і яка відповідь авторитетна. ШІ може сховати складність у досвіді; він не прибирає врядування чи межу.

Що тут вирішує архітектор

• Чи є справжня архітектурна причина для більш ніж однієї org, замість розв’язувати відмінності в межах однієї.
• Де працює кожна org і яка вимога резидентності, регулювання, договору чи бізнесу ставить її туди.
• Які дані можуть перетинати межі org і регіонів, де основні дані авторитетні і як працює глобальна ідентичність.
• Як змінюються інтеграція, ідентичність, аналітика і звітність, коли один прямокутник Salesforce стає кількома.
• Чи варта перевага розділення розподіленої архітектури, яку воно створює.

Читаючи сценарій, я першим шукаю це рішення: одна org чи кілька, де хостинг і що це примусило? Відповідайте на це — і решта ландшафту почне набувати форми.

Додаткові матеріали

• Salesforce Help, Salesforce Hyperforce: General Information, FAQ, Migration Guide, and Security Overview (opens in a new tab) (англійською, перевірено 2026-10-14).
• EUR-Lex, Regulation (EU) 2016/679, the General Data Protection Regulation (opens in a new tab) (Регламент (ЄС) 2016/679, Загальний регламент захисту даних), глава V (передавання персональних даних третім країнам), перевірено 2026-10-14.