
Когда компания начинает обсуждать миграцию BI, первый вопрос почти всегда звучит одинаково: «Сколько это будет стоить?». Дальше происходит вполне рациональный процесс — команда пытается оценить объём работ, прикинуть сроки и умножить их на стоимость ресурсов. На выходе получается цифра, которая выглядит обоснованной и управляемой.
Проблема в том, что почти в каждом проекте эта цифра оказывается заниженной.
Причём не на 10–20%, а иногда в разы. И дело здесь не в том, что команды плохо считают. Дело в том, что сама модель оценки не учитывает реальную природу BI-систем.
На первый взгляд BI-отчёт выглядит как интерфейс: графики, таблицы, фильтры.
Именно поэтому возникает соблазн оценивать его перенос так же, как разработку нового отчёта. Но в реальности BI — это гораздо более сложная конструкция.
В основе любого отчёта лежит три слоя.
Первый — это данные. Причём не просто таблицы, а набор источников, которые могут быть связаны между собой сложными отношениями. Часто эти связи формировались постепенно, под конкретные задачи, и не всегда документированы явно.
Второй слой — это логика. Формулы, агрегаты, вычисляемые показатели. Здесь особенно важна специфика языка DAX, который позволяет строить довольно сложные выражения в компактной форме. Но за этой компактностью скрывается большое количество зависимостей.
Третий слой — это контекст использования. Один и тот же отчёт может использоваться разными пользователями для разных задач. И это влияет на то, как именно интерпретируются данные.
Когда начинается миграция, переносится не просто визуализация. Фактически пересоздаётся вся эта система — со всеми её зависимостями и особенностями. Именно поэтому оценка «по количеству отчётов» почти всегда оказывается некорректной.
Один из самых недооценённых факторов в проектах миграции — это время. Причём не столько календарное, сколько совокупность всех этапов, через которые проходит каждый отчёт.
На практике перенос включает несколько последовательных шагов, каждый из которых требует отдельного внимания.
Сначала идёт анализ структуры. Команда должна понять, из каких источников формируется отчёт, какие таблицы используются, как они связаны между собой. В простых случаях это занимает часы, в сложных — дни.
Затем начинается разбор логики. Именно здесь проявляется основная сложность. Формулы, написанные на DAX, редко бывают тривиальными. Даже если выражение выглядит коротким, оно может опираться на другие меры, фильтры и контексты. Аналитику нужно не просто переписать формулу, а воспроизвести её поведение в другой системе.
После этого идёт этап реализации. Создаётся модель данных, настраиваются связи, воспроизводятся вычисления.
Но на этом работа не заканчивается. Следующий этап — тестирование. Нужно убедиться, что цифры совпадают, что фильтры работают корректно, что поведение отчёта соответствует ожиданиям пользователей.
И, наконец, исправление ошибок. Практически в каждом отчёте находятся расхождения, которые требуют дополнительного анализа и доработки.
В результате даже один отчёт превращается в многоэтапный процесс. И именно суммарное время всех этих этапов формирует основную стоимость миграции.
Даже если команда правильно оценила трудозатраты на перенос отчётов, это ещё не означает, что бюджет будет соблюдён. В проектах миграции есть слой затрат, который часто не учитывается на старте.
Один из самых значимых факторов — это параллельное существование двух систем. Старая система не может быть отключена до тех пор, пока новая не начнёт полностью её заменять. Это означает, что компания фактически поддерживает две BI-инфраструктуры одновременно. Это тянет за собой цепочку последствий.
Во-первых, увеличиваются инфраструктурные расходы. Необходимо поддерживать сервера, хранение данных, обновления и резервное копирование для обеих систем.
Во-вторых, усложняется контроль качества. Каждый отчёт приходится проверять не только сам по себе, но и в сравнении со старой версией. Это увеличивает время тестирования и требует дополнительных ресурсов.
В-третьих, возрастает нагрузка на команды. Аналитики и инженеры вынуждены работать сразу в двух системах, переключаться между ними и синхронизировать изменения.
Эти затраты редко фиксируются как отдельная статья бюджета, но именно они часто становятся причиной его превышения.
Любая ручная работа предполагает интерпретацию. И в случае с BI это становится критически важным фактором.
Даже опытные специалисты, работая с одним и тем же отчётом, могут принимать разные решения. Например, по-разному интерпретировать бизнес-логику или выбрать разные способы реализации расчётов в новой системе.
Кроме того, всегда существует риск упущенных деталей. Отчёт может содержать скрытые зависимости, нестандартные фильтры или особенности, которые не очевидны при первом анализе.
Особенность BI в том, что ошибки здесь не всегда проявляются сразу. Отчёт может выглядеть корректно, визуально совпадать со старым, но давать небольшие расхождения в цифрах.
Эти расхождения могут оставаться незамеченными до тех пор, пока не попадут в бизнес-процесс. И тогда их исправление становится гораздо более дорогим — как с точки зрения ресурсов, так и с точки зрения доверия пользователей.
Таким образом, человеческий фактор влияет не только на качество, но и на стоимость проекта.
Ещё один важный фактор, который часто недооценивается, — это доступность специалистов.
Миграция BI требует не просто разработчиков или аналитиков. Нужны специалисты, которые одновременно понимают:
Такая комбинация навыков встречается нечасто. Кроме того, такие специалисты, как правило, уже заняты в текущих проектах. Их невозможно просто «выделить» на миграцию без ущерба для других задач.
В результате возникает ограничение, которое сложно масштабировать: скорость миграции определяется не количеством отчётов, а доступностью экспертизы.
И это напрямую влияет на сроки и, как следствие, на бюджет.
Когда все перечисленные факторы складываются вместе, становится понятно, почему проекты миграции BI так часто выходят за рамки первоначальных оценок.
Здесь нет одной конкретной ошибки. Проблема системная.
Недооценивается сложность логики, не учитываются скрытые затраты, переоценивается доступность ресурсов. В результате каждая отдельная неточность добавляет небольшой перерасход, а вместе они формируют существенное отклонение от плана.
Важно понимать: это не исключение, а типичный сценарий.
Миграция BI — это не просто технический проект. Это сложная трансформация, в которой участвуют данные, логика, люди и процессы. И именно поэтому ключ к успешной реализации заключается не в попытке максимально точно посчитать бюджет на старте.
Гораздо важнее выбрать подход, который:
Только в этом случае стоимость миграции становится управляемой, а не сюрпризом в середине проекта.

Автор
Will Cheng
Похожие статьи

Автоматическая миграция Power BI → FineBI: как на самом деле устроен процесс переноса BI-системы
Технический разбор автоматической миграции Power BI → FineBI: PBIX, DAX, модели данных, визуализация и контроль качества.
Will Cheng
2026 май 12

Как мигрировать с Power BI без остановки бизнеса: инженерный взгляд на стратегии перехода
Разбираем стратегии миграции Power BI: Big Bang, постепенный переход и гибридный подход. Как избежать остановки бизнеса при смене BI-системы.
Will Cheng
2026 май 12

Ручная миграция Power BI: системные риски, которые проявляются только в процессе
Разбираем, почему ручной перенос Power BI приводит к срывам сроков, ошибкам в данных и росту стоимости BI-проектов.
Will Cheng
2026 май 11