Десять лет кадровых данных, клиентов, автомобилей и истории сервиса российской сети автосалонов переехали из PeopleSoft и Siebel в новую учётную систему и новую CRM. Перенос данных выполнил Евгений Росляков: сайтами и бизнес-системами он занимается с 2016 года, оформлен как самозанятый, перед стартом подписывает договор, а юрлицам отдаёт закрывающие документы. Принимает заказы в Москве и удалённо.
Компания много лет жила на продуктах Oracle. Кадры и зарплата лежали в PeopleSoft. Клиенты, машины и заказ-наряды сервиса — в Siebel CRM. Склад, учёт и обе системы связывала шина на Oracle Fusion Middleware, собранная на SOA Suite.
Поддержка и лицензии Oracle для российской компании стали недоступны. Обновлений нет, а людей, которые помнят устройство шины, в штате не осталось. Решили уходить на российскую учётную систему и собственную CRM.
Формулировка у задачи короткая: ничего не потерять. Все сотрудники с их историей, все клиенты, все автомобили с VIN, все визиты в сервис. И понять, что станет с потоками данных между системами, когда шину выключат.
Ещё в базах накопились дубли. Один клиент мог числиться три раза, а машина — под двумя написаниями VIN. Переносить всё как есть значило подарить новой системе тот же беспорядок.
Начал с чтения баз. По JDBC подключился к PeopleSoft и Siebel напрямую, к копиям баз и только на чтение, и выгрузил структуру таблиц. Интерфейсы приложений для этого не нужны. Так стало видно, какие поля люди заполняют на самом деле, а какие остались от старых настроек.
Сервис миграции написан на Java и идёт этапами: справочники, сотрудники, клиенты с автомобилями, история сервиса. На каждом этапе есть таблица соответствий старых значений новым. Должности, филиалы, виды работ и статусы заказ-нарядов сопоставляли вместе с сотрудниками компании. Моя часть — подготовить списки и вынести спорные случаи.
Дубли клиентов искал по телефону, реквизитам юрлиц и связке ФИО с датой рождения. VIN приводил к одному виду: убирал пробелы, заменял кириллические буквы, похожие на латинские, проверял длину и недопустимые символы. Сомнительные пары автоматически не склеивались, они уходили в список на ручную проверку.
После каждого этапа сервис сравнивал количество записей и контрольные суммы по обе стороны. Бухгалтерия и сервисные менеджеры сверяли отчёты «было/стало» по привычным формам. Любое расхождение останавливало следующий шаг.
Потоки, которые шли через Oracle Fusion Middleware, разобрал по описаниям процессов и переписал в виде небольших Java-сервисов. У каждого своя очередь сообщений, журнал и понятная повторная отправка после сбоя. Шина стала не нужна.
Старые системы оставили доступными только для чтения на период проверки: поменять там ничего нельзя, а заглянуть и сверить можно.
Данные десяти лет лежат в новой учётной системе и новой CRM. Клиента и его машины сотрудник находит в одной карточке, а не в трёх записях. История сервиса сохранилась, и мастер на приёмке видит прошлые визиты автомобиля.
Бухгалтеры и кадровики сверили отчёты на старых и новых данных и закрыли расхождения. Часть из них оказалась ошибками самих старых баз, которые годами никто не замечал. Их поправили при переносе, а в журнале записано, что изменилось и почему.
Интеграции стали понятными. Вместо шины, которую некому обслуживать, работают небольшие сервисы. Код прочтёт любой Java-разработчик, а по журналу видно, где застрял обмен.
Что осталось недоделанным. Склейка дублей шла осторожно, поэтому часть спорных клиентов пока осталась раздельной, и их разбирают вручную по мере обращений. Старые системы нельзя выключать, пока не закроется полный отчётный период. Когда это сделать, решает компания, а не я.
Дальше план простой: закончить проверку на полном периоде, заархивировать старые базы и отказаться от лицензий.
Если у вас тоже остались базы Oracle, которые нужно вывести без потерь, пришлите в личные сообщения на freelance.ru список систем, срок хранения данных и то, что с чем связано. Я набросаю порядок этапов и перечень проверок после каждого.
