Как создать дашборд: пошаговый план

КЛЮЧЕВОЙ ФАКТОР УСПЕШНОГО ДАШБОРДА

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

Ключевой критерий успешности создания дашборда – это оценка целесообразности на каждом этапе подготовки.

ЭТАПЫ СОЗДАНИЯ ДАШБОРДОВ

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

Итак, какие же этапы мы выделяем:

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

2. Определение основных "болей" заказчика. Заказчик не просто так к нам обратился с идеей создать дашборд. Он явно руководствовался какой-то проблемой, задачей. Важно выяснить это.

3. Определение основных целей. Вытекает из предыдущего пункта - здесь, по сути, мы даём ответ на вопрос, а как мы закроем "боли" и проблемы заказчика?

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

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

6. Разработка дашбордов. Самый простой и понятный пункт.

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

8. Тестирование и получение обратной связи.

9. Финальные доработки. Как правило небольшие косметические правки, которые завершают процесс создания дашбордов.

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

КТО ЗАКАЗЧИКИ ДАШБОРДОВ?

Самым первым этапом в нашей статье "как сделать дашборд?" мы ставим именно определение заказчиков. Ни цели, ни "боли" и проблема, а именно заказчиков. Почему же?

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

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

Приведём пример, когда этот этап пропускают или пускают на самотёк.
Пришёл клиент, собственник бизнеса, который хочет оцифровать свой бизнес на маркетплейсах. Он знает про такой потрясающий инструмент как дашборд и хочет его внедрить у себя в компании. Его цель - выводить на дашборды ключевые показатели работы на маркетплейсах. После внедрения оказывается, что дашборд не отвечает запросу клиента. Почему же?
Дело в том, что наш собственник из примера не является реальным заказчиком дашборда. Он не будет каждый день за ним работать и принимать решения, потому что это не его задача. У него есть сотрудник, который отвечает за маркетплейсы. И вот именно с ним, с этим реальным заказчиком, стоило бы и познакомиться. Тогда мы бы поняли, что та же цель - "выводить ключевые показатели работы на маркетплейсах" - реализуется по-другому и ориентируется под ежедневное использование реальным заказчиком. А если мы закроем "боль" реального заказчика, то и сам клиент будет доволен, ведь его сотрудники повысили эффективность работы с помощью дашбордов.

КАКИЕ КЛЮЧЕВЫЕ "БОЛИ" ЗАКАЗЧИКОВ?

Это второй ключевой вопрос, ответ на который важно получить при построении дашбордов.

Здесь можем порекомендовать пообщаться с реальным заказчиком с глазу на глаз. В общем, дать ему слово и попросить его показать, а что он делает сейчас? Как сейчас собирает отчеты? Что формируется долго, что быстро? В каком формате он привык работать?

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

ОПРЕДЕЛЯЕМ ОСНОВНЫЕ ЦЕЛИ

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

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

Следовательно, на этом этапе мы детально прописываем то, как будет выглядеть дашборд, в каком виде лучше показывать информацию (в виде таблиц или графиков) и достаточно ли будет одного дашборда? Может быть стоит задачу разбить на 2 подзадачи - 2 дашборда. То есть это декомпозиция задач, которые будут закрывать основные проблемы заказчика.

Как правило, на данном этапе становится понятным количество дашбордов, необходимых к построению и реализации для заказчика.

КАКИЕ ИСТОЧНИКИ ДАННЫХ ИСПОЛЬЗОВАТЬ?

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

Как правило, это стандартные базы данных SQL, Google таблицы (куда без них), API запросы к веб-сервисам и иное.

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

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

Абсолютно нормально часть малозначимых показателей забирать из Эксель или Гугл таблиц. В этом нет ничего плохого, честно!

ЭСКИЗЫ - ЗАКАЗЧИКУ!

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

Как правило, эскизы накидывают в Figma, Power Point, Miro или показывают на примере уже реализованных дашбордов. Главная задача - быстро и довольно схематично показать суть будущих дашбордов.

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

СОЗДАНИЕ И РАЗРАБОТКА ДАШБОРДОВ

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

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

Думаю, здесь каждый сам выбирает по своему усмотрению и по многим другим факторам, в каком инструменте лучше делать дашборды. Лишь перечислим основные из них:
1. Tableau
2. Microsoft Power BI
3. Google Data Studio
4. QlikView
5. Excel или Google Sheets (Гугл таблицы)
6. Яндекс ДатаЛенс (Yandex DataLens)

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

Соответственно, этап разработки самый трудозатратный, но при хорошей подготовке на предыдущих этапах, вы сможете сэкономить много времени.

УТВЕРЖДЕНИЕ МЕТРИК

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

Несколько полезных пунктов:
1. Создайте справку / инструкцию / отдельный дашборд про алгоритм расчета основных метрик;
2. Сообщите заказчику, где находится эта справка / инструкция и проверьте, что он легко в неё может попасть;
3. Опишите методику расчета метрик на понятном для заказчика языке (ни в комем случае не формулами языка BI системы);
4. Укажите по основным метрикам, из каких источников берутся данные и как они фильтруются (если таковые фильтры есть).

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

Почему этот этап мы поместили после разработки дашбордов? Ведь очень часто рекомендуют сначала прописывать метрики, а уже только потом приступать к созданию дашбордов.

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

ТЕСТ И ФИДБЭК

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

ФИНИШНАЯ ПРЯМАЯ

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

После внесения правок, сдаёте дашборды заказчикам.
И, если вы выполнили все пункты, то заказчики скорее всего останутся довольны и захотят дальше внедрять новые дашборды / вносить доработки.

Поздравляем вас, дашборд собран!