Обновлено 3 сентября 2026 года.
Полезный кейс Power BI отвечает на четыре вопроса: какое решение принимал бизнес, какие данные использовал, как считал показатели и чем подтвердил результат. Скриншот отчёта и обещание «повысить эффективность» этих ответов не заменяют.
В начале статьи приведены два опубликованных клиентских кейса Microsoft с датами и источниками. Затем — самостоятельные учебные примеры с условными данными и контрольными расчётами. Их можно воспроизвести в своей модели; они не являются результатами внедрений BI Data.
Опубликованный кейс: общая финансовая модель Walmart
В клиентской истории от 11 октября 2022 года Microsoft описывает стандартизацию финансовой аналитики Walmart на Power BI. В центре решения — библиотека семантических моделей, через которую аналитики получают доступ к финансовым данным и детализации проводок.
Согласно публикации, общая модель помогает сократить сбор данных и согласование расходящихся отчётов. Это описание проекта со стороны поставщика и клиента, а не независимое измерение причинного эффекта. Приведённые там изображения отчётов содержат вымышленные демонстрационные значения — Microsoft отмечает это в подписях.
Что можно перенести в свой проект: согласовать определения показателей в одной модели, назначить владельцев расчётов и позволить подразделениям создавать отчёты поверх общей основы. Для проверки эффекта измеряйте время подготовки отчёта и число расхождений до и после внедрения, сохраняя сопоставимый объём работы.
Опубликованный кейс: движение запасов Marks & Spencer
В истории от 31 марта 2023 года описаны платформа BEAM, Azure Synapse Analytics и Power BI в Marks & Spencer. Среди решений — Stock Movement Tool для анализа движения продуктов по цепочке поставок, в том числе отчёты в портале для поставщиков.
Публикация показывает, что отчётность опиралась на подготовку данных и общую платформу, а внедрение сопровождалось обучением сотрудников. Это исторический пример архитектуры и организации работы; он не подтверждает, что в 2026 году все компоненты проекта остались прежними.
Практический вывод: для контроля запасов нужны согласованные данные о движениях, доступ партнёров и понятный процесс использования отчёта. Одна визуализация не создаёт достоверный остаток, если в исходной системе пропущены перемещения или возвраты.
Учебный пример 1. Продажи, средний чек и валовая прибыль
Вопрос: сколько заказов оплачено, какую сумму они принесли и как результат различается по каналам? В таблице Sales одна строка означает один заказ. ID заказа уникален; один клиент может сделать несколько заказов.
Условные суммы ниже заданы в рублях, в единой базе без НДС. Revenue — выручка после скидок; ProductCost — себестоимость проданного по принятому в примере правилу. Возвратов и неоплаченных заказов в этом маленьком наборе нет. В рабочем отчёте для них потребуются отдельные правила.
| OrderId | CustomerId | Channel | Revenue | ProductCost |
|---|---|---|---|---|
| 101 | C1 | Search | 1000 | 700 |
| 102 | C2 | Search | 2000 | 1400 |
| 103 | C1 | 1500 | 900 | |
| 104 | C3 | Referral | 500 | 300 |
| 105 | C2 | Search | 1000 | 650 |
| 106 | C4 | 1000 | 600 |
Для воспроизведения внесите таблицу через Enter data в Desktop и назовите её Sales. Для Revenue и ProductCost задайте числовой тип, для остальных полей — согласованные типы идентификаторов и текста. Создайте следующие меры по одной через New measure. Формулы используют запятые как разделители аргументов.
Revenue = SUM(Sales[Revenue])
Product Cost = SUM(Sales[ProductCost])
Gross Profit = [Revenue] - [Product Cost]
Orders = DISTINCTCOUNT(Sales[OrderId])
Customers = DISTINCTCOUNT(Sales[CustomerId])
Average Order = DIVIDE([Revenue], [Orders])
Gross Margin = DIVIDE([Gross Profit], [Revenue])Это меры, а не вычисляемые столбцы. Gross Margin отформатируйте как процент: умножать результат дополнительно на 100 не нужно. DISTINCTCOUNT подходит здесь при условии непустых корректных ID; отдельно проверяйте пропуски ключей в реальных данных. Синтаксис функций: SUM, DISTINCTCOUNT, DIVIDE.
| Показатель | Контрольный результат |
|---|---|
| Выручка | 7 000 ₽ |
| Себестоимость | 4 550 ₽ |
| Валовая прибыль | 2 450 ₽ |
| Заказы / клиенты | 6 / 4 |
| Средний чек | ≈1 166,67 ₽ |
| Валовая маржа | 35% |
Постройте карточки общей выручки, прибыли и среднего чека, затем таблицу с Channel в строках. При выборе Search выручка должна стать 4 000, прибыль — 1 250, число заказов — 3. Так вы проверите и арифметику, и контекст фильтра.
Количество клиентов по каналам нельзя просто сложить: C1 встречается и в Search, и в Email. В целом клиентов четыре, хотя сумма уникальных клиентов отдельных каналов равна пяти. Мера должна пересчитываться в итоговом контексте. Подробности — в руководстве по DAX.
Учебный пример 2. Реклама: выручка и окупаемость — разные показатели
Добавим таблицу Spend с расходами за тот же условный период. Channel в Sales означает присвоенный заказу канал по выбранному правилу атрибуции. Это не обязательно канал первого привлечения клиента.
| Channel | AdCost | Выручка из Sales | Валовая прибыль из Sales |
|---|---|---|---|
| Search | 800 | 4000 | 1250 |
| 200 | 2500 | 1000 | |
| Referral | 0 | 500 | 200 |
В Spend внесите только Channel и AdCost; два остальных столбца таблицы выше показаны для сверки. Создайте DimChannel с тремя уникальными каналами и связи один-ко-многим от него к Sales и Spend с фильтрацией от справочника к фактам. Для срезов используйте DimChannel. Не присоединяйте месячный расход к каждой строке заказа: это размножит сумму расходов.
Ad Spend = SUM(Spend[AdCost])
ROAS = DIVIDE([Revenue], [Ad Spend])
Profit After Ads = [Gross Profit] - [Ad Spend]
ROMI = DIVIDE([Profit After Ads], [Ad Spend])Здесь ROAS — отношение приписанной выручки к рекламе, а ROMI определён как (валовая прибыль − реклама) / реклама. ROAS показываем коэффициентом, ROMI — процентом. Это заданные определения управленческого примера; «прибыль после рекламы» не учитывает все расходы компании и не является чистой прибылью.
| Канал | ROAS | Прибыль после рекламы | ROMI |
|---|---|---|---|
| Search | 5 | 450 ₽ | 56,25% |
| 12,5 | 800 ₽ | 400% | |
| Referral | Не определён при нулевом расходе | 200 ₽ | Не определён при нулевом расходе |
| Всего | 7 | 1 450 ₽ | 145% |
DIVIDE без альтернативного результата возвращает BLANK при нулевом знаменателе. Не показывайте в таком случае бесконечную окупаемость или ноль. Итоговые коэффициенты считайте по итоговым суммам, а не средним значением строк.
Высокий ROAS Email в этой выборке не доказывает, что весь бюджет нужно перенести в рассылки. Каналы могут работать с разной аудиторией; заказы постоянных клиентов и новые продажи различаются. До решения нужны модель атрибуции, новые клиенты, возвраты, ограничения масштабирования и проверка дополнительного эффекта рекламы.
Учебный пример 3. Повторные покупки и удержание
В Sales два клиента из четырёх сделали более одного заказа: C1 и C2. Доля повторных покупателей внутри этого периода — 50%. Это не месячное удержание, поскольку таблица не содержит дат первой покупки и следующего периода.
Для когортного удержания определите дату первой покупки клиента, сформируйте когорту и отслеживайте возвращение в последующие завершённые периоды. Например, если в условной когорте M0 было 100 новых покупателей и 30 из них купили в M1, удержание M1 равно 30%. Количество заказов этих 30 людей не меняет знаменатель.
На отчёте полезны размер когорты и доля вернувшихся по периодам. Молодые когорты нельзя сравнивать со старыми по ещё не завершённым месяцам. Не подменяйте отсутствие наблюдения нулём. Для сегментации по давности, частоте и сумме покупок потребуется отдельно определить RFM. ABC, XYZ и RFM на примерах.
Учебный пример 4. Производство и качество
Допустим, за первую смену проверено 1 000 изделий, из них 10 признаны дефектными. За вторую — 100 изделий и 5 дефектных. Доли составляют 1% и 5%, а общая доля — 15 / 1 100 ≈ 1,36%. Простое среднее 3% неверно для объединённого объёма.
Различайте число дефектов и число дефектных изделий: у одного изделия может быть несколько дефектов. Если в числителе количество дефектов, показатель может превышать 100%, и это уже не доля дефектных изделий.
Для отчёта нужны партия, изделие или объём проверки, линия, смена, время и классификатор причин. На обзорной странице покажите объём проверки, долю брака и динамику; далее — детализацию по партиям. Сам факт различия двух смен не доказывает причину: могли измениться продукт, метод контроля или состав выборки.
Другие сценарии: какой исходной информации не хватает
| Задача | Что хранить | Распространённая ошибка |
|---|---|---|
| Финансовый план-факт | Версию плана, период, статью, подразделение и согласованную базу факта | Сравнить платежи с выручкой или разные версии бюджета |
| Проекты и сроки | Плановые и фактические даты, историю статусов, календарь работы | Вычислять длительность стадий из одного текущего статуса |
| Прогноз спроса | Историю продаж, наличие товара, промоакции и периоды наблюдения | Считать нулевые продажи при отсутствии товара нулевым спросом |
| Социальные сети | Данные доступного API или выгрузки с датой среза и определением метрики | Обещать универсальный коннектор и любые показатели без проверки доступа |
| Анализ рынка | Проверяемый источник внешних данных, охват и методику оценки | Выдавать собственные продажи за весь рынок или считать Power BI источником выручки конкурентов |
Для прогнозов сравнивайте метод с простой базовой моделью на будущих относительно обучения периодах. Красиво продолженная линия не подтверждает точность. Не заполняйте все пропуски нулём автоматически: сначала выясните, отсутствовало событие или наблюдение. Пример проверки прогноза — в статье о прогнозировании в Power BI.
Как превратить пример в рабочий отчёт
- Запишите решение. Кто использует показатель и какое действие предпримет при отклонении?
- Опишите данные. Источник, ключ, детализация, период, валюта, часовой пояс и правила исключений.
- Согласуйте формулы. Заказ, оплата, выручка, валовая прибыль и клиент должны иметь однозначные определения.
- Сверьте небольшой набор. Получите ожидаемые результаты вручную или отдельным контрольным расчётом.
- Создайте модель. Проверьте уникальность справочников, связи и направление фильтрации.
- Постройте страницу решения. Ключевые показатели, сравнение с целью, динамика и переход к деталям.
- Проверьте фильтры. Сверьте один канал, период и клиента, а затем общий итог.
- Настройте эксплуатацию. Доступ, обновление, журнал ошибок и владельца отчёта.
В примерах используется отчёт Power BI. Отчёт и dashboard сервиса — разные объекты: не все действия над ними совпадают. Для знакомства с готовыми файлами можно взять официальные образцы Microsoft; проверяйте описание происхождения данных конкретного образца.
Публикация не заменяет настройку доступа и обновления
Публикация из Desktop отправляет содержимое в рабочую область. Она не делает внутренний отчёт доступным всем без учётной записи. Настройте права зрителей, условия лицензирования и ограничения строк там, где они требуются. Publish to web создаёт публичный доступ и не подходит для внутренней CRM или финансовых данных. Условия Publish to web.
Для Import расписание обновления настраивают в сервисе, проверяя учётные данные и, при необходимости, шлюз. Сам шлюз не определяет расписание и не гарантирует мгновенное появление событий. Подробнее — в руководстве по обновлению данных.
При совместной разработке назначьте владельца модели и порядок публикации изменений. Не рассчитывайте на неограниченную историю каждого действия и одновременное редактирование всех файлов как на автоматическую защиту от потерь: используйте поддерживаемые механизмы версионирования и проверку перед заменой рабочего отчёта.
Как измерять результат внедрения
До запуска зафиксируйте время подготовки отчёта, частоту ошибок, задержку данных и действия, для которых отчёт нужен. После запуска измеряйте те же показатели за сопоставимый период. Сокращение ручной подготовки с четырёх часов до одного — измеримое изменение процесса; рост продаж после появления отчёта сам по себе ещё не доказывает его причинный вклад.
В карточке кейса сохраняйте период, исходное состояние, выполненные изменения, способ измерения и ограничения вывода. Тогда «реальный пример» можно проверить, а полезную часть решения — перенести в другой бизнес.