Финдиректор видит два отчёта по выручке за один год: 150 млн в старой системе и 145 млн в новой CRM. Виноватыми назначают айтишников. Но проблема не в миграции.
Разрыв в 5 млн рублей между системами — классический симптом того, что я называю «иллюзией темпоральности». Суть простая: система хранит только последнее известное состояние данных, игнорируя то, что бизнес непрерывно меняется. Клиент переехал — адрес обновился, но старые сделки теперь «переехали» вместе с ним. Товар прошёл ребрендинг — и вся его история числится под новым названием. Итог: исторические отчёты перестают быть историческими.
Это не баг конкретной CRM и не кривой скрипт миграции. Это архитектурное решение, принятое по умолчанию — хранить только актуальное состояние. И оно ломает аналитику задним числом.
Что такое SCD и почему это не академия. Slowly Changing Dimensions — методология, формализованная Ральфом Кимбаллом ещё в эпоху классических хранилищ данных. Она описывает стратегии того, как измерение (клиент, товар, сотрудник, регион) реагирует на изменение своих атрибутов. Выбор стратегии — архитектурное решение, которое определяет, можно ли будет восстановить состояние данных на любую дату в прошлом.
Тип 0 — атрибут неизменен: дата рождения, дата открытия счёта. Никогда не перезаписывается.
Тип 1 — перезапись: новое значение затирает старое. Подходит только для исправления ошибок ввода. Для реальных бизнес-изменений — гарантированный источник расхождений в отчётах.
Тип 2 — добавление новой строки: текущая запись закрывается (проставляется дата окончания), создаётся новая с актуальными данными и датой начала. Именно это позволяет восстановить состояние на любой момент прошлого.
Тип 3 — отдельный столбец для предыдущего значения: даёт сравнение «было/стало», но не полноценную историю.
Тип 6 — гибрид (1+2+3): аналитики получают и текущий срез, и полную историю одновременно.
Почему Тип 2 — это не опция, а обязательство. В российских компаниях, которые сейчас массово мигрируют с SAP и других западных систем, именно SCD Тип 2 оказывается тем местом, где теряются данные и репутация IT-команды. Если при миграции применялся Тип 1 — вся историческая аналитика пересчиталась под текущее состояние справочников. Отсюда и расхождения, которые невозможно объяснить без понимания этой механики.
Тип 2 дороже в реализации: больше строк, сложнее запросы, нужны суррогатные ключи и поля effective_date / expiry_date. Но это единственный способ, при котором отчёт за прошлый год остаётся отчётом за прошлый год — независимо от того, что изменилось в справочниках после.
Для CIO это не вопрос технологий — это вопрос доверия к данным. Когда финдиректор видит расхождение в 5 млн, он теряет доверие к новой системе. Восстановить его потом значительно сложнее, чем заложить правильную архитектуру с самого начала. Миграционные проекты без явного решения по SCD — это отложенный конфликт между бизнесом и IT, который случится ровно в момент первого серьёзного аудита.
