Перейти к содержимому
HPI Pro — Salesforce consulting and implementation
Язык

Интеграции и миграция данных

Центральная система не может работать одна, и ее данные не должны вызывать недоверия.

Мы подключаем Salesforce к системам, уже используемым организацией, определяем четкие контракты интерфейсов и переносим исторические данные через контролируемый процесс с полной сверкой.

Запланировать интеграцию или миграциюПроверить существующую систему

Топология потока данных

Как данные поступают, управляются и потребляются

Любая стабильная интеграция начинается с определения того, какая система является авторитетом для каждой сущности. Все остальное — протокол, частота и инструменты — вытекает из этого решения.

Топология потока данных

Исходные системы

Откуда поступают данные

  • ERP и финансовые системы
  • Веб-сайт, формы и кампании
  • Контакт-центр и каналы обслуживания
  • Операционные системы

Уровень контракта и контроля

Что регулируется до ввода

  • Контракт интерфейсаполя, формат, ответственность
  • Идентификационный ключ и идемпотентность
  • Валидация и качество данных
  • Повторные попытки, логирование и мониторинг

Salesforce и потребление

Где данные становятся решением

  • Центральная модель данных
  • Автоматизация и процессы
  • Отчеты и информационные панели
  • Agentforce на управляемых данных
Уровень контракта — это то, что отличает стабильную интеграцию от той, которая ломается при каждом изменении в исходной системе.

Типы систем

Что можно подключить

  • ERP
  • Финансовые и бухгалтерские системы
  • Веб-сайты и формы
  • Автоматизация маркетинга
  • Телефония и CTI
  • WhatsApp и каналы обмена сообщениями
  • Системы обслуживания
  • BI и хранилища данных
  • Операционные системы
  • HR-системы
  • Системы документов и электронная подпись
  • Внутренние API
  • Вебхуки

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

Модели интеграции

Выбраны по отказоустойчивости, а не по удобству

Запрос-Ответ

Когда подходит
Немедленный ответ необходим до продолжения процесса
Типичный пример
Проверка запасов или кредита при создании заказа
На что обратить внимание
Прямая зависимость от доступности целевой системы

Fire and Forget

Когда подходит
Обновление важно, но не блокирует процесс
Типичный пример
Отправка обновления статуса в систему отчетности
На что обратить внимание
Требуются повторные попытки и мониторинг

Пакетная синхронизация

Когда подходит
Большой объем, низкая чувствительность к актуальности данных
Типичный пример
Ночная синхронизация каталога или цен
На что обратить внимание
Задержки актуальности между системами

Управляемый событиями

Когда подходит
Несколько потребителей для одного бизнес-события
Типичный пример
Публикация «заказ утвержден» для нескольких систем
На что обратить внимание
Требуется управление схемой и порядком событий

Виртуализация данных

Когда подходит
Визуализация данных без их копирования
Типичный пример
Отображение истории выставления счетов из внешней системы
На что обратить внимание
Производительность зависит от внешнего источника

Миграция данных

Десять контролируемых шагов

01

Картирование источников

Какие системы содержат какие сущности, и каков их авторитет.

02

Профилирование данных

Оценка полноты, дублирования, нерегулярных форматов и отсутствующей истории.

03

Правила очистки

Что исправляется автоматически, что требует бизнес-решения и что не переносится.

04

Сопоставление

Поле за полем, включая преобразования и значения по умолчанию.

05

Идентификационный ключ

Уникальный бизнес-ключ для каждой сущности, чтобы избежать дубликатов при повторных загрузках.

06

Тестовая загрузка

Полная загрузка в тестовую среду с реальными объемами.

07

Валидация

Проверки количества, суммы и выборки по сравнению с источником.

08

Сверка

Формальное сравнение и утвержденный список различий.

09

Окончательная загрузка

Запланированное окно переключения с определенной точкой отката.

10

Постоянный контроль

Метрики качества данных поддерживаются после запуска.

Жизнь после запуска

Интеграция — это система, которой нужно управлять

Операционный цикл интеграций

  1. 01

    Мониторинг

    Измерение успехов, сбоев и времени отклика по каждому интерфейсу.

  2. 02

    Оповещения

    Сбой, превышающий пороговое значение, генерирует оповещение для ответственного за процесс.

  3. 03

    Управление и исправление

    Контролируемая повторная попытка, задокументированное ручное исправление и анализ первопричины.

  4. 04

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

    Обновление контракта интерфейса или бизнес-правила и запись изменения.

↻ Цикл повторяется: каждая итерация определяет приоритеты следующей

Интерфейс без операционного цикла — это интерфейс, который сбоит молча. Этот цикл превращает сбой в управляемое событие, а не в сюрприз.

Продолжить с этого места

Связанные услуги и руководства

Часто задаваемые вопросы

Интеграции и данные — общие вопросы

Когда выбрать интеграцию в реальном времени, а когда — пакетную интеграцию?
Решающий вопрос: что произойдет, если данные придут на час позже? Если это приведет к неверному решению в отношении клиента, то нужна синхронизация в реальном времени. Если последствия - это менее актуальный отчет, то пакетный процесс дешевле, стабильнее и проще в поддержке. Распространенная комбинация — реальное время для ключевых сущностей и пакетный режим для обогащения и исправлений.
Что такое контракт интерфейса и почему он критичен?
Контракт интерфейса письменно определяет, какая система является источником, какие поля передаются, в каком формате, что происходит при сбое, что однозначно идентифицирует запись и кто отвечает за изменения. Без него любое обновление с одной стороны нарушает работу другой, и никто не знает почему. Это документ, который предотвращает большинство реальных сбоев интеграции.
Как избежать дубликатов при миграции?
Определите ключ бизнес-идентификации для каждой сущности перед загрузкой данных, проведите профилирование данных, чтобы узнать реальный масштаб дублирования, примите явное правило слияния и выполните тестовую загрузку в тестовой среде. Только после полного согласования выполняется окончательная загрузка.
Что делать, если исходная система ненадежна?
Не скрывайте проблему за интеграцией. Определите диапазон приемлемого качества, отфильтруйте или пометьте записи, выходящие за его пределы, и определите процесс исправления в источнике. Передача некачественных данных в Salesforce лишь переносит недоверие к новой системе.
Сколько времени занимает миграция данных?
Продолжительность зависит от качества источника, а не от объема. Миллион чистых записей с четким ключом намного быстрее, чем сто тысяч записей с дубликатами и частичной историей. Поэтому профилирование проводится на ранней стадии, прежде чем будет установлен какой-либо срок.
Нужна ли отдельная интеграционная платформа?
Не всегда. Для нескольких стабильных интерфейсов достаточно использовать подход, основанный на API и событиях платформы. Отдельная платформа оправдана, когда имеется множество систем, сложные преобразования, требования к централизованному мониторингу или необходимость повторного использования логики между процессами.

Следующий шаг

Запланируйте интеграцию или миграцию

Мы отобразим системы, источники правды и необходимый уровень качества, а также разработаем план, который действительно можно реализовать.

Запланировать интеграцию или миграциюАрхитектура CRM