KungFu Аналитика. Как автоматизировать и визуализировать показатели эффективности

Хороший инструмент мониторинга показателей – как тест на беременность: быстрый, простой и точный. К такому выводу я пришёл за время работы с метриками бизнесов в разных отраслях: оптовые продажи, энергетика, IT.

Сегодня в KungFu-блоге для аналитиков новый автор, но тема, которую он раскрывает, возникает постоянно: подходы к проектированию приборной панели, подводные камни. Статья будет полезна тем, кто впервые столкнулся с подобной задачей, так и тем, для кого график баров – это не только расписание питейных заведений.

Разработка продукта состоит из двух частей, с долей условности назовём их:

1) Backend – задний двор решения. Пользователь нечасто здесь появляется, большая часть содержимого скрыта. Здесь находятся справочники, таблицы, сценарии.

2) Frontend – фасад или та самая приборная панель, с которой взаимодействует пользователь. Это виджеты, дашборды.

Задняя часть всегда более-менее стандартна. У показателей есть фактические значения – их нужно считать (сценарий) или вводить (справочник) и хранить (таблица). В 95% случаев присутствуют плановые значения – им тоже нужен ввод и хранение.

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

По лицевой части неопределенности больше:

Эти вопросы можно задать представителям Заказчика или фокус-группе напрямую. Возможно, даже будут получены ответы. Но если бы всё было так просто, профессия бизнес-аналитика была бы не нужна.

Минутка очевидного, о котором забывают. Чтобы спроектировать востребованный продукт, выясните, КТО будет им пользоваться, КАК он планирует это делать и ЗАЧЕМ, то есть какие задачи предполагается решать.

На протяжении последних трёх лет средний возраст топ-менеджеров в России практически не менялся - это 40-45 лет, и мужчин здесь на 10-14% больше. Руководители среднего звена по статистике на пару лет моложе, и численный перевес в этой категории на стороне женщин.

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

Ещё немного статистики. 63,3% руководителей предпочитают контролировать ключевые этапы процесса, 24% –­ контролируют весь процесс, 12,7% - итоговый результат. Это намекает, что полезно выделять контрольные точки процесса и проводить в них замеры. Например, в процессе продаж целесообразно использовать индикаторы:

· получено запросов,

· отправлено предложений,

· принято предложений,

· совершено поставок,

· получено оплаты.

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

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

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

Достоверность данных – важнейшая ценность нашего решения. Поэтому каждая формула, каждый алгоритм должен быть выверен, как удар Тайгера Вудса.

Пример из практики. Заказчик хочет контролировать средний срок обработки заявок. Норматив составляет 10 дней. Неопытный аналитик воскликнет: «Легкотня! Берем заявки за период, считаем срок по каждой, складываем, делим на количество заявок, сравниваем с нормативом».

Но мы-то с вами зададим минимум 3 вопроса:

1) Какие заявки попадают в выборку: поступившие за период, обработанные за период, находившиеся в работе за период?

2) Средний срок – это среднее арифметическое или медиана?

3) 10 дней – это календарных или рабочих?

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

Порой возникает искушение дать пользователям возможность самим определять, как визуализировать те или иные показатели, выбирая из набора диаграмм. Такой подход имеет право на жизнь, но следует помнить, для КОГО и ЗАЧЕМ мы делаем продукт. Есть ли у пользователя потребность и желание играться с настройками?

Для визуализации набора чисел подходят таблицы:

Для сравнения нескольких величин, являющихся частью целого – круговые и кольцевые диаграммы:

Для сложных сравнений – столбчатые диаграммы:

Для показа тенденций – линейные диаграммы:

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

Параметры решения, обязательные к проработке:

1. Периоды. С какими отчетными периодами работает Заказчик: месяц, квартал, декада, семестр, год?

2. Разрезы. Как дробится показатель: по организационной структуре (филиалы, отделы, сотрудники), по рынкам сбыта (страны, отрасли, клиенты), по продуктовой структуре?

3. Перспективы развития решения. Предполагается ли доработка продукта или масштабирование? Нужна ли продукту гибкость или он должен решать определенный набор задач?

4. Персональные потребности. Важно не упустить особенности Заказчика. Например, помощник передает дашборды с показателями руководителю в распечатанном виде. В этом случае придется предусмотреть кнопку «Печать», а формат дашборда привести в соответствие формату и размеру бумаги, на которой он будет печататься.

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

И с другой стороны ещё один момент: важно помнить, что вы не несёте ответственность за качество вносимых данных и результат. Вы создаёте удобный тест на беременность, а за количество полосок отвечает кто-то другой.

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