Краткий ответ
«Единый источник истины» — это не технический вопрос, а вопрос полномочий: кто в организации имеет право определять правильность определённого значения. Если такое решение не принимается явно, оно принимается тайно — тем, кто написал последнюю интеграцию.
Ключевое правило: право собственности определяется на уровне поля, а не на уровне системы. Попытки объявить «ERP является источником истины для клиента» терпят крах, как только отдел обслуживания обновляет номер телефона в Salesforce, а ночная синхронизация удаляет это обновление.
Три вопроса, определяющие право собственности
Для каждой сущности, а затем для каждой группы полей следует задать вопросы: где данные были первоначально созданы, кто уполномочен в бизнес-процессе изменять их, и кто несёт ответственность в случае их некорректности. Во всех трёх случаях ответом должна быть должность, а не название системы. Система определяется должностью.
Если ответы указывают на две разные должности, это почти всегда признак того, что два разных поля были объединены в одно.
Пример матрицы прав собственности
| Сущность / Поле | Источник истины | Salesforce | Направление синхронизации |
|---|---|---|---|
| Юридическое название, ИНН, условия оплаты | ERP | Только для чтения | ERP → Salesforce |
| Контактное лицо, должность, предпочтения | Salesforce | Редактирование | Salesforce → Маркетинговые системы |
| Каталог продукции и базовый прайс-лист | ERP / PIM | Только для чтения | ERP → Salesforce |
| Коммерческое предложение и утверждённая скидка | Salesforce | Редактирование | Salesforce → ERP |
| Подтверждённый заказ и статус доставки | ERP | Только для чтения | ERP → Salesforce |
| Задолженность и статус взыскания | Финансовая система | Только для чтения | Финансовая система → Salesforce |
| Активность, обращения и коммуникации | Salesforce | Редактирование | Без внешней синхронизации |
Эта таблица является результатом. Она компактна, содержится в одном документе, и каждая новая интеграция проверяется по ней до начала разработки.
Разделение между представлением и полномочиями
Большинство конфликтов между системами устраняются, когда становится понятно, что представление данных не требует их копирования. Остаток задолженности, отображаемый продавцу, не обязательно должен быть полем в Salesforce, которое обновляется каждую ночь; это может быть удалённое представление или слой федерации.
Каждое скопированное поле — это операционное обязательство: синхронизация, сбой, расхождение и время. Прежде чем копировать, следует задаться вопросом, требуется ли автоматизация или историческая отчётность. Если нет — предпочтительнее отображать, а не копировать. Более подробное описание этого подхода представлено в статье «Zero Copy и федерация в Data 360».
Конфликты: принятие решений заранее, а не в реальном времени
Даже при наличии чёткого определения прав собственности возникают ситуации одновременного обновления. Возможны три правила: приоритет системы (владелец всегда выигрывает), последняя временная метка или пометка для ручной обработки. Третье правило является наиболее безопасным для конфиденциальных полей — при условии, что существует очередь обработки с назначенным ответственным, а не просто запись в журнале, которая накапливается.
Сценарий: организация с двумя истинами для одного адреса
Компания, оказывающая услуги инфраструктуры, управляла адресом клиента в двух системах: ERP для выставления счетов и системой выездного обслуживания для координации работы технических специалистов. Обе системы синхронизировались с Salesforce двунаправленно. Результат: адрес постоянно менялся туда-обратно, а технические специалисты прибывали по адресу для выставления счетов.
Решение заключалось не в исправлении синхронизации, а в декомпозиции сущности. Были определены два отдельных поля — адрес для выставления счетов, принадлежащий ERP, и адрес обслуживания, принадлежащий системе выездного обслуживания. Оба поля были только для чтения в Salesforce, со ссылкой на запрос на изменение, направляемый соответствующему владельцу. Количество сервисных обращений, закрытых как «неверный адрес», значительно снизилось в течение следующего квартала.
Урок: когда системы «борются» за поле, часто речь идёт о двух разных бизнес-данных, которым присвоено одно и то же имя.
Обеспечение: от документа к реальности
Матрица прав собственности работает только в том случае, если она реализована в трёх ключевых точках: Field-Level Security, которая предотвращает редактирование на стороне, не являющейся владельцем; интеграционный пользователь с ограниченными разрешениями только к полям, находящимся в его владении; и ежемесячный отчёт, показывающий поля, которые были обновлены в нарушение политики. Последний отчёт выявляет давно существующие интеграции, о которых никто не помнит.
Документирование значения каждого поля напрямую связано с картой данных для миграции.
Распространённые риски и профилактические меры
| Риск | Как проявляется на практике | Превентивная мера |
|---|---|---|
| Право собственности на уровне системы | Противоречия внутри одной и той же сущности | Принятие решения на уровне поля или группы полей |
| Двусторонняя синхронизация по умолчанию | Значения, периодически изменяющиеся | Одностороннее направление + режим чтения на другой стороне |
| Избыточное копирование | Десятки синхронизированных полей без потребителя | Отображать вместо копирования |
| Документ без обеспечения | Политика размывается в течение нескольких месяцев | Разрешения на уровне поля + мониторинг отклонений |
| Отсутствие очереди конфликтов | Противоречия накапливаются незаметно | Очередь обработки с назначенным ответственным и SLA |
Как измерить успех
| Область | Что измеряется | Частота проверки |
|---|---|---|
| Согласованность | Доля несоответствий в ключевых полях между системами | Ежемесячно |
| Отклонения от политики | Записи в полях, сделанные вне определённого владельца | Ежемесячно |
| Конфликты | Количество и время закрытия элементов в очереди | Еженедельно |
| Операционное воздействие | Сбои, вызванные некорректными данными | Ежеквартально |
Разработка и обеспечение выполнения матрицы прав собственности осуществляется в рамках услуг по интеграции и работе с данными.
Чек-лист для определения «единого источника истины»
- ☐ Список центральных сущностей в организации
- ☐ Для каждой сущности: где создана, кто уполномочен, кто отвечает за ошибку
- ☐ Право собственности определено на уровне поля или группы полей
- ☐ Явное направление синхронизации для каждой группы
- ☐ Каждое копируемое поле проходит проверку «имеет потребителя»
- ☐ Выбрано и задокументировано правило разрешения конфликтов
- ☐ Существует очередь ручной обработки с назначенным ответственным и SLA
- ☐ Field-Level Security соответствует матрице
- ☐ Интеграционный пользователь ограничен полями, находящимися в его владении
- ☐ Ежемесячный отчёт по отклонениям от политики
Профессиональные ресурсы
- Salesforce Data 360 — https://www.salesforce.com/data/
- Архитектура Salesforce Data 360 — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html
- HPI Pro – Интеграции и данные — https://hpi.pro/integrations-data