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

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

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

Что усложняет перенос данных между системами

Российские и западные корпоративные системы нередко существенно различаются на архитектурном уровне.

В локальных решениях, ориентированных на российские бизнес-процессы и законодательство, могут использоваться схожие подходы к построению справочников, документов и учетных моделей. Западные платформы — SAP, Oracle E-Business Suite, Microsoft Dynamics и другие — создавались в иной архитектурной и методологической парадигме.

В результате одному объекту в исходной системе далеко не всегда соответствует один аналогичный объект в новой. Могут отличаться количество и состав полей, типы данных, способы хранения истории, связи между таблицами, классификаторы и алгоритмы расчетов. Особенно хорошо эта проблема видна в HR-системах. Условная запись о сотруднике — это не просто фамилия, должность и подразделение. За ней может находиться история кадровых перемещений, изменение условий оплаты, графики рабочего времени, отсутствия, начисления и множество других связанных сущностей.

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

Поэтому миграция с SAP HCM и систем аналогичного класса — это прежде всего задача сопоставления двух моделей данных и двух наборов бизнес-правил.

Четыре этапа миграции

Типовой процесс переноса можно разделить на четыре крупных этапа: аудит, экспорт, трансформацию и импорт.

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

Затем выполняется выгрузка информации из исходной платформы. Уже на этом этапе могут проявиться технические ограничения: различия СУБД, особенности API, нестандартные форматы экспорта и накопленные за годы кастомизации.

Следующий этап — трансформация. Данные очищаются, приводятся к необходимым форматам, сопоставляются справочники и правила хранения информации.

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

Идентичность результата важнее идентичности структуры

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

Гораздо важнее обеспечить идентичность результата. Для финансового контура это означает совпадение отчетности и остатков. Для операционного — сохранение информации о контрагентах, сделках и истории операций. Для HR — корректное воспроизведение кадровой истории, табельного учета и расчетов.

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

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

Как эту задачу решают современные российские HR-платформы

Подход к миграции во многом зависит и от архитектуры системы, на которую переходит компания.

Один из примеров — российская платформа Digital Q.HR компании «Диасофт», предназначенная для кадрового учета, расчета заработной платы и управления рабочим временем в крупных организациях, включая компании с численностью от 5 тыс. сотрудников.

Продукт создавался в том числе как импортонезависимая альтернатива зарубежным HR-решениям уровня SAP HR и Oracle. При этом задача замещения здесь заключается не в буквальном воспроизведении архитектуры иностранного продукта.

Digital Q.HR построен в микросервисной архитектуре. Для проекта миграции это принципиальный момент: целевая платформа может адаптироваться к бизнес-процессам организации и требованиям российского законодательства без необходимости полностью копировать модель исходной системы.

Различия между платформами в этом случае становятся не препятствием, которое необходимо устранить, а условием, которое следует корректно учесть.

Например, сложную систему связанных таблиц исходной HR-платформы можно преобразовать в другую структуру хранения данных, сохранив при этом историю кадровых событий и точность табельного учета. Если в ходе миграции выясняется, что для расчетов необходимы дополнительные атрибуты, модель данных должна позволять их учитывать без разрушения всей логики переноса.

Для автоматизации таких операций в Digital Q.HR предусмотрены API и модули загрузки данных. Их задача — сократить объем ручных корректировок и помочь перевести информацию на единые правила учета.

Три группы рисков

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

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

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

Третья — техническая несовместимость. Разные базы данных, интерфейсы и API создают дополнительный слой сложности между исходной и целевой системами.

По отдельности каждая из этих проблем выглядит решаемой. Основной риск возникает на их пересечении. Технически корректно преобразованные данные могут оказаться неверными с точки зрения бизнес-логики, а корректное сопоставление справочников — нарушить исторические связи между записями.

Поэтому миграцию нельзя рассматривать исключительно как задачу разработчиков или администраторов баз данных. В проекте должны одновременно учитываться архитектура систем, особенности данных и реальные бизнес-процессы компании.

Что определяет успех миграции

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

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

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

«Диасофт» имеет опыт проектов переноса данных, включая замещение систем класса SAP HCM на Digital Q.HR. По данным компании, при таких миграциях приходится работать в том числе с сотнями тысяч исторических записей. Именно поэтому центральными задачами становятся управление качеством данных и проверка итоговых расчетов.

В заключение

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

В HR-контуре это особенно критично. Корректность кадровой истории, учета рабочего времени и расчетов напрямую влияет на заработную плату, налоги и обязательную отчетность. Поэтому результат миграции нельзя оценивать только по количеству перенесенных записей или факту запуска новой системы.

Ключевым критерием становится воспроизводимость результата: после перехода новая платформа должна корректно интерпретировать исторические и текущие данные и обеспечивать непрерывность привычных бизнес-процессов.

Именно такой подход лежит в основе проектов миграции на Digital Q.HR: предварительная оценка структуры и объема данных, тестовые загрузки, верификация результата и, при необходимости, параллельная проверка в старой и новой системах. Это позволяет рассматривать миграцию не как разовую техническую операцию, а как управляемый процесс перехода на новую архитектуру без потери качества данных и устойчивости HR-процессов.

Источник: TAdviser.

Больше новостей читайте в сообществе SAPLAND в ВК и телеграм-канале SAPLAND: Новости экосистемы.