Три вопроса, определяющие необходимость использования нескольких организаций Multi-Org
Распространенная ошибка заключается в подходе к вопросу «одна организация или несколько?» как к техническому вопросу о пропускной способности или производительности. В большинстве случаев техническое решение существует в рамках одной организации: типы записей (Record Types), профили (Profiles), наборы разрешений (Permission Sets) и правила совместного доступа (Sharing Rules) достаточны для разделения бизнес-подразделений без фактического разделения среды. Salesforce поддерживает десятки тысяч пользователей и миллионы записей в одной организации — пропускная способность почти никогда не является истинной причиной разделения.
Вопрос, который действительно имеет значение, — это вопрос организационной независимости, и он сводится к трем проверкам:
- Реальная регулятивная независимость — Существует ли юридическое или договорное требование к физическому разделению данных (например, отдельное юридическое лицо с местным регулированием, запрещающим совместное использование инфраструктуры) в отличие от логического разделения, которое может быть достигнуто с помощью модели совместного доступа (Sharing Model).
- Несовместимые темпы изменений — Нуждается ли одно бизнес-подразделение в частых и быстрых циклах выпусков (Release), в то время как другое требует максимальной стабильности и строгого контроля, так что каждый совместный выпуск становится постоянным источником трений между командами.
- Конфликтующая, а не просто отличающаяся модель данных — Когда одна и та же сущность (например, «клиент» или «заказ») имеет обязательное определение поля, поток утверждения или структуру связей, которые физически противоречат друг другу между подразделениями, а не просто отличаются в представлении.
Если ни одно из этих трех условий не выполняется четко, правильное решение — одна организация с логическим разделением. Разделение «на всякий случай» создает постоянные операционные затраты — дублирование управления пользователями, дублирование лицензирования и дублирование поддержки интеграции — за проблему, которую можно было решить с помощью конфигурации.
Матрица решений: одна организация или несколько
| Измерение | Одна организация с логическим разделением | Несколько отдельных организаций |
|---|---|---|
| Стоимость лицензирования и обслуживания | Ниже — единое лицензирование, централизованное управление пользователями | Выше — дублирование лицензирования, дублирование управления выпусками |
| Customer 360 и унифицированное представление | Естественно — все данные в одном пространстве запросов | Требует выделенного слоя BI или интеграции |
| Операционная независимость подразделения | Ограничена — каждый выпуск влияет на всех | Полная — каждое подразделение контролирует свой темп |
| Соблюдение жестких регулятивных требований к разделению данных | Невозможно, если требование — физическое разделение | Единственное решение, соответствующее требованию |
| Сложность интеграции между подразделениями | Низкая | Высокая — требуется промежуточное ПО (Middleware) или ETL |
| Риск при будущем слиянии/разделении | Низкий — только изменение разрешений | Высокий — полноценный проект миграции |
Вывод: по умолчанию следует использовать одну организацию, и разделение следует выбирать только при наличии четкого и положительного ответа на один из трех вопросов выше, а не в качестве реакции на временные организационные разногласия.
Что происходит на практике, когда разделение выполняется без достаточных на то оснований
Когда организация разделяет Org по политическим причинам (подразделение, которое хочет «свой собственный контроль»), а не по реальным техническим причинам, в течение одного-двух лет происходят три вещи: во-первых, создается дублирующаяся запись клиента в каждом Org, где появляется одно и то же бизнес-лицо, без общего ключа идентификации. Во-вторых, любое изменение на уровне организации (такое как обновление процесса безопасности или внедрение нового инструмента) становится отдельным проектом в каждом Org, что удваивает стоимость каждого будущего изменения. В-третьих, корпоративная отчетность требует интеграционного слоя, который изначально не был необходим, и часто он создается в спешке после обнаружения проблемы, а не как часть планирования.
Поэтому один из руководящих принципов архитектуры Salesforce заключается в том, чтобы сначала определить, может ли организационная потребность быть реализована с помощью разрешений и правил совместного доступа (Sharing Rules) в рамках одной организации, и только затем рассматривать разделение.
Пошаговое руководство для тех, кому уже требуется разделение
Когда одна из трех проверок действительно выполняется, разделение должно быть выполнено в порядке, минимизирующем риски:
1. Определите глобальный ключ идентификации до разделения
Перед созданием второй организации установите единое идентификационное поле (идентификационный номер юридического лица, глобальный Customer ID или аналогичный код), которое позволит в будущем сопоставлять записи между средами. Без этого любая будущая попытка объединить представление клиента будет основана на сопоставлении имени и адреса, что приводит к значительным ошибкам.
2. Выберите шаблон интеграции в соответствии с направлением и скоростью передачи данных
Если речь идет только о периодическом обновлении для целей отчетности, достаточно запланированного ETL. Если требуется просмотр в реальном времени (например, для межподразделенческой проверки кредитоспособности), требуется синхронный API с обработкой сбоев и повторных попыток. Выбор неподходящего шаблона является основной причиной того, что кросс-организационные интеграции ломаются под нагрузкой — подробнее об этом в разделе шаблоны интеграции Salesforce.
3. Заранее спланируйте идентификацию и права доступа
Пользователи, работающие в двух организациях (например, глобальные менеджеры по работе с клиентами), требуют решения для идентификации, которое управляется один раз, а не два отдельных пользователя с двумя паролями. Планирование SSO между организациями предотвращает ситуацию, когда каждое изменение прав пользователя выполняется вручную в двух средах — этот вопрос подробно рассматривается в архитектуре SSO и идентификации в Salesforce.
4. Проверьте ограничения API до того, как интеграция будет запущена в производственную среду
Каждый вызов между двумя организациями учитывается в лимитах API обеих сторон. Трафик, запланированный без проверки объема, может нарушить ежедневные лимиты именно в часы пиковой нагрузки, то есть именно тогда, когда интеграция наиболее необходима. Это следует проверить заранее по лимитам API Salesforce.
5. Определите владельца и общий процесс управления обоими организациями
Кто-то должен быть ответственным за согласованность архитектурных решений между средами — структуру полей, правила именования и политику изменений. Без централизованного владения две организации разойдутся даже на уровне стандартов в течение года, что сделает любую будущую интеграцию более дорогой.
Иллюстративный сценарий: страховая группа с двумя подразделениями
Сценарий является гипотетическим и предназначен для иллюстрации. Страховая группа имела подразделение общего страхования и подразделение страхования жизни, оба действовали в рамках одного юридического лица, но с разными регуляторами и совершенно разными циклами утверждения продуктов. Подразделение страхования жизни требовало строгого контроля изменений с регулятивным одобрением каждого выпуска, в то время как подразделение общего страхования хотело выпускать улучшения еженедельно.
Первоначальное предложение заключалось в разделении на отдельные организации для каждого подразделения, но при проверке по трем вопросам выяснилось, что реально существует только регулятивный темп (проверка 2) — модель клиента и продукта не конфликтовали (проверка 3 отрицательная), и не было требования физического разделения данных (проверка 1 отрицательная). Выбранное решение заключалось в одной организации с двумя отдельными «путями выпуска» в одной и той же среде — выделенная песочница (Sandbox) и отдельный процесс утверждения для подразделения страхования жизни, при этом использовалась общая модель данных для единого Customer 360. Полное разделение было предотвращено, как и двойные затраты на обслуживание, которые пришлось бы нести на протяжении многих лет.
Общие риски и способы их предотвращения
- «Временное» разделение, которое остается постоянным — Sandbox, который становится производственной средой без прохождения контроля безопасности. Предотвращается тем, что каждая организация с реальными данными клиентов проходит официальный процесс утверждения управления, без исключений.
- Дублирующиеся записи без общего ключа — Возникает, когда разделение происходит до определения глобального идентификатора. Предотвращается путем определения общего поля как предварительного условия для разделения, а не как позднего этапа.
- Лимит API, который заполняется в часы пик — Происходит, когда интеграция между организациями планируется на основе среднего объема, а не пикового. Предотвращается путем нагрузочного тестирования перед запуском в производственную среду и создания механизма Backoff.
- Расхождение стандартов между организациями — Происходит, когда нет единого владельца общей архитектуры. Предотвращается путем создания небольшого управляющего комитета, который утверждает изменения структуры данных с обеих сторон.
- Ненадежная управленческая отчетность — Происходит, когда попытки рассчитать сквозные KPI организации напрямую из Salesforce без уровня агрегации. Предотвращается путем создания выделенного уровня BI с первого дня разделения, а не в качестве позднего исправительного проекта.
Заключение
По умолчанию используется одна организация; разделение является исключением, требующим конкретного обоснования по одной из трех проверок — реальная регулятивная независимость, несовместимый темп изменений или физически конфликтующая модель данных. Когда обоснование существует, успех перехода измеряется подготовкой, проведенной до разделения: глобальный ключ идентификации, подходящий шаблон интеграции, общая идентификация, проверка лимитов API и четкое владение общими стандартами. Организация, которая пропускает эту подготовку, не экономит работу — она просто откладывает ее на тот момент, когда исправление будет намного дороже.