Краткий ответ
Выбор между CRM и Data 360 определяется не «тем, где есть место», а «тем, кто и с какой частотой потребляет данные». Система CRM строится вокруг записи, которую кто-либо открывает, редактирует и продвигает в рамках процесса. Data 360 строится вокруг потока событий, который объединяется в профиль и используется для сегментации, анализа и выполнения действий.
Смешение этих двух подходов приводит к одному из двух результатов: либо к громоздкой CRM с миллионами записей, к которым никто не прикасается, либо к богатому слою данных, по которому никто не действует, потому что он не интегрирован в рабочие процессы.
Практическое разделение
| Тип информации | Место хранения | Обоснование |
|---|---|---|
| Клиент, контакт, возможность, обращение | CRM | Управляется вручную, запускает процессы и разрешения |
| Этап продажи, задачи, утверждения | CRM | Автоматизация и ежедневные операции |
| Клики, просмотры, использование продукта | Data 360 | Высокий объем, не управляется вручную |
| История транзакций из ERP | Data 360 (или виртуальный доступ) | Объём и внешний источник достоверных данных |
| Единый профиль и сквозная идентификация систем | Data 360 | Функция объединения идентификаторов |
| Оценка, сегментация, рекомендация | Рассчитывается в Data 360, отображается в CRM | Расчёт больших объемов, использование в рабочих процессах |
Ключевой принцип заключается в следующем: расчёты выполняются там, где есть большой объём данных, а отображение — там, где принимаются решения.
Тест четырёх вопросов
Прежде чем вводить данные в CRM, задайте себе следующие вопросы: Редактирует ли кто-то эти данные вручную? Зависят ли от них автоматизация или валидация? Требуются ли они в текущем операционном отчете? Влияют ли они на разрешения или владение? Если ответ на все четыре вопроса отрицательный, данные почти всегда относятся к слою унификации.
Обратное тоже верно: данные, которые хранятся только в Data 360, но необходимы для принятия решений в реальном времени, должны иметь механизм обратной связи — сводное поле, представление или действие — иначе они не повлияют на бизнес-результат.
Объем, производительность и стоимость
CRM ценообразование и проектирование основаны на бизнес-записях. Введение поведенческих событий в систему меняет профиль нагрузки: массовые обновления замедляются, создание отчетов становится ресурсоёмким, а резервное копирование и тестовые среды увеличиваются в размере. Data 360 спроектирован для такой скорости и тарифицируется по потреблению — что требует иного подхода: широкие запросы и избыточные потоки данных порождают постоянные затраты.
В обоих случаях гигиена данных одинакова: передавать только то, что имеет потребителя, и определить политику хранения (Retention) для каждого потока. Подробное обсуждение копирования против удалённого доступа приведено в статье Zero Copy и Federation.
Разрешения: легко упустить из виду
Модель разрешений в CRM является богатой и точной на уровне записей и полей. Слой унификации работает иначе — он предназначен для анализа, и его доступность регулируется правилами доступа и масками. Организация, которая передаёт конфиденциальные данные в слой унификации без предварительного планирования, может создать более широкую область видимости, чем в CRM.
Правило: каждый поток, содержащий конфиденциальную информацию, получает явное решение о допустимости раскрытия до его передачи, а не после.
Сценарий: розничный продавец, который перенёс всё в CRM
Розничная сеть перенесла трёхлетнюю историю покупок (около 40 миллионов строк) в настраиваемый объект CRM с целью обеспечить «продавцу полную картину». В результате: длительное время загрузки на экране клиента, ночные обновления, выходящие за рамки отведённого окна, и отчёты, которые завершались с ошибкой из-за превышения времени ожидания.
При перестройке в CRM остались только четыре производных значения: дата последней покупки, сумма за 12 месяцев, ведущая категория и отметка о риске оттока. Вся полная история была перемещена в слой унификации с возможностью запроса подробного просмотра по требованию.
Экран клиента загружался быстро, продавцы получали именно ту информацию, которую они запрашивали, а маркетинговая сегментация улучшилась — потому что она основывалась на данных, которые находились в одном месте, а не только на тех, которые удалось поместить в CRM.
Типичные риски и профилактические меры
| Риск | Как это проявляется на практике | Профилактические действия |
|---|---|---|
| Всё в CRM | Производительность, стоимость и время загрузки | Производные значения вместо необработанной истории |
| Всё в слое унификации | Insights, не достигающие рабочего процесса | Механизм обратной связи: поле, представление или действие |
| Отсутствие Retention | Неконтролируемый рост объёма данных | Политика хранения для каждого потока |
| Неспланированные разрешения | Раскрытие конфиденциальных данных при анализе | Решение о допустимости раскрытия до передачи данных |
| Необъединённая идентификация | Разделённый профиль для одного клиента | Определённые правила Identity Resolution |
Как измерить успех
| Область | Что измеряется | Частота проверки |
|---|---|---|
| Производительность | Время загрузки экрана клиента и массовых обновлений | Ежемесячно |
| Унификация | Процент успешно объединённых профилей | Ежемесячно |
| Активация | Фактически созданные сегментации и действия на основе данных | Ежеквартально |
| Стоимость | Потребление в сравнении с бюджетом по потокам | Ежемесячно |
Планирование разделения между CRM и слоем унификации осуществляется в рамках сервиса интеграции и данных.
Чек-лист для принятия решения
- ☐ Картирование потоков данных по объему и частоте обновления
- ☐ Тест четырёх вопросов для каждого потока
- ☐ Определены производные значения для отображения в CRM
- ☐ Существует механизм обратной связи из слоя унификации в рабочий процесс
- ☐ Написаны правила Identity Resolution
- ☐ Решение о допустимости раскрытия для каждого потока с конфиденциальной информацией
- ☐ Политика Retention для каждого потока
- ☐ Оценка стоимости потребления для первого этапа
- ☐ Выбран один сценарий использования для демонстрации ценности
- ☐ Назначен владелец для каждого потока данных
Профессиональные источники
- Salesforce Data 360 — https://www.salesforce.com/data/
- Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html
- HPI Pro — Интеграции и данные — https://hpi.pro/integrations-data
