Бизнес Юниты

Как организовать архитектуру Marketing Cloud для международной компании
Salesforce Org – жильё для ваших бизнес процессов
Перед тем как перейти к архитектуре конкретного Marketing Cloud, рассмотрим вкратце принципы организации облачных сервисов Salesforce и связанную с этим терминологию.
Облачные сервисы Salesforce работают по принципу многоэтажек с квартирами разного размера с интерьером или без.

В такой аналогии:
  • здание - это дата центр или стек. Как правило, стек прямо указывается в ссылке вида eu16.salesforce.com (дата центр №16, расположенный в регионе EMEA)
  • квартиры в нём арендованные - предоставленное по подписке пространство для хранения данных и выполнения логики. Это называется Organization, Org, инстанс или попросту орга. В Marketing Cloud орга имеет своё название - бизнес юнит (BU, Business Unit)
  • интерьер - готовые инструменты для работы по Sales или Service процессам в дружелюбном интерфейсе. Можно "снять квартиру" и без "интерьера". В этом случае в том же удобном интерфейсе можно настроить свои собственные уникальные процессы
Сразу очертим различия в иерархии организаций в конвенциональных облаках Salesforce вроде Sales/Service и в Marketing Cloud. Далее для простоты буду называть Sales/Service облака зонтичным жаргонным термином "форс"

Итак, в форсе нет как таковой иерархии инстансов. Единственное подобие - связка продуктивной среды и тестовых сред. То есть условная международная компания должна решить, будут ли процессы всех стран работать в одной мультиязычной сложносочинённой орге или каждая страна или группы стран будут оперировать своими независимыми инстансами. В Marketing Cloud, напротив, бизнес юниты могут быть организованы иерархически: BU головного офиса > BU стран > BU независимых команд маркетологов по крупным направлениям
Дальше всё зависит от уровня независимости команд компании в разных странах и особенностей контрактования. Я собрал руководство по определению архитектуры в виде дерева решений:
Уровень локализации
Если ваша компания локализована в одной стране, то ваш выбор - связка один форс + один BU MC. Если компания интернациональная, переходим к оценке независимости подразделений в разных странах.
Уровень (не)зависимости от HQ
Если вы планируете запускать кампании в разных странах, важно учитывать степень свободы команд в этих странах.

Когда имя бренда в реальности единственный объединяющий фактор, стоит рассмотреть независимое контрактование тех же связок один форс + один BU по каждой стране.

Если же команды действительно связаны не только общим названием, но и общей инфраструктурой, стоит внимательнее посмотреть на источники данных
Варианты коннекта Sales/Service с иерархическими BU Marketing Cloud с помощью нативных инструментов Salesforce:
Источник или источники
Как правило, у каждой страны свой зоопарк систем. Эти системы уже делают много сложной взаимосвязанной работы, и логично каждой команде в процессе роста мигрировать процессы в свой собственный Sales/Service Cloud инстанс. Если HQ хочет помочь в этом, головной офис может закупить Marketing Cloud в конфигурации Головной BU + россыпь BU для стран, чтобы каждая страна связывала свой Sales/Service со своим же BU MC.

Попытка загнать всех под одну крышу ради скидки за количество подписок или ради эфемерной отчётности в большинстве случаев заканчивается увеличением длительности разработки, увеличением стоимости поддержки и повышением рисков падения процессов. Будет потрачено очень много времени, денег и нервов на неизменно безуспешные попытки развести потоки данных и спасти процессы, страдающие от каждого второго (первого) релиза команды из другой страны.

Возможно два оправдания попыткам засунуть процессы всех стран, с которыми вы работаете, в один общий Sales/Service Cloud:
- во всех странах идентичные процессы
- внедрением занимается одна команда на все страны

Заключение
Тема организации архитектуры бизнес юнитов Marketing Cloud и инстансов Sales/Service едва ли не главная в начале любого внедрения. Именно поэтому я решил так подробно остановиться на описании вариантов решения. Информированное решение в самом начале может сэкономить многие сотни часов работы по поддержанию неэффективной структуры. Ниже вы видите полное дерево решений. Понятно, что всегда есть исключения или исторически сложившиеся экосистемы, которые не позволяют следовать best practice, но это не повод не стремиться к лучшему.