В одном из проектов я с нуля собирал BI-аналитику платных медицинских услуг. В отчёте нужно было показывать динамику доходов и помогать находить расхождения в данных. Когда первые страницы были готовы, визуально всё выглядело вполне убедительно: показатели считались, графики строились, фильтры переключались, явных ошибок на экране не было.

На этом месте очень хочется считать основную работу законченной. Отчёт открывается, ничего не падает, цифры похожи на правду. Можно показывать пользователям.

Но «похоже на правду» для аналитического отчёта - довольно опасный критерий. Особенно если речь идёт о финансовых показателях.

Во время проверки я выявил существенные расхождения. Точную сумму, внутреннее устройство систем и причины отдельных несоответствий я здесь не раскрываю. Важно другое: на самом графике не было никакого признака, что с данными что-то не так. Линия динамики оставалась аккуратной, карточки выглядели нормально, а ошибка проявлялась только при сверке результата с исходными данными и логикой процесса.

После этого я перестал воспринимать проверку BI-отчёта как обычный просмотр готового интерфейса. Проверять нужно не картинку, а весь путь цифры: от записи в источнике до значения, которое увидел пользователь.

График проверяет только сам себя

Главная проблема визуальной проверки в том, что неправильные данные тоже отлично визуализируются. Если сумма завышена на одном и том же участке всей выборки, линия динамики не станет от этого кривой. Если при соединении таблиц размножились записи, диаграмма просто покажет более высокий результат. Если часть данных не загрузилась, график может выглядеть как обычное снижение.

BI-инструмент не знает, какой результат бизнес считает правильным. Он честно отображает то, что получил от модели.

Поэтому я не начинаю проверку с вопроса «правильно ли выглядит диаграмма». Сначала мне нужно понять, можно ли независимо получить ту же цифру другим способом.

Для этого я выбираю закрытый период, по которому данные уже не должны заметно меняться, и получаю контрольный итог из источника или проверенного отчёта. Затем отдельно считаю тот же показатель на уровне аналитической витрины. И только после этого смотрю, какое значение показывает Power BI.

Получается три точки сверки:

исходная система или контрольная выгрузка;
подготовленная аналитическая витрина;
модель и визуализация в BI.

Если источник и витрина не совпали, проблему нужно искать в извлечении, фильтрации, соединениях или преобразованиях. Если витрина правильная, а Power BI показывает другое значение, значит, нужно разбирать модель, связи, меры и контекст фильтрации. Без такого разделения поиск быстро превращается в перебор всего подряд.

Сам дашборд при этом нельзя использовать как единственное доказательство собственной корректности. Сверять одну карточку Power BI с другой карточкой в том же файле почти бессмысленно, если обе используют одну ошибочную меру.

Сначала простая таблица, потом визуализация

Для проверки отчёта я почти всегда возвращаю данные в максимально скучный вид. Обычная таблица с идентификатором, периодом, подразделением, исходными составляющими и рассчитанным значением в этом плане намного полезнее графика.

В таблице видно, какая именно строка попала в расчёт два раза, где отсутствует значение справочника и почему итог одного подразделения отличается от другого. Диаграмма всё это агрегирует. В итоге ошибка исчезает за одним столбцом, который выглядит вполне логично.

Общий итог тоже недостаточен. Две ошибки могут случайно компенсировать друг друга: в одном месте сумма завышена, в другом занижена, а на верхнем уровне всё сошлось. Поэтому после общей сверки я выбираю несколько отдельных объектов и прохожу их вручную.

Это не обязательно должна быть большая выборка. Намного полезнее взять разные по поведению случаи: обычную запись, запись с изменённым статусом, граничную дату, пустое значение, повторное появление одного идентификатора и объект, который связан с несколькими строками в другой таблице.

Такие примеры быстро показывают, что именно считает модель. Например, обычный JOIN может незаметно размножить сумму, если с одной стороны находится одна операция, а с другой - несколько связанных записей. Запрос выполнится успешно, типы данных будут правильными, и только построчная проверка покажет, откуда взялось лишнее значение.

Отдельно я проверяю ноль и отсутствие данных. На графике они часто выглядят почти одинаково, хотя смысл совершенно разный. Ноль означает, что данные получены и расчёт действительно дал нулевой результат. Пустое значение может означать, что источник не обновился, связь не нашлась или запись не прошла условие отбора. Если превратить всё это в ноль, отчёт станет аккуратнее, но перестанет честно показывать качество данных.

Итоговая строка может считаться не так, как кажется

После проверки витрины остаётся ещё один слой - расчёты внутри Power BI. Здесь я отдельно смотрю не только формулу меры, но и контекст, в котором она вычисляется.

Одна и та же мера может вернуть разные значения в карточке, строке таблицы и общем итоге. Это не обязательно ошибка Power BI. Меры DAX рассчитываются заново для каждого набора фильтров, а итоговая строка получает собственный контекст. Это особенно заметно на процентах, средних значениях, уникальных объектах и других показателях, которые нельзя просто сложить между собой. Механика контекста описана в официальном обзоре DAX, но на практике её проще всего увидеть именно на небольшой контрольной выборке.

Предположим, в таблице показана доля по каждому подразделению. Пользователь может ожидать, что итог внизу равен сумме видимых строк. Но мера в итоговой строке обычно пересчитывает числитель и знаменатель уже для всей выборки. В зависимости от смысла показателя это может быть как правильным поведением, так и ошибкой постановки расчёта.

Поэтому я проверяю карточку, строки таблицы и итог отдельно. Если значения отличаются, сначала выясняю, какое из них соответствует бизнес-вопросу, а уже потом меняю DAX. Попытка просто заставить итог выглядеть привычно иногда исправляет внешний вид и ломает сам показатель.

При работе с моделями Power BI я также подключался к ним через DAX Studio и выгружал метаданные через DMV-запросы. Так удобнее увидеть полный состав таблиц, столбцов, мер и связей, особенно когда модель уже разрослась и по интерфейсу сложно понять, откуда приходит фильтр. Автоматические локальные таблицы дат я при такой проверке исключал, чтобы они не смешивались с объектами, которые действительно создавались для отчёта.

DAX Studio не заменяет проверку результата, но помогает разобрать модель как технический объект. Иногда проблема находится не в формуле, а в неактивной связи, неоднозначном пути фильтрации или неожиданно используемой таблице дат.

Фильтр нужно проверять как часть расчёта

Когда пользователь выбирает период или подразделение, он не просто меняет внешний вид страницы. Он меняет набор данных, на котором пересчитываются все меры. Поэтому фильтры для меня являются частью аналитической логики, а не элементом интерфейса.

Сначала я проверяю каждый фильтр отдельно. Затем комбинирую их и смотрю, остаётся ли результат ожидаемым. Именно в сочетаниях часто проявляются проблемы: один фильтр действует только на часть визуализаций, второй использует поле из другой таблицы, а третья диаграмма сохраняет собственное скрытое условие.

Есть несколько ситуаций, которые я стараюсь не пропускать:

выбран только один период;
выбран диапазон, захватывающий границу месяца или года;
выбрано одно подразделение;
одновременно выбраны подразделение, период и категория;
все значения фильтра сняты;
фильтр не возвращает ни одной записи;
пользователь нажал на элемент диаграммы и включил перекрёстную фильтрацию других объектов.

Последний вариант особенно коварный. Пользователь может нажать на столбец, затем переключить страницу и забыть, что часть отчёта всё ещё отфильтрована. Если состояние плохо заметно, он будет сравнивать неполные данные с общим итогом и искать проблему там, где её нет.

Проверять нужно и направление взаимодействия между визуализациями. Не каждый график обязан фильтровать все остальные. Иногда правильнее оставить объект независимым, например если он показывает общий ориентир для сравнения. Но такое поведение должно быть сознательным, а не случайным результатом настроек.

Граничные случаи я собираю заранее

На обычных данных почти любой отчёт работает нормально. Основные ошибки появляются на границах: первый и последний день периода, незавершённый месяц, изменившийся статус, отсутствующее подразделение, поздно пришедшая запись или дубликат идентификатора.

Поэтому со временем у меня появился небольшой набор контрольных случаев. Это не отдельная тестовая платформа, а список записей и ожидаемых результатов, к которому можно вернуться после изменения витрины, модели или меры.

Такой набор особенно полезен, когда отчёт развивается. Исправление одного показателя может незаметно изменить другой, потому что они используют общую таблицу, связь или базовую меру. Если после каждой доработки вручную вспоминать, что именно нужно проверить, часть сценариев обязательно потеряется.

Кроме конкретных примеров, я использую простые инварианты - условия, которые должны выполняться всегда. Например, уникальный бизнес-ключ не должен внезапно стать неуникальным. Доля не должна выходить за допустимые границы. Сумма по закрытым категориям должна совпадать с общим итогом, если методика предполагает полное разбиение. Отрицательное значение не должно появляться там, где процесс его не допускает.

Часть таких проверок можно выполнять автоматически ещё до обновления отчёта. Тогда BI не становится первым местом, где команда узнаёт о проблеме с данными.

При этом автоматическая проверка не заменяет смысловую. Тест может подтвердить, что сумма строк равна общему итогу, но не ответит, правильную ли дату мы выбрали для построения динамики. Для этого всё равно нужно возвращаться к бизнес-вопросу и устройству процесса.

Пользовательский сценарий тоже является тестом

Даже технически правильный отчёт может быть неудобным для работы. Поэтому финальную проверку я строю не вокруг вопроса «вам нравится дашборд?», а вокруг конкретной задачи.

Пользователь должен найти участок, который требует внимания, понять, какой показатель изменился, перейти к детализации и объяснить, на каких данных основан вывод. Если после этого ему всё равно нужна ручная выгрузка или отдельный запрос к аналитику, значит, отчёт не закрыл сценарий полностью.

На этом этапе всплывают проблемы, которые нельзя увидеть в формулах. Подпись показателя может быть понятна разработчику, но не пользователю. Цвет может выглядеть как предупреждение, хотя значение находится в норме. Детализация может открываться, но не объяснять итоговую цифру. Дата обновления может быть указана мелким текстом, и пользователь будет считать неполный период завершённым.

Я также отдельно проверяю пустые состояния и ошибки. Если данных нет, отчёт должен прямо это сообщать, а не показывать пустую страницу. Если часть источника не обновилась, лучше вывести предупреждение, чем оставить пользователя гадать, действительно ли показатель снизился.

Хорошая приёмка заканчивается не подтверждением того, что все кнопки нажимаются. Она заканчивается пониманием, что пользователь может пройти весь путь от общего сигнала до проверяемой причины и не потерять контекст по дороге.

Что я считаю достаточной проверкой отчёта

После этого проекта у меня сложился довольно простой принцип. У каждой важной цифры должно быть независимое подтверждение, понятный расчёт и возможность вернуться к исходным данным.

Перед выпуском я проверяю:

совпадает ли контрольный итог между источником, витриной и BI;
можно ли вручную воспроизвести несколько выбранных значений;
не размножаются ли записи после соединений;
одинаково ли мера ведёт себя в карточке, таблице и итоговой строке;
правильно ли работают отдельные фильтры и их сочетания;
что происходит на границах периода;
различаются ли ноль, отсутствие данных и ошибка загрузки;
видит ли пользователь дату и полноту обновления;
можно ли перейти от агрегата к деталям;
помогает ли отчёт выполнить реальную рабочую задачу.

Не все эти проверки нужно каждый раз делать вручную. Стабильные правила лучше переносить в автоматические тесты витрины и модели. Но полностью отдавать приёмку автоматике тоже не стоит: она хорошо ловит нарушение известных условий, но не замечает, что отчёт начал отвечать не на тот вопрос.

В моём кейсе результатом стала работающая отчётность по динамике доходов и контролю расхождений. Я не проводил отдельного исследования, сколько времени сэкономила такая схема проверки, поэтому не буду приводить проценты. Зато практический эффект был понятен: ошибки удавалось искать не по внешнему виду графика, а на конкретном участке пути данных.

Красивый график важен. Он помогает быстрее увидеть изменение и объяснить результат. Но сам по себе он ничего не доказывает.

Если отчёт нельзя сверить, разложить и повторить на контрольном примере, перед нами пока не аналитический инструмент, а просто убедительная картинка.

Как проверять аналитический отчёт, если красивого графика недостаточно