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

Можно сравнить разработку BI-дэшбордов с созданием презентаций.

Какими минимальными знаниями должен обладать человек, чтобы создать свою первую презентацию? Он должен хотя бы чуть-чуть разбираться в информации, которую хочет рассказать и владеть инструментом, например, Microsoft Power Point. А создание красивых и понятных презентаций — целое искусство, которому люди учатся годами и всю жизнь совершенствуют свои навыки, редко достигая совершенства.

Какими минимальными знаниями должен обладать человек, чтобы создать свой первый BI-дэшборд? Иметь данные, например, файл Excel, понимать эти данные и уметь пользоваться BI-инструментом, например, Pentaho.

Давайте рассмотрим эти шаги подробнее.

Какие именно шаги по разработке BI-решения нужно выполнить?

Совсем необязательно, что нам потребуется команда из 8ми человек  для разработки BI-дэшборда— эти роли может совмещать в себе один или несколько человек. Главное, чтобы были выполнены все основные по разработке BI-приложения.

ответит на вопросы пользователей

Специалист поддержки 

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

Тестировщик 

подготовит нам итоговый продукт, реализует макет дизайнера, и сделает автоматический расчет нужных показателей

BI-разработчик 

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

Дизайнер

поможет найти нужные взаимосвязи и ответить на вопросы при помощи данных, расскажет какие показатели нужно выводить в интерфейс приложения

Аналитик 

это человек, который поможет настроить все нужные интеграционные потоки (ETL, ELT), разработать структуру данных, провести их очистку и подготовку к использованию

Инженер данных 

он отвечает за планирование работ и достижение этих планов.

Менеджер проекта 

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

Для создания такого решения нам понадобится команда:

Предположим мы хотим создать BI-приложение, в котором сможем отслеживать данные о здоровье (физические упражнения, диета и режим сна), и использовать эту информацию для принятия решений — как поменять режим и улучшить здоровье.

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

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

Аналитик 

Менеджер должен оценить верхнеуровневый объем работ, понять стоимость и длительность проекта. А также оценить — сможет ли команда выполнить задачу своими силами, или придется привлекать дополнительных специалистов.

Менеджер проекта 

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

На этом этапе к проекту по разработке подключаются следующие роли:

Если мы соединим данные в едином месте и получим интерфейс ввода данных настроении, то получим график взаимозависимостей ключевых показателей: качество сна, калории + белки, жиры и углеводы, физическая активность, вес, настроение.
Анализируя тренды 1 раз в неделю, мы сможем понимать — какие факторы влияют на наши ключевые цели: вес и настроение.
Идеальным решением будет, если на BI-дэшборд будет выводиться рекомендации: нужно ли что-то менять и на какие показатели нужно обратить особенное внимание?

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

Если вес растет, то мы меняем диету и увеличиваем физическую активность. Если вес в пределах нормы, то не предпринимаем действий.

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

Мы хотим понять, как количество часов сна, физическая активность и питание влияют на наш вес и настроение.

Попробуем определить цель нашего BI-дэшборда из примера:

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

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

Диеты у профессионального спортсмена и офисного работника разные, и ключевые показатели (KPI) тоже разные. Одному важно есть сладкое не каждый день и пить меньше кофе. А второму нужно считать распределение белков, жиров и углеводов, количество электролитов и других параметров — не доберешь магния и сведет мышцы во время важного соревнования.

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

Анализирует нужные интеграционные потоки (ETL, ELT), продумывает структуру данных, профилирует, чистит данные и готовит витрины для BI-дэшборда.

Инженер данных  

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

Менеджер проекта 

Сможет ответить на вопрос: "Решают ли имеющиеся данные поставленную задачу?" или предложит дополнительные источники данных для поиска ответов.

На втором шаге к проекту по разработке подключаются следующие роли:

Чтобы быстро проверить свою гипотезу и не потратить силы в пустую мы можем создать прототип «на коленке». Например, мы можем выгрузить сэмплы данных и нарисовать макет приложения, чтобы оценить — сможем ли мы решить нашу задачу? Такой прототип можно собрать даже в Excel, настроить графики и ключевые показатели. Если данные отвечают на вопросы пользователя — это сигнал идти дальше, если не отвечают — повод задуматься.

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

Основная ценность любого аналитического решения — данные. Мы можем использовать самый мощный BI-инструмент, взять на работу самых умных и дорогих аналитиков, но если на входе нет нужных данных, то мы не получим качественных решений. Именно поэтому принимать решение — разрабатывать BI-дэшборд или нет — нужно на этапе оценки данных.

Мы определили, что для нашего BI-дэшборда нужны следующие данные:

Для начала мы должны ответить себе на следующие вопросы:

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

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

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

Менеджер проекта

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

Этот человек хорошо понимает особенности BI-инструментов. Он будет разрабатывать итоговое приложение и сможет оценить — какие инструменты позволят ему решить задачу быстрее.

BI-разработчик  

Для лучшего понимания критериев выбора BI-инструмента советуем посмотреть видео в дополнительных материалах к этому лонгриду.

На рынке существуют сотни BI-инструментов — opensource, бесплатных, коммерческих и облачных. Выбор конкретного инструмента — вопрос личных предпочтений разработчиков, корпоративных стандартов и условий.

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

Но мы не будем выбирать конкретный инструмент, а просто опишем критерии выбора.

Назначает нужные встречи, контролирует сроки, мотивирует команду и приносит пиццу :)

Менеджер проекта

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

Заказчик/менеджер продукта

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

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

BI-разработчик

Готовит макеты, выбирает шрифты и цветовые схемы и от него зависит на сколько итоговый продукт будет удобным в использовании

Дизайнер  

Разработать хорошую компоновку — сложная задача. Для того, чтобы выполнить ее потребуется несколько итераций. Для работы на этом этапе можно использовать подходы скетчинга и прототипирования. Можно создавать макеты (прототипы) страницы на бумаге, на стикерах, в досках Miro и обсуждать эти макеты с командой разработки и ключевыми заказчиками. Это позволит создать конечный продукты быстрее и с лучшим качеством.

Финальный шаг разработки BI-дэшборда — компоновка всех визуализаций на странице.

Хороший BI-дэшборд — это не просто набор визуализаций, а история, которую вы рассказываете пользователю с помощью данных.

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

Будет хорошо, если вы отобразите на BI-дэшборде следующие элементы: тренды и показатели, KPI и рекомендации к действию.

Например, на нашем BI-дэшборде могут быть выведены:

• тренды: график физической активности, диаграмма КБЖУ, диаграмма сна
• KPI — вес, и индикатор достижения цели
• Рекомендации — на какие показатели нужно обратить внимание, чтобы достичь цели

3. Компоновка элементов на странице

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

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

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

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

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

Рассмотрим три самых популярных типа визуализации:

2. Выбор визуализаций для данных

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

Агрегировать исходные данные мы можем по разным правилам, например:

• Сумма — мы можем посчитать количество калорий, которое было потрачено за неделю. Это будет полезно, если мы смотрим динамику на длительном отрезке, например — год.
• Среднее — можем посчитать среднее количество калорий за неделю, это позволит оценить краткосрочную динамику.
• Минимум — можем оценить самые пассивные недели
• Максимум — или наоборот, самые активные
• Количество — можем посчитать количество дней в неделю, когда мы достигли цели подвижности, или наоборот не достигли.

Выбор способа агрегации — это тоже важная часть подготовки и анализа данных.

На этом этапе мы загружаем в BI-инструмент данные из источника — из базы, или файла Excel. Наши данные уже очищены и подготовлены для BI-дэшборда, но это не значит, что этап работы с данными закончен.

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

Меры — это значения данных, которые интересуют пользователя. А измерения — категории по которым измеряются значения данных.

Например, у нас есть данные по физической активности — количество калорий, потраченных человеком за день. В качестве меры мы можем выбрать — калории, а в качестве измерения — дату.

1. Подготовка и анализ данных

У нас есть постановка цели и задачи, есть данные и есть BI-инструмент. Мы можем приступить к разработке BI-дэшборда.

Разработка BI-дэшборда состоит из трех основных этапов: подготовка и анализ данных, выбор визуализаций для данных и разработка самого BI-дэшборда (компоновка элементов на странице).

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

Специалист поддержки

Устраняет ошибки в работе приложения, следит за производительностью работы BI-дэшборда, проводит оптимизацию и устраняет баги

BI-разработчик

Дорабатывает дизайн, меняет функциональные блоки и элементы, если по итогам пользовательского тестирования они оказались неудобными

Организует необходимые встречи для сбора обратной связи и планирует ресурсы команды на доработку решения. При необходимости расширяет команду.

Менеджер проекта

Принимает решения, какие из задач на доработку брать в работу в первую очередь, какие могут подождать, а какие не требуется создавать в продукте никогда.

Заказчик/менеджер продукта

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

Аналитик

Настраивает механизмы контроля качества данных и панели мониторинга, чтобы вовремя узнавать о проблемах

Инженер данных

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

Тестировщик  

Наша команда разработала BI-дэшборд. Мы провели с этим проектом много часов, и он нам стал «родным" — мы знаем наизусть каждую кнопку, понимаем, как этим пользоваться и считаем свое детище идеальным. Даже если мы очень захотим взглянуть на свой продукт свежим взглядом — у нас не получится.

Но новые пользователи увидят наш BI-дэшборд впервые и то, что нам кажется очевидным, для большинства может оказаться непонятным. Чтобы упросить работу с нашим BI-дэшбордом, можно сделать следующие действия:

• Провести быстрое UX-исследование. Можно сесть рядом со своим другом или коллегой, когда он в первый раз работает с нашим дэшбордом. Главное ничего не комментировать и не объяснять, а просто смотреть — как человек справляется с этим кейсом. И фиксировать для себя действия другого человека: на что обратил внимание, на что кликнул в первую очередь, что вызвало затруднения. Такое наблюдение поможет сформулировать гипотезы — что следует изменить в интерфейсе и какие функции добавить\убрать.

• Сбор статистики. Гипотезы по итогам UX-исследования можно сформулировать в виде анкеты и отправить первым пользователям. Это поможет собрать статистику — какие моменты стоит исправить, потому что они вызывают затруднения у большинства, а какие-то вопросы непонятны только нескольким пользователям — это можно решать через поддержку.

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

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

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

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

Специалист поддержки  

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

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

Чтобы не растерять всю аудиторию важно развивать и дорабатывать наш продукт.

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

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

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

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

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

Если на дэшборд вывести слишком много информации, то пользователям сложно будет найти нужные данные и принять решение. Цель BI-дэшбордов — ускорить анализ и понимание информации. Частая причина перегруженных дэшбордов — плохое понимание целей, задач и сценариев использования данных. В таком случае разработчики стараются вывести на панель больше информации на случай «авось пригодятся».

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

Избегая этих распространенных ошибок, вы можете создать эффективный и удобный для пользователя BI-дэшборд

5 ошибок джуна при разработке BI-дэшбордов