Российский бизнес переживает эпоху «Великого перехода». Санкционное давление и уход западных вендоров заставили компании в спешке мигрировать на отечественное ПО. Но гонка за новыми платформами обнажила старую как мир проблему: наши системы полны «мусора».

На многочисленных проектах по миграции с SAP и западных CRM на российские решения наблюдается одна и та же картина: бизнес ждет «магии» от новой системы, а получает перенос хаоса. Аналитики и ИТ-специалисты приходят к выводу: битва за качество данных проигрывается не из-за отсутствия талантливых разработчиков, а потому что бизнес-анализ как дисциплина в России до сих пор не воспринимает данные как стратегический актив.

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

План

По крайней мере следующие темы должны быть освещены в дальнейшем:

1. Часть 1. «Синдром чистой миграции»: Почему перенос «как было» убивает новый бизнес

2. Часть 2. «Иллюзия темпоральности»: Почему вы не видите динамику и как SCD спасает аналитику

3. Часть 3. «Мифический золотой стандарт»: Почему Data Governance умирает в кабинетах и как сценарии использования возвращают к жизни

Часть 1. «Синдром чистой миграции»: Почему перенос «как было» убивает новый бизнес

Вступление

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

Содержание

Когда данные переносятся без предварительной очистки, вместе с полезной информацией мигрируют и накопленные годами «залежи мусора». Известен показательный кейс: в старой системе крупной торговой компании числилось 15 000 контрагентов. После аудита выяснилось, что реально работают только 3000. Остальные — «мёртвые души»: дубликаты (ООО «Ромашка», ООО «Ромашка» и ИП «Ромашкин»), компании, закрытые 10 лет назад, и индивидуальные предприниматели, давно сменившие статус. Если перенести всё это без очистки, новая система захлебнётся в шумах. Отделу продаж придётся обзванивать несуществующих клиентов, аналитики будут строить отчёты на некорректной базе, а производительность системы упадёт из-за обработки гигабайтов мусора.

Согласно исследованию проблем качества данных, опубликованному в ноябре 2025 года, данные определяются их пригодностью для конкретных бизнес-процессов через критерии точности, полноты, непротиворечивости, актуальности и достоверности. Перенос неактуальных контрагентов нарушает критерии актуальности и достоверности с самого начала работы новой системы. Более того, подобный подход закладывает мину замедленного действия под все последующие отчёты и аналитические выборки.

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

Как должен быть пересмотрен подход?

Современная практика системного анализа предлагает вместо простого ETL (Extract, Transform, Load — извлечение, преобразование, загрузка) проводить полноценную «инвентаризацию данных» как отдельный этап проекта миграции. Это не просто техническая задача — это бизнес-задача, требующая вовлечения ключевых пользователей и руководителей подразделений.

Аналитикам необходимо задать бизнесу жёсткие вопросы:

• «Какая у вас стратегия работы с клиентами? Вы будете искать новых среди этих 15 000 или работать только с активной базой?»

• «Что вы будете делать с дубликатами? Объединять их вручную или готовы заплатить за алгоритмы дедупликации?»

• «Какие данные действительно нужны для операционной деятельности, а какие можно отправить в архив?»

В том самом кейсе с 15 000 контрагентов ответы отделов были однозначны: продавцы хотели видеть только «живую» базу, маркетинг — сегментировать только активных клиентов, финансы — слать закрывающие документы реальным юридическим лицам. В результате 80% нерелевантной информации было отсечено ещё на этапе выгрузки. Система запустилась быстрее, отчёты перестали врать, а пользователи не проклинали ИТ-специалистов за «тормоза».

Рецепт: Этап 0 — Очистка перед миграцией

1. Профилирование данных. Запустите скрипты, которые подсчитают количество дубликатов, пустых полей, откровенно ошибочных записей (например, дата рождения 01.01.1900 или контрагенты без заказов за 3 года). Инструменты профилирования (например, Talend Data Quality, Informatica) позволяют автоматизировать эту работу.

2. Бизнес-верификация. Выгрузите списки «подозрительных» записей и передайте их владельцам данных (data owners). Пусть они поставят вердикт: удалить, заморозить или оставить. Без участия бизнеса здесь не обойтись — только они знают, нужен ли конкретный поставщик, который не работал пять лет.

3. Разработка правил очистки. Не делайте это вручную! Пропишите алгоритмы: как объединять дубликаты, по каким полям чистить справочники, какие значения считать эталонными. Это ляжет в основу ETL-процедур.

4. Маскировка и архивация. Если данные нужны только для истории (например, чтобы отчёт за 2010 год «сошёлся»), но не для операционной работы — выгружайте их в архивное хранилище, а не в основную базу новой ERP. Это сохранит производительность и чистоту оперативного контура.

Вывод

Миграция — это не переезд, а реновация. Нельзя переехать в новую квартиру со старыми тараканами. Задача аналитика — убедить заказчика выкинуть хлам до переезда, а не надеяться, что новая система сама «переварит» мусор. Как отмечают эксперты в области Data Governance, ключевая цель построения аналитики — предоставление единой версии правды, но если на входе мусор, на выходе будет «мусорная» версия правды. Только осознанное отношение к данным на этапе миграции способно заложить фундамент для качественной аналитики будущего.

P.S. Практические шаблоны и чек-листы для бизнес- и системных аналитиков я публикую в своем Telegram-канале: https://t.me/vas_yukoff