В рамках этого урока мы рассмотрим основные правила формирования требований к дэшбордам и основные этапы создания дэшбордов. Еще раз напомню, дэшборд — это информационная панель, которая визуально отображает наиболее значимую информацию для пользователя, на экране. С точки зрения пользователя дэшборды визуализируют очень важную, самую важную информацию, группируют информацию, но с точки зрения бизнес-логики и позволяют, это тоже очень важная возможность дэшбордов, позволяют интерактивно уточнять детали. Предположим, аналитик видит какой-то важный ключевой показатель, ему интересно почему он сейчас именно такой, например, объем продаж. Он должен иметь возможность провалиться до деталей и понять, например, какие группы товаров сейчас обеспечивают такой объем продаж. Очень важно, для разработчика, учитывать следующий момент. Визуальная панель — это аналитическая панель, она делается для пользователя и поэтому прежде чем приступать к разработке дэшборда обязательно нужно поговорить с заказчиком, поговорить с пользователем и определить, что должно находиться на этой панели. Те вопросы, которые я вам предложу они существенно упрощают процедуру сбора требований, но это, по крайней мере, минимум тех вопросов, которые разработчик должен задать и получить на них ответы. Итак. Какие вопросы должен разработчик дэшборда обязательно поставить перед заказчиком: кто будет пользоваться этим приложением, представителем каких бизнес доменов они бывают, например, это представители отдела продаж или представители бухгалтерии, какие конкретно должностные обязанности пользователей требуют информационной поддержки, с какой периодичностью они обращаются за информационной поддержкой для принятия управленческих решений и в настоящее время они же как-то принимают управленческие решения, какими источниками в настоящий момент они пользуются. Ответы на эти вопросы позволят, и, еще раз проинтервьюировать заказчиков и задать вопрос, а не забыли ли они что-то обозначить, и разработчику, самому понять, что должно появиться на дэшборде. Еще группа вопросов, которые, как правило, задают профессиональные разработчики — это какие должностные обязанности пользователей, какие связанные цели в компании, с теми целями, которые получили отражение на дэшборде. Например, бизнес пользователи просят вывести на аналитическую панель показатель увеличения продаж за последнюю неделю. Хорошо, продажи увеличились, но дальше, тому же самому заказчику станет интересно, а за счет чего они увеличились, то ли были повышены цены, то ли увеличилось количество посетителей, например, магазина. Это и есть пример связанных целей, которые, скорее всего, тоже пользователю потребуются при анализе ситуации в компании. Здесь еще раз мы видим пункт о уточнении источников информации, которые содержат необходимую для агрегирования данных информацию, какая информация из этих источников должна извлекаться, нам не все массивы данных нужны, а для получения и расчета определенных показателей только часть информации, какие производные показатели нужно рассчитывать, и обычно рассчитываются в компании, соответственно, их, как правило, тоже нужно помещать в эти дэшборды, и как часто обращаются, в настоящий момент, управленцы к тем источникам информации, из которых эта информация берется. Таким образом неявно прозвучала, давайте мы еще раз про это скажем, по существу два крупных этапа, два таких глобальных этапа есть в любой процедуре сбора требований. Это анкетирование, а затем уточнение вопросов и ряда деталей у заказчиков. Как правило, формирование требований — это такая интерактивная процедура. Какие основные данные выводятся на дэшборды? Это количественные данные, это некоторые индикаторы и, не количественные данные. Несмотря на очевидность представления количественных данных, как правило, на диаграммах отражаются количественные данные, здесь важно обратить внимание на следующий момент — это тоже зависит от пользователей, то ли данные будут отражаться сами по себе, например, объемы продаж, то ли эти данные должны сравниваться с какими-то другими связанными показателями, например, объем продаж за предыдущий период. Следующая группа показателей, которые появляются на дэшборде, это индикаторы. Как ни странно, такие простые вещи, как сигнал красным цветом о том, что какой-то показатель ниже нормы очень часто используются в дэшбордах и их цель именно обратить внимание на состояние дел. Семафор — это такой классический пример индикатора, который сигналит как обстоят дела с тем или другим показателем, увидев такой показатель, например, сигнал о том, что где-то что-то не очень хорошо, пользователь тогда переключается на другую панель, может быть даже вашего дэшборда, и анализирует более детально, что случилось. И третья, менее очевидная, группа показателей, которые очень часто помещаются на дэшборд, это не количественные показатели, это, например, топ-5, самых успешных менеджеров, или, наоборот, топ-5 самых, сейчас, слабо работающих менеджеров по продажам. Это могут быть какие-то расписания и так далее, на слайде представлены варианты неколичественных вариантов представления, неколичественных данных. Еще на один момент хочется обратить внимание, дэшборды, как уже неоднократно говорилось, делаются для того, чтобы управленцу проще было принимать решения и они делаются для того, чтобы агрегированные показатели в более комфортном варианте представлялись и позволяли принимать обоснованные какие-то решения. Соответственно, очень важно как, чисто внешне, выглядят такие дэшборды, но при этом очень важным моментом является следующее. Нельзя перегружать цветом, нельзя перегружать деталями вот эти аналитические отчеты. Я знаю примеры крупных компаний, в которых просто, например, цвет который можно использовать в таких дэшбордах, заранее оговаривается, регламентирован и, например, разработчик, он может просто выбрать один из вариантов цветовой гаммы из уже заранее утвержденных. На следующем слайде приведены основные ошибки, которые делаются разработчиками, обычно начинающим разработчиками, при создании дэшбордов, как правило, они связаны с проблемами визуализации, с неправильным использованием, например, типов диаграммы, мы про это говорили в предыдущих курсах, с плохой организацией информации. И здесь очень важно обсуждать с пользователем, где пользователю комфортно, например, наличие того или другого показателя, для разработчиков это иногда странно, но очень часто представители бизнеса говорят, а мы привыкли чтобы этот показатель был в левом верхнем углу, а не в правом нижнем, как вы сделали. И в заключение, немножко тоже упрощаем, но на данном этапе этого вполне достаточно, приведу этапы построения дэшборда. Итак, на первом шаге необходимо определить перечень тех показателей, которые будут помещены на аналитическую панель, определить какие срезы, временные, категориальные нужно будет просматривать пользователю, например, объем продаж в разрезе районов, в разрезе товаров. На следующем шаге определяется архитектура отчета, про это будет подробно говорится в следующих уроках. Абсолютно необходимо построить макет отчета, собственно, про что я только что говорила, где располагаются те или другие элементы этого аналитического отчета, в отчет добавляются диаграммы и таблицы, добавляются срезы и срезы подключаются к диаграммам и таблицам. Итак, в рамках этого урока, мы просмотрели этапы формирования требований со стороны бизнеса дэшборду, очень упрощенно, но очень важные моменты мы перечислили и этапы, собственно, построения самого дэшборда. Далее можно переходить уже к техническим аспектам создания дэшбордов, этому и будут посвящены дальнейшие уроки нашего курса.
