Краткий ответ
Картирование данных — это не просто таблица соответствия полей, а документ, в котором организация определяет значение каждого фрагмента данных, переносимого в Salesforce. Практически любая ошибка загрузки, кажущаяся технической — неверный формат даты, неопознанное значение Picklist, разорванная связь — изначально является следствием непринятого бизнес-решения.
Порядок действий: сначала определяется, какие сущности будут переноситься, затем, кто является бизнес-владельцем каждой сущности, далее, какие поля имеют реального потребителя, и только потом пишутся правила преобразования. Если начать с обратного, техническая команда принимает бизнес-решения незаметно — и это обнаруживается спустя три месяца после Go-Live, когда отчет о доходах не сходится.
Общая информация о планировании миграции данных доступна по ссылке: Миграция данных в Salesforce.
Три типа пробелов, выявляемых при картировании
| Тип пробела | Распространенный пример | Кто принимает решение |
|---|---|---|
| Семантический пробел | «Активный клиент» = совершил покупку в этом году в одной системе, = не заблокирован в другой системе | Владелец бизнес-процесса |
| Структурный пробел | Один клиент с пятью адресами против модели Account/Contact | Архитектор данных |
| Пробел в качестве | 18% записей без действительного внутреннего номера НДС | Владелец данных + регулирующие органы |
Семантический пробел является наиболее дорогостоящим, поскольку он не выявляется при загрузке. Данные успешно поступают, автоматизация выполняется на их основе, а отчет показывает неверное, но правдоподобное число. Структурные пробелы выявляются при загрузке и обнаруживаются рано. Пробелы в качестве выявляются, если — и только если — заранее были определены пороговые значения приемлемости.
Семантический уровень: Data Dictionary до Mapping-таблицы
Перед тем как сопоставлять поля, составляется глоссарий для каждой ключевой сущности: что такое Account (клиент), чем Lead (потенциальный клиент) отличается от Contact (контакта) в данной организации, когда Opportunity (возможность) закрывается. Эти определения коротки — две строки на сущность — но именно они позволяют разрешать разногласия, а не указывать на них.
Простая проверка: дайте трем сотрудникам из трех разных отделов определить «клиента» по отдельности. Если определения различаются, миграция передаст три разные истины в одну и ту же таблицу.
Анатомия правильной строки картирования
Каждая строка в таблице должна отвечать на семь вопросов: из какого исходного объекта и поля, в какой объект и поле в Salesforce, каков тип данных и его длина, каково правило преобразования, что происходит с пустым значением, каково значение по умолчанию и кто утвердил. Строка, в которой отсутствует один из этих столбцов, вернется в качестве вопроса в процессе ночной загрузки Cutover.
Три рабочих правила, которые помогают избежать ошибок:
- Нет тихих преобразований. Все значения, которые система «исправляет» самостоятельно, должны быть записаны в лог исключений.
- Значение по умолчанию — это бизнес-решение. Тот, кто устанавливает
Country = ILв качестве значения по умолчанию, должен нести ответственность за отчеты по регионам. - Внешние ключи превыше всего. Для каждой сущности сохраняется External ID из исходной системы. Без него нет Reconciliation и повторного запуска.
Преобразования: где совершаются ошибки
Наибольший ущерб наносят именно простые преобразования. Даты без часового пояса смещают записи на день; имена, которые обрезаются и переводятся в верхний регистр без единого правила, создают новые дубликаты сразу после удаления старых; суммы, конвертированные в единую валюту по дневному курсу, создают расхождения в отчетах с ERP.
Правило: любое числовое или денежное преобразование проверяется путем сравнения сумм, а не путем сравнения записей. Одинаковый подсчет не является доказательством корректности.
Те, кто еще не решил вопрос об источнике истины, найдут информацию в Source of Truth в организации, а само окно переноса — в Cutover и Reconciliation в Salesforce.
Сценарий: Сервисная компания с двумя исходными системами
Организация, предоставляющая услуги, с 90 тысячами клиентов приступила к миграции из двух систем: старой системы выставления счетов и системы обслуживания, приобретенной вместе с дочерней компанией. Первая таблица картирования была отмечена как «готова» в течение двух недель — 340 полей было сопоставлено.
При первом тестовом прогоне (Rehearsal) было загружено 97% записей. Проблема обнаружилась при сверке (Reconciliation): общая сумма остатков в Salesforce была на 4,1% ниже, чем в ERP. Причиной была не неудачная загрузка, а то, что все записи с отрицательным остатком (кредитовые ноты) были сопоставлены с полем, имеющим правило валидации, которое предотвращало отрицательное значение — и тихо устанавливались как ноль.
Исправление было на двух уровнях: явное правило преобразования для кредитовых нот, а также изменение политики — каждое правило, которое обнуляет или укорачивает значение, должно генерировать строку исключения. При втором прогоне количество исключений увеличилось до 1900, и это был прогресс: исключения стали видимыми вместо скрытых. Третий прогон свел количество исключений к 40 задокументированным, и только тогда была назначена дата Cutover.
Распространенные риски и профилактические меры
| Риск | Как проявляется на практике | Профилактические меры |
|---|---|---|
| Перенос всей истории | Объем, дубликаты и бесполезная информация переносятся в новую систему | Определить политики Retention и пороговые значения качества |
| Только техническое картирование | Поля переносятся без понимания бизнес-значения | Data Dictionary и бизнес-владельцы |
| Тихие преобразования | Значения исправляются автоматически, и никто об этом не знает | Логирование исключений обязательно для каждого правила преобразования |
| Отсутствие тестовых прогонов (Rehearsal) | Окно простоя увеличивается, возникают сюрпризы | Минимум два полных тестовых прогона |
| Отсутствие External ID | Невозможно проверить, исправить или повторно запустить | Для каждой сущности сохраняется исходный ключ |
Как измерять успех
| Область | Что измеряем | Частота проверки |
|---|---|---|
| Полнота (Completeness) | Доля заполненных обязательных полей в целевой системе | До и после каждой загрузки |
| Сверка (Reconciliation) | Соответствие подсчетов, сумм и связей исходным данным | При каждом тестовом прогоне (Rehearsal) и Cutover |
| Исключения | Количество открытых строк исключений по степени серьезности | Ежедневно в период миграции |
| Поля без потребителя | Сколько перенесенных полей не использовались за 90 дней | Один раз после Go Live |
Последний показатель является подготовкой к следующему циклу: он показывает, сколько работы было излишним, и определяет объем следующей миграции.
Организации, предпочитающие профессиональное сопровождение в построении картирования, делают это в рамках услуги интеграции и данных.
Контрольный список перед первой загрузкой
- ☐ Краткий словарь терминов для каждой ключевой сущности, утвержденный бизнесом
- ☐ Список полей с определенным потребителем; остальное в архив
- ☐ External ID для каждой перенесенной сущности
- ☐ Полная таблица сопоставления значений (Value Mapping), включая значение для неопознанных значений
- ☐ Явное правило для каждого пустого значения и для каждого значения по умолчанию
- ☐ Каждое правило преобразования генерирует строку исключения вместо тихого исправления
- ☐ Сценарий сверки (Reconciliation): подсчет, сумма, связь, ручная выборка
- ☐ Согласованный порог исключений, выше которого Cutover не выполняется
- ☐ Версия и подпись на листе картирования
- ☐ План отката (Rollback) и повторного запуска
Профессиональные ресурсы
- 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