17 июля 2026
5
Реализация системы бизнес-аналитики (BI) может пройти технически гладко, но не принести ожидаемого эффекта компании. Причина обычно не в самой платформе, а в организации работы над проектом. Начальник отдела витрин данных и аналитики IBS Анна Филиппова поделилась взглядом на то, почему возникают такие ситуации и как их избежать.
Главные причины неудач в BI-проектах
Профильные исследования и реальный опыт показывают, что серьезные проблемы в BI-проектах чаще всего возникают не из-за несовершенства платформ, а из-за просчетов в управлении и неверных ожиданиях. Зачастую в компаниях не уделяют достаточного внимания качеству данных, вовлеченности пользователей и тому, на какие стратегические решения должны повлиять показатели отчетности из BI-системы. В результате даже при корректной загрузке данных и стабильной работе дашбордов (аналитических панелей) проект может не приносить пользу бизнесу. В большинстве случаев к этому приводят шесть ключевых причин.Причина 1. Нет привязки к бизнес-целям и метрикам
Внедрение BI-решений должно отвечать на конкретные вопросы, например: «Почему падает конверсия?» и «Какие клиенты чаще уходят?». Во многих компаниях вместо этого создают универсальные панели управления без четкой цели. Рассчитанные в них метрики не ложатся в основу действий руководителей и остаются оторванными от бизнес-процессов. Такая аналитическая панель может показывать средний чек, не формируя понимания, на что он влияет.Причина 2. Данные есть, но им не доверяют
В случае расхождений между данными BI-платформы, отчетов из «1С» и других учетных систем многие пользователи выбирают привычный «правильный» Excel. На такую тенденцию может указывать обилие выгружаемых файлов в этом формате. Проблему может усугублять отсутствие в BI прозрачной методологии расчета для ключевых показателей. Пользователи не понимают, как система оценивает удержание клиентов, совокупную выручку или чистую прибыль, которую клиент приносит компании за все время взаимодействия. При этом отсутствует владелец данных, а значит, некому подтвердить корректность показателей.Причина 3. Пользователи не используют бизнес-аналитику в работе
Если после внедрения BI-системы компания не проводит обучение персонала, пользователи могут просто не знать о существовании дашбордов или не понимать, как с ними работать. Решение могут считать неудобным и из-за медленно применяющихся фильтров и ограниченного мобильного доступа к инструментам анализа. Кроме того, у руководителей может в принципе не сформироваться привычка принимать решения на основе бизнес-аналитики вместо опоры на собственную интуицию.Причина 4. Низкое качество данных из-за человеческого фактора и отсутствия контроля
Такая проблема возникает, если, например, в систему управления взаимоотношениями с клиентами (CRM) вносят неточную информацию: если менеджеры округляют суммы сделок при заполнении полей или компания удаляет архивные данные, чтобы сэкономить на серверах. В результате теряются исторические тренды, а источники бизнес-аналитики расходятся с реальными показателями. Это делает прогнозы и выводы BI-платформ неверными.Причина 5. Решение не интегрировано в процессы компании
При неупорядоченных операционных процессах попытка настроить сквозную аналитику в компании обречена на провал. В таких случаях дашборды демонстрируют отклонения показателей от нормы, но нет регламента, кто и когда должен на это реагировать. При этом бизнес-аналитика не встроена в ежедневные повторяющиеся процессы, такие как рабочие совещания, email-рассылки отчетов и автоматические проверки целей подразделений.Причина 6. Неверные объекты и методы измерений
BI-платформы могут не давать желаемого эффекта при использовании запаздывающих метрик (например, продаж за прошлый квартал) вместо опережающих (активности в воронке). Сотрудники могут усреднять показатели там, где нужна сегментация, что скрывает аномалии в данных и не позволяет использовать в BI дополнительные возможности аналитики. Еще один источник проблем — отсутствие проверки гипотез, при котором аналитическая панель строится без понимания, какое решение она изменит.Специфика импортозамещения BI-платформ
Отдельная зона риска — вынужденный ускоренный переход компаний с BI-платформ уходящих западных вендоров на отечественное ПО, который часто проходит без должной подготовки. Такие проекты требуют больших усилий по переносу данных в ущерб развитию аналитики. Миграция BI — проект с повышенным риском провала, но это связано не с недостатками технических инструментов, а со стратегическими ошибками. Если их допустить, то после перехода компания может получить старые проблемы на новом ПО.Самая распространенная ошибка — перенос «как есть»
Самая распространенная ошибка российского бизнеса в таких проектах — перенос по модели «как есть». В этом случае команда пытается просто скопировать старые дашборды и логику на новую платформу, забывая о нюансах. Например, облачные BI-системы работают не так, как локальные. Старые модели данных, настроенные с учетом серверных мощностей, в облаке замедляются и повышают издержки компании, генерируя неэффективные запросы.Перенасыщение информационного контура
Ситуация усложняется в случае перенасыщения информационного контура, при котором в компании хранятся тысячи отчетов, многие из которых никто не открывает. При смене платформы неупорядоченный массив данных просто переносится в новую систему и становится источником проблем, особенно при отсутствии владельца данных.Неверное планирование бюджета
Миграцию часто затрудняет и неверное планирование бюджета. Стоимость перехода на новую BI-платформу почти всегда оказывается выше, чем ожидалось, причем во многих случаях в несколько раз. Так происходит из-за того, что компании на стадии планирования не учитывают параллельную работу двух систем в переходный период, расходы на вычислительные ресурсы в облаке и долгое переписывание запросов на языке DAX вручную.Технические риски (DataOps)
Проблемы также могут возникнуть, если при миграции не учитывать технические риски (DataOps). Например, скрипты обновления информации могут перестать работать после смены версии СУБД или сервера. После перевода базы SQL на другую платформу может потребоваться ручная адаптация пользовательских представлений для корректной работы семантической модели.Человеческий фактор и сопротивление пользователей
Наконец, на миграцию может повлиять человеческий фактор, в первую очередь консервативный настрой и сопротивление пользователей. Они могут не доверять новым показателям и продолжать делать отчеты по старой методике. Часто это связано с тем, что прозрачность данных разрушает привычные схемы влияния. В то же время для миграции нужны специалисты, которые знают обе платформы. Дефицит таких сотрудников может привести к срыву сроков проекта.Как избежать ошибок
Для успешной реализации BI-проекта следует четко сформулировать, какую бизнес-проблему решает внедрение платформы и с помощью каких метрик будет оцениваться результат. Сначала можно за 2–4 недели создать базовую версию системы (минимально жизнеспособный продукт) и получить обратную связь от реальных пользователей. При этом надо обязательно назначить владельца метрик из числа представителей бизнеса, которые будут использовать данные BI-платформы для принятия решений. Также необходимо встроить систему в регулярные активности: от утренних дайджестов до создания автоуведомлений о выходе метрик за пределы нормы. После этого можно переходить к полноценному внедрению, которое занимает не менее четырех месяцев.Алгоритм успешной миграции
Если необходимо выбрать BI-платформу при переходе с иностранного ПО, в первую очередь следует проанализировать функциональные и нефункциональные требования к аналитической отчетности, сравнить характеристики доступных систем и их соответствие требованиям. Эксперты советуют использовать следующий алгоритм, чтобы обеспечить успешную миграцию:• Рационализация. Прежде чем переносить код, стоит посмотреть, какие отчеты действительно используются. Если удалить дублирующиеся и ненужные данные, можно сократить количество переходящих объектов на 30–50%.
• «Сдвиг влево» (миграция логики в СУБД). Не следует переносить высоконагруженные вычисления в BI, лучше оставить их в базе данных или витрине. Роль BI-платформы должна сводиться к наглядному представлению и визуализации готовых результатов.
• Пилотная версия (минимально жизнеспособный продукт). Не стоит сразу выполнять полномасштабную миграцию. Лучше сначала перенести один ключевой отчет и показать результат руководителям, принимающим решения о проекте, чтобы на раннем этапе получить от них обратную связь и поддержку.
• Автоматизация. По возможности лучше использовать инструменты для автоматической конвертации кода, чтобы минимизировать ручной труд и ошибки, связанные с человеческим фактором.
Хороший способ оптимизировать внедрение BI — обратиться к экспертам для предпроектного обследования ИТ-инфраструктуры, сбора требований, формирования рекомендаций по выбору платформы и составления дорожной карты.
Учиться на курсе
Внедрение BI-системы начинается задолго до выбора платформы и не заканчивается установкой дашбордов: фундамент успеха — это качество данных, четкая терминология и назначенные владельцы метрик. Именно эти аспекты системно разбираются в нашем курсе «Управление данными: от архитектуры до процессов и ИС», построенном на методологии DAMA-DMBOK и примерах из практики российского бизнеса. Освоив этот материал, вы сможете не просто визуализировать данные, а выстроить процессы, которые превратят аналитику в работающий инструмент управления.Автор — Анна Филиппова.
Оригинал статьи — на сайте IBS.ru