Что мигрировали?

Задача: в рамках проекта, длившегося год, наша консалтинговая компания внедряла с нуля системы SAP Sales Cloud, SAP CPQ и SAP Comissions. На позднем этапе проекта нам нужно было мигрировать большой объем исторических данных из старой CRM-системы заказчика (Oracle Siebel) и баз данных российских организаций ЕГРЮЛ и ЕГРИП в SAP Sales Cloud.

В чем сложность: мигрировать нужно было около 33,6 миллионов записей, в том числе данные клиентов, контактных лиц, контрактов, кастомных объектов и другое.

Сроки по плану: 1 месяц. Планировали за это время осуществить миграцию вместе с предварительным согласованием процедуры со службой безопасности.

Сроки по факту: 4 месяца. Возникло большое количество непредвиденных обстоятельств, из-за которых было множество эскалаций, переработок, сдвиг срока Go-live на 2 месяца и прочих проблем.

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

Подготовка к миграции

Мы начали подготовку процессу миграции данных за 1,5 месяца до планируемой даты Go-live (не считая работ по согласованию атрибутов объектов) — оказалось, слишком поздно. Так что начинать подготовку лучше заранее, особенно если у заказчика строгая служба безопасности.

Вот список того, о чем я рекомендую позаботиться во время подготовки к миграции:

1. Согласовать с заказчиком формат проведения миграции.
2. Определить набор атрибутов для загружаемых объектов.
3. Решить, использовать ли «промежуточную» базу данных.
4. Выбрать способ загрузки данных в SAP Sales Cloud.
5. Решить, нужны ли валидаторы для автоматизированной проверки данных.
6. Подготовить шаблоны для загрузки.
7. Настроить диапазоны номеров для объектов в SAP SC.
8. Настроить отображение ФИО контактных лиц и сотрудников.

Разберем каждый пункт.

1. Согласовать с заказчиком формат проведения миграции данных

Начать тему миграции можно с проведения установочной встречи с заказчиком. На ней кратко рассказать, как можно мигрировать данные в SAP Sales Cloud, и спросить:

• Какие именно объекты нужно мигрировать?
• Какое примерное количество записей по каждому объекту?
• Кто со стороны заказчика будет заниматься этой задачей?
• Сколько времени потребуется заказчику для подготовки файлов с данными?
• От каких подразделений заказчика потребуется согласование факта предоставления данных стороне исполнителя? Например, нужно ли разрешение от службы безопасности заказчика (у нас на проекте согласование со службой безопасности способа миграции заняло примерно 3 недели).
• Нужна ли будет миграция «дельты» по данным? Изменения по каким именно объектам она должна включать в себя?

А также обозначить, что миграция – это важный процесс, к нему нужно отнестись ответственно и заранее спланировать выделение ресурсов.

Затем нужно выбрать формат миграции. У нас были возможны следующие пути миграции:

1. Предоставление данных заказчиком в виде файлов (.xls или .csv) и загрузка этих файлов в SAP Sales Cloud через Data Workbench.
2. Подключение напрямую к базе данных старой CRM-системы заказчика (Oracle Siebel) и загрузка данных с помощью веб- или Odata-сервисов в SAP Sales Cloud.
3. Автоматический сбор мигрируемых данных на стороне Siebel, автоматическое формирование и загрузка файлов с этими данными на FTP-сервер. На стороне SAP Sales Cloud/SAP CPI предполагалось писать скрипт для автоматического парсинга этих файлов и загрузки данных из этих файлов в SAP Sales Cloud.

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

Далее нужно согласовать с заказчиком основные положения и организацию процесса миграции. Для этого я готовил письмо заказчику с предложениями по следующим пунктам:

1. Список объектов, которые нужно мигрировать, в представлении системы SAP Sales Cloud. Заказчик может не догадываться о том, что для миграции данных по сотрудникам нужно загружать несколько разных csv-файлов или заполнять несколько листов с разными полями в xlsx-файле (организационное присвоение сотрудников, полномочия и т.д.).
2. Порядок загрузки объектов. Например, сначала нужно загрузить основные данные сотрудников, потом их орг. единицы и полномочия, только потом данные клиентов (так как в них нужно указать ответственных сотрудников), затем контракты (с указанием клиента, ответственных сотрудников) и т.д. Заказчику нужно понимать, в каком порядке и с каким приоритетом готовить выгрузку данных из БД.
3. Конкретные связи между загружаемыми данными. Нужно понимать, какие объекты ссылаются на другие объекты и продумать маппинг между ними.

Например, в файле по основным данным контрактов нужно указать ответственного сотрудника и клиента. Изначально известны только ID этих записей из БД Siebel, а для того, чтобы загрузка данных прошла корректно, нужно правильно проставить ID для SAP Sales Cloud.

Для этого определенная сторона должна:

• заранее проставить на записях сотрудников и клиентов в файлах ID для SAP Sales Cloud;
•  смаппить этот идентификатор с их ID Siebel;
•  правильно проставить эти ID для SAP Sales Cloud в конечном файле для загрузки контракта.

На нашем проекте такими операциями занимались специалисты BW.

4. Диапазоны номеров для объектов SAP Sales Cloud — если заказчик сам будет проставлять ID для SAP Sales Cloud.
5. Формат предоставляемых файлов с данными: .csv или .xlsx, а также формат кодирования файлов (для .csv – это UTF-8) и формат разделителей для полей в .csv файлах (для загрузки в DWB разделители должны быть ""). Советую отдельно обратить внимание заказчика на то, что формат файла, набор полей в нем и регистр их названий не должны меняться на протяжении всей миграции.
6. Способ обмена файлами с данными. Так как скорее всего мигрируемые данные являются коммерческой тайной, следует относиться к ним внимательно, не допускать к ним третьих лиц, не выкладывать в открытые источники и т.д. Мы использовали NextCloud заказчика, файлы запаковывали в архив с паролем, который был разным для каждого архива. После скачивания я должен был удалить архив из хранилища. Также лучше изначально прописать правила наименования архивов и файлов, чтобы всё было в едином формате.
7. Ограничения.
   • Какие объекты не мигрируются (в данный момент или вообще).
   • Какая сторона (заказчик или исполнитель) будет осуществлять подготовку данных для загрузки.
   • Какая сторона будет загружать данные в систему SAP Sales Cloud.
   • Кто будет подготавливать файлы для загрузки, и предполагаются ли в этих файлах комментарии по заполнению полей.
   • Если требуется прописывать ID объектов для SAP Sales Cloud, то какая сторона это будет делать (и для чего именно) и т.д.
8. План действий с датами по каждому объекту. Например, 19 мая заказчик предоставляет выгрузку по объекту «Контракт», 20 мая исполнитель загружает данные по объекту «Контракт» в SAP Sales Cloud при отсутствии замечаний по выгрузке.

2. Определить набор атрибутов для объектов

Очевидно, что перед миграцией данных нужно понимать, какие именно поля загружать в систему. Начинать выяснять и согласовывать с заказчиком набор полей для объектов (и для их поиска) на проекте нужно как можно раньше.

Ниже приведу несколько проблемных моментов по этой теме, с которыми я столкнулся на проекте.

Ведение внешних ID для объектов SAP Sales Cloud

Практически всегда при наличии интеграционных сценариев на объектах SAP Sales Cloud нужно хранить ID из внешних систем. В стандарте SAP Sales Cloud предполагается записывать ID из внешних систем для объектов (например, ID контракта в Siebel) в специальном поле «Внешний ид.» (External ID). Какие есть плюсы и минусы использования данного поля:

1. Поле нельзя изменять вручную в карточках объектов в интерфейсе.
2. В меню «Администратор» есть специальный пункт «Мэппинг ид. для интеграции», где можно изменять External ID, но только для основных данных (вручную или через Add-In для MS Excel (до 10 тыс. записей за одну