§ P3 — Power BI · Руководство

Power BI для среднего бизнеса

Выбрать · Внедрить · Развивать

Power BI — самый функциональный BI-инструмент на рынке. В 2025-2026 в стеке появились важные изменения (в первую очередь — PBIRS в SQL Server Standard), которые переворачивают экономику on-premise внедрения. Когда брать Power BI, как внедрять, как оптимизировать — разберём по пунктам.

Для кого эта статья. IT-директор, финдиректор или BI-лид компании с выручкой 500М–5Б₽, который выбирает BI-инструмент в 2026 или оптимизирует уже работающий Power BI.

Что изменилось в Power BI в 2025-2026

Главные события для on-premise Power BI за последний год:

Power BI Report Server теперь включён в SQL Server 2025 Standard и Enterprise по per-core модели, без Software Assurance. Раньше требовался Enterprise + SA (капитально от 3.5 млн ₽) — теперь достаточно обычной Standard core-лицензии
Power BI Pro подорожал до $14/мес с апреля 2025 (было $10) — это заметно ударило по TCO облачного сценария на горизонте 3-5 лет
Доступность облачного Power BI Service отличается по юрисдикциям: в некоторых регионах новые подписки недоступны или ограничены — уточняйте у своего реселлера перед выбором архитектуры
Power BI Desktop — бесплатный, работает без привязки к tenant-у, никаких изменений

Практический вывод: для большинства новых on-premise проектов в 2026 ставьте Report Server через SQL Server 2025 Standard per-core. Это закрывает весь отчётный контур без подписок. Функциональность Report Server — 85-90% от Service, нет Q&A (естественный язык), push-алертов и части облачных datasets. Для управленческой отчётности среднего бизнеса этого хватает.

Power BI vs альтернативы

В 2026 для среднего бизнеса есть три зрелых BI-продукта, которые стоит сравнивать:

Power BI Report Server — самый функциональный, DAX-модель, живое подключение к SSAS Tabular, богатая визуализация, большое сообщество. on-premise.
Облачные managed BI-платформы (DataLens, Metabase Cloud, Looker, Mode) — быстрое развёртывание, подписочная модель, базовые визуализации, разные диалекты SQL/собственных языков. Подходят под простые сценарии и стартапы.
Apache Superset — open-source, on-premise, SQL-first подход (меньше фронт-end функций), требует дата-инженера для поддержки.

Выбор между ними:

Критерий	Power BI RS	Облачный managed BI	Superset
Лицензия	SQL 2025 Standard per-core, от ~800 тыс. ₽ за сервер	От 15-30 тыс. ₽/мес по подписке	Бесплатно
Хостинг	on-premise	Облачный (managed)	on-premise
DAX / семантический слой	Да, через SSAS Tabular	Ограниченно, зависит от платформы	Нет (SQL в datasets)
Интеграция с 1С	Через DWH (стандарт)	Через DWH	Через DWH
Visual-уровень	Высокий	Средний	Средний
Порог входа	Внедрение 6-12 нед., собственные ИТ	Дни-недели, минимум DevOps	Своя дата-команда обязательна

На практике: для корпоративного среднего бизнеса (20+ отчётов, 100+ пользователей) Power BI + SSAS Tabular выигрывает по функциональности и предсказуемости TCO. Облачные managed платформы подходят e-com и стартапам, где скорость важнее сложности. Superset — для компаний с сильной внутренней дата-командой.

Архитектура: Power BI — только презентационный слой

Типичная ошибка: «давайте подключим Power BI напрямую к 1С и построим отчёты». Работает в первый месяц, а через полгода отчёт за год открывается минуту и данные в разных отчётах не совпадают.

Правильная архитектура корпоративного BI — три слоя:

DWH — MS SQL Server, трёхслойная схема (staging/core/marts), исторические данные, ETL из источников раз в сутки
Семантическая модель — SSAS Tabular, DAX-меры, RLS (Row-Level Security), партиции, агрегации
Визуализация — Power BI (Desktop для разработки, Report Server для публикации)

Зачем семантическая модель отдельно от Power BI:

Переиспользование мер — одна мера «Выручка» используется в 30 отчётах. Определение в SSAS, не в каждом .pbix-файле
Централизованный RLS — политики доступа на уровне модели: региональный менеджер видит свой регион, финдиректор — всё. Неважно, из какого отчёта
Производительность — SSAS Tabular работает с сжатой in-memory моделью (VertiPaq). Типичная модель среднего бизнеса (100М строк фактов, 30 измерений) — 8-16 ГБ RAM, отчёты отрабатывают за секунды
Альтернативные клиенты — Excel с pivot поверх MDX, кастомные дашборды через REST. Не всё крутится только через Power BI

Сколько стоит каждый слой для компании 1Б ₽ выручки (на основе правил SQL Server 2025): SQL Server 2025 Standard per-core (от ~800 тыс. ₽ за 4 ядра, Report Server в комплекте) + SSAS Tabular (входит в Standard) + железо. Итого железа и лицензий — 1-1.8 млн ₽ единоразово. Разработка — от 1-3 млн ₽ в зависимости от объёма. Подробная разбивка — в статье про TCO на MS Stack.

Когда отчёты тормозят: куда смотреть в первую очередь

«Отчёт открывается 40 секунд» — типовая ситуация. В 80% случаев причина не в железе, а в модели или DAX. Порядок диагностики:

DAX Studio Performance Analyzer — показывает, сколько времени тратится в Storage движок vs Formula движок. SE-bottleneck = проблема в модели. FE-bottleneck = проблема в DAX
Проверьте кардинальность — колонки с высокой cardinality (более 1М уникальных значений) плохо сжимаются и тормозят фильтры. Часто найдутся timestamp-ы до секунд, которые можно усечь до минут/часов
Bi-directional filters — если в модели есть связи с двунаправленной фильтрацией, каждый фильтр порождает полный скан. По возможности — single direction
Many-to-many связи — особенно без bridge-таблицы — убивают производительность
CALCULATE с ALL в мерах — часто неоправдан, заменяется на REMOVEFILTERS с конкретными колонками или KEEPFILTERS
VAR вместо повторных вычислений — банальная оптимизация, даёт 2-5× ускорение на сложных мерах

На одном из наших аудитов мы ускорили CEO-отчёт с 42 секунд до 1.8 секунды — рефакторинг DAX, замена snowflake-схемы на star и агрегационные таблицы для годовых срезов. Инфраструктура не менялась. Клиент готовился покупать Premium-ёмкость (~900К₽/мес) — не понадобилось. Детали кейса.

RLS: контроль доступа через модель, а не через отчёты

Row-Level Security — правила, которые на уровне семантической модели ограничивают, какие строки видит пользователь. В SSAS реализуется через DAX-выражения в ролях.

Пример: региональный менеджер должен видеть только свой регион. В SSAS — роль с фильтром:

[tr Регион] = LOOKUPVALUE(
    [tr Сотрудник][Регион],
    [tr Сотрудник][AD_Login], USERPRINCIPALNAME()
)

Роль применяется ко всем отчётам, подключённым к модели. Обойти из UI нельзя — SSAS физически не возвращает запрещённые строки.

Типичные ошибки при реализации RLS:

RLS на уровне отчёта, не модели — каждый новый отчёт нужно заново настраивать, быстро ломается
Hard-coded список пользователей — добавили нового сотрудника — надо пересобирать модель. Правильно — таблица dim_employee с AD-login, и DAX-роль читает её
RLS + агрегаты — если используется, должен применяться и к агрегационным таблицам, иначе можно обойти фильтр

Lifecycle отчётов: dev → Промежуточный → prod

Зрелый BI — это не один разработчик, пишущий сразу в продакшн. Это процесс:

Dev — разработчик в Power BI Desktop, подключение к dev-модели SSAS (копия с ограниченным объёмом данных)
Code review — pbix commit в Git, пересмотр DAX, мер, структуры визуалов
Промежуточный — публикация в Report Server test-folder, подключение к Промежуточный-SSAS, тестирование бизнес-пользователями
Prod — перемещение в production-folder, переключение connection string на prod-SSAS, алерт команде

Параметризация connection string — опорная точка. В .pbit-шаблоне хранится параметр ServerName, при публикации он переключается на нужную среду. Без этого каждый .pbix хранит hard-coded адрес сервера.

Для версионирования мы используем PBIP-формат (Power BI project files, Microsoft добавил в 2023). Это текстовые файлы, их можно нормально дифать в Git. Бинарный .pbix — только для дистрибуции.

Сопровождение: что делать с BI после запуска

Типичная история: проект сдан, команда разошлась, через полгода отчёты тормозят, данные расходятся, никто не знает, что с этим делать. Чтобы не попасть в такую ситуацию, BI нужно сопровождать. Минимум — ежедневный мониторинг ETL и ежеквартальный performance-ревью.

Формат сопровождения зависит от размера:

10 часов/мес — стабильная система, мелкие доработки, редкие инциденты. Для компаний, где BI не растёт активно
20 часов/мес — растущая система, регулярно подключаются новые источники, расширяется модель
40 часов/мес — фактически разработчик на part-time. Для компаний с регулярными проектами развития

Что должно быть в SLA: P1 (полная остановка BI) — реакция 15 минут, восстановление 2 часа. P2 — реакция 1 час, 8 часов. P3 (доработки) — 1 день, 3 дня. Детали — страница про сопровождение.

Чек-лист: готова ли ваша компания к Power BI

Короткий self-assessment перед стартом проекта:

☐ У нас есть источники данных (1С, CRM, маркетплейсы), из которых нужно собирать отчётность
☐ Есть хотя бы 3-5 ключевых бизнес-отчётов, которые хочется автоматизировать (P&L, cash flow, продажи, воронка, остатки и т.д.)
☐ Есть куратор на нашей стороне (IT-директор или финдиректор) — 2-3 часа в неделю на проекте
☐ Понимаем, что BI — не разовый проект «построили и забыли», а живая система с сопровождением
☐ Готовы к 2-4 месяцам внедрения (пилот — 3 недели, полноценный ландшафт — 8-12 недель)
☐ Есть бюджет на проект (1-3М₽ для среднего бизнеса) и на сопровождение (80-400К₽/мес)

Если все шесть — да, вы готовы. Если 3-4 — сначала сделайте аудит текущей аналитики (5 дней, конкретный план). Если 0-2 — BI пока не для вас, сначала нужна база: нормализованные источники, регулярные бизнес-процессы.

Хотите обсудить ваш случай? 30-минутный звонок — разберём, что внедрять, в каком порядке и с какими рисками. Или посчитайте годовую экономию от BI на нашем калькуляторе — 30 секунд, три вопроса.