Краткий ответ

Выбор между CRM и Data 360 определяется не «тем, где есть место», а «тем, кто и с какой частотой потребляет данные». Система CRM строится вокруг записи, которую кто-либо открывает, редактирует и продвигает в рамках процесса. Data 360 строится вокруг потока событий, который объединяется в профиль и используется для сегментации, анализа и выполнения действий.

Смешение этих двух подходов приводит к одному из двух результатов: либо к громоздкой CRM с миллионами записей, к которым никто не прикасается, либо к богатому слою данных, по которому никто не действует, потому что он не интегрирован в рабочие процессы.

Практическое разделение

Тип информацииМесто храненияОбоснование
Клиент, контакт, возможность, обращениеCRMУправляется вручную, запускает процессы и разрешения
Этап продажи, задачи, утвержденияCRMАвтоматизация и ежедневные операции
Клики, просмотры, использование продуктаData 360Высокий объем, не управляется вручную
История транзакций из ERPData 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 для каждого потока
  • ☐ Оценка стоимости потребления для первого этапа
  • ☐ Выбран один сценарий использования для демонстрации ценности
  • ☐ Назначен владелец для каждого потока данных

Профессиональные источники