Аудит системы Power BI

1.Общая информация

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

В отчет входит перечень выполненных работ с описанием выявленных ошибок или недоработок и рекомендаций по их исправлению.

2.Когда нужен?

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

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

3.Что включает в себя?

Внутренний аудит решения на Power BI состоит из:

1. Анализ модели данных:

Анализ подключения к источникам данных,
Корректность построения модели данных, проверка на избыточный функционал,
Быстродействие модели,

2. Оценку вычисляемых элементов в модели:

Проверка на корректность/достаточность/избыточность вычисляемых мер и столбцов,
Проверка корректности вычисления параметров «What if»,
Проверка на возможность использования модели для интеграции с системой управления доступом (Row Level Security),
Проверка быстродействия,

3. Оценку дашбордов:

Анализ дизайна и интерфейса (UI),
Анализ достаточности используемых визуальных элементов,
Анализ сценариев использования дашбордов,
Проверка корректности настройки оповещений пользователя о событиях и конфиденциальности данных (sensitivity label’s и data alert’s),

Внешний аудит решения на Power BI состоит из:

Анализ метрик использования дашбордов,
Анализ достаточности знаний у пользователей,
Анализ возможностей интеграции с другими программными продуктами,

4.Подробная информация про каждый этап

N	Вопрос	Работы	Структура вывода	Примеры / Рекомендации
Блок 1. Внутренний аудит
1)	Анализ модели данных
1.	Анализ подключения к источникам данных.	Поиск неиспользуемых или избыточных источников данных, оценка скорости загрузки файлов в модель.	Нужно сократить или увеличить количество источников данных для повышения быстродействия и корректности вычислений в модели.	При одновременном использовании более 10 источников загрузка данных может значительно замедлять модель.
2.	Корректность построения модели данных, проверка на избыточный функционал.	Оценка построения связей внутри модели, корректности их типов и настройки.	«Принцип построения модели корректный» или «Выявлены некорректные связи и излишние связи: список связей и причины»	Необходимо исправить следующее: 1) Перенастроить связи, 2) Использовать другие связи, 3) Отказаться от активных связей и использовать функции типа USERELATIONSHIP и т.д.
3.	Быстродействие модели данных.	Проверка на использование основных способов оптимизации.	О необходимости доработки источников данных, скрытия столбцов, создания дополнительных витрин данных, изменения типов данных и т.д.	При разделении столбца ДАТА/ВРЕМЯ на два столбца ДАТА и ВРЕМЯ быстродействие модели увеличивается в полтора раза.
2)	Оценка вычисляемых элементов в модели
1.	Проверка на корректность/достаточность/избыточность вычисляемых мер и столбцов.	Оценка используемых операторов в модели, проверка корректности их использования.	Функции меры и столбцов в модели используются корректно / некорректно, Необходимо исправить следующее: 1) Использовать операторы другого типа, 2) Заменить вычисляемые столбцы на меры и т.д.	Для вычисления суммы по столбцу клиент использовал функции SUMX, когда мог бы воспользоваться обычной функцией SUM, что замедлило модель в 2 раза.
2.	Проверка корректности вычисления параметров «What if».	Проверка формул на корректность использования параметра, Проверка на соответствие формул основному смыслу дашборда.	Параметры what if в модели используются корректно / некорректно, Необходимо изменить формулы использования параметра, т. к. они не соответствуют логике модели.
3.	Проверка на возможность использования модели для интеграции с системой управления доступом (Row Level Security).	Проверка формул, данных и логики построения модели на возможность использования RLS.	В модели может ограничиваться доступ пользователю по значению «Masha», в базе данных же встречаются две формулировки «Masha» и «Maha»	Большинство формул DAX не поддерживают стабильную работу при использовании режима DirectQuery, поэтому клиенту будет необходимо перейти на другой тип подключения данных.
4.	Проверка быстродействия.	Оценка быстродействия вычисляемых элементов, выделение основных проблем, подготовка рекомендаций.	Необходимо изменить формулу или визуальный элемент, т.к. их использование значительно замедляет модель	Применение некоторых визуальных элементов в комбинации с мерами может существенно замедлять модель.
3)	Оценка дашбордов и их использования
1	Анализ дизайна и интерфейса (UI).	Проверка дашборда на считываемость информации, на соответствие уровню пользователя и т.д.	Необходимо изменить визуальный ряд, стиль, улучшить интерфейс. Подготовка предложений по изменению.	Нечитаемые дашборды, некорректно расположенные фильтры и прочее.
2	Анализ сценариев использования.	Построение «Пути пользователя» по дашборду, оценка критических мест и определение рекомендаций по их устранению.	По данному дашборду необходимо скорректировать визуальный ряд / фильтры / срезы.	На дашбордах может быть множество лишних элементов, которые никогда не используются пользователями.
3	Анализ достаточности используемых визуальных элементов,	Проверка соответствия темы дашбордов и его визуальных элементов,	На дашборде может быть слишком много или мало визуальных элементов, что может затруднять пользователям получать ответы на свои вопросы	Дашборд должен отвечать на вопрос «Сколько продали», и в тоже время не содержит разделения на продажи со скидкой/без скидки – возможно стоит добавить pie с подобным измерением
4	Проверка корректности настройки оповещений пользователя о событиях и конфиденциальности данных (sensitivity label’s и data alert’s).	Проверка корректности настройки data alert’s и sensitivity label’s.	«Настройка корректна» или «Выявлены некорректны срабатывания алертов из-за многочисленных ошибок в формулах»	Данные функции при неправильной настройке могут давать сбои.
Блок 2. Внешний аудит
1	Анализ метрик использования дашбордов.	Оценка частоты использования дашборда, выводы по актуальности тех или иных моделей.	Список используемых и не используемых дашбордов.	У клиента было 10 дашбордов, 2 из них использовались постоянно, 5 использовались раз в день и 3 вовсе не использовались, последние можно удалить и перестать поддерживать.
2	Анализ достаточности знаний у пользователей.	Проведение встреч с пользователями, оценка их знаний программы и ее возможностей.	Необходимо провести обучение.	Пользователи могут не знать базовых функций «сброс фильтров» или как сделать выгрузку данных.
3	Анализ возможностей интеграции с другими программными продуктами.	Оценка основного стека программ компании, определение возможностей интеграций с Power BI.	Вы можете отобразить свои дашборды в MS Teams.	Использование комбинации MS Teams + Power BI значительно упростила рабочий процесс компании.