Техзадание на салфетке: как упростить реализацию дашборда
Правильная постановка задачи - обязательное условие для успешной реализации проекта.
Постановка задачи
Наличие грамотно составленного технического задания – обязательно условие для успешной реализации проекта автоматизации корпоративной отчетности. Оно поможет и исполнителю избежать бесконечного процесса доработок, и заказчику получить эффективный инструмент работы с нужными данными.
Однако далеко не всегда руководство компании понимает, что именно должно быть включено в ТЗ. А следовательно, на создание и согласование самого ТЗ, в котором задача будет прописана максимально точно, можно потратить несколько месяцев. Это, разумеется, будет серьезным ударом по эффективности работы.
Понятно, что нужна схема работы, которая позволит одновременно и избежать бюрократии, и избежать взаимного недовольства исполнителя и заказчика. Я уверен, что необходимо итерационно заниматься созданием конечного визуального продукта. И для этого за годы работы мною найден простой, но действенный инструмент.
Однако далеко не всегда руководство компании понимает, что именно должно быть включено в ТЗ. А следовательно, на создание и согласование самого ТЗ, в котором задача будет прописана максимально точно, можно потратить несколько месяцев. Это, разумеется, будет серьезным ударом по эффективности работы.
Понятно, что нужна схема работы, которая позволит одновременно и избежать бюрократии, и избежать взаимного недовольства исполнителя и заказчика. Я уверен, что необходимо итерационно заниматься созданием конечного визуального продукта. И для этого за годы работы мною найден простой, но действенный инструмент.
Техзадание на салфетке
Давайте признаем: требовать от клиента четко и детального ТЗ с алгоритмами всех показателей бесполезно. В лучшем случае ответ на такой запрос мы получим требование 100 метрик на одном дашборде в режиме реального времени. В худшем – предложение сделать несколько рабочих вариантов, из которых и будут выбирать нужный для доработки.
Чтобы работу можно было начать без проволочек, я использую короткую форму брифа из 6 пунктов, разделенных на две колонки. В правой содержится творческая составляющая, ассоциации: это пункты «заказчик», «выводы», «решения».
А в левой – логика построения и факты по существу: например, в каком формате будет представлен отчет, с какой периодичностью должны обновляться данные, какие ключевые количественные показатели и в каких разрезах (фильтрах, категориях) будут отображены.
Здесь также три пункта: «формат и период», «ключевые показатели» и «категории и фильтры» Именно левая часть служит основой для визуализации, поэтому поговорим о ней подробнее.
Чтобы работу можно было начать без проволочек, я использую короткую форму брифа из 6 пунктов, разделенных на две колонки. В правой содержится творческая составляющая, ассоциации: это пункты «заказчик», «выводы», «решения».
А в левой – логика построения и факты по существу: например, в каком формате будет представлен отчет, с какой периодичностью должны обновляться данные, какие ключевые количественные показатели и в каких разрезах (фильтрах, категориях) будут отображены.
Здесь также три пункта: «формат и период», «ключевые показатели» и «категории и фильтры» Именно левая часть служит основой для визуализации, поэтому поговорим о ней подробнее.
Формат и период
Формат – это первое, с чем стоит определиться. Речь идет про реальный сценарий использования аналитики, про то, как именно планируется работать с данными – смотреть на экране проектора, в BI-приложении на планшете, в Excel на ноутбуке или только на бумажных распечатках. Если это не обговорить в начале пути, вероятность того, что проект придется переделывать полностью, будет очень высока.
Период должен фиксировать, как часто отчетом будут пользоваться: раз в день, в неделю, в месяц, в квартал или в год. Понятно, что если показатель анализируется два раза в год, то тратить ресурсы даже на еженедельное его обновление смысла нет.
Период должен фиксировать, как часто отчетом будут пользоваться: раз в день, в неделю, в месяц, в квартал или в год. Понятно, что если показатель анализируется два раза в год, то тратить ресурсы даже на еженедельное его обновление смысла нет.
Ключевые показатели
Нужно уже на первом этапе выделить самые важные количественные показатели, которые должны быть отражены. Это может быть прибыль, выручка, продажи, численность работников, ФОТ и любой другой в соответствии с целью отчета. Будет ли этот показатель включать множество составляющих, можно будет определить и потом.
Категории и фильтры
В данном пункте необходимо прописать, как необходимо детализировать ключевые показатели. К примеру, топ-менеджер может потребовать фильтровать сделки по типу клиента, но в базе исходных данных такого атрибута нет. Чтобы реализовать подобный фильтр, надо будет либо заполнить это поле в источнике данных, либо сделать агрегированный промежуточный расчет.
Теперь посмотрим более детально на правую колонку. Если с параметрами, включенными в левую часть брифа, у аналитиков обычно нет сложностей, то с описанием правой части они могут возникнуть. Однако пренебрегать этим не стоит: именно в правой колонке находятся вопросы, больше всего влияющие на успех проекта.
Заказчик
Необходимо точно определить, кто будет основным пользователем, ведь универсальных дашбордов не существует. Директору по продажам и финдиректору интересны разные наборы показателей, а следовательно, и отчеты должны быть персонализированы. Особенно важно учитывать реального пользователя: мы можем готовить отчет для гендиректора, а в действительности им будет пользоваться заместитель, тогда как гендиректор будет только подписывать документы. Даже это может влиять на желаемый результат проекта.
Выводы
В этом пункте нужно прописать, какие выводы можно будет сделать, глядя в отчет: где отклонения, проблемы, задержки сроков или другие параметры. Это преобразование данных в информацию, но еще не принятие решения. Вывод логически исходит из показателей и категорий в отчете, правильно представленных на диаграммах. Например, помесячный график выручки растет вверх, а рентабельность падает. А рядом мы видим список убыточных проектов.
Решения
Понятно, что ни один дашборд в явном виде не предложит решение проблемы и не даст инструкции по дальнейшим бизнес-действиям. Его придется принимать заказчику, в том числе учитывая дополнительную внешнюю информацию или собственный опыта. И все же нужно понимать, что решения должны соотноситься с выводами.
Например, логическим решением при низкой конверсии агентских продаж будет увеличение комиссионных ставок, а при падении продаж в отдельном сегменте – увеличение рекламного бюджета.
И если такой логической связи между выводом и решением нет, то что-то в брифе пошло не так. Не нужно бояться, что заказчик подумает, что мы лезем не в свое дело. Хороший руководитель поймет, что это необходимо для того, чтобы сделать отчет полезнее. Также важно помнить, что все варианты решений просчитать нельзя, но выделить пару вариантов, чтобы связать части брифа между собой, вполне возможно.
Например, логическим решением при низкой конверсии агентских продаж будет увеличение комиссионных ставок, а при падении продаж в отдельном сегменте – увеличение рекламного бюджета.
И если такой логической связи между выводом и решением нет, то что-то в брифе пошло не так. Не нужно бояться, что заказчик подумает, что мы лезем не в свое дело. Хороший руководитель поймет, что это необходимо для того, чтобы сделать отчет полезнее. Также важно помнить, что все варианты решений просчитать нельзя, но выделить пару вариантов, чтобы связать части брифа между собой, вполне возможно.
КЕЙС: Структура себестоимости
Давайте рассмотрим применение ТЗ на салфетке на реальном примере.
В одном из крупных агрохолдингов назревал конфликт между экономистами, ежемесячно предоставляющими финдиректору огромный отчет по структуре себестоимости, факторам отклонений от норматива, детализации по каждой статье, и финдиректором, который все равно вынужден был требовать дополнительных разъяснений.
Получалось, что при наличии всех необходимых данных, сделать их основой для принятия управленческих решений было крайне трудно, если не невозможно. В процессе беседы с заказчиком мне удалось сформировать следующее техзадание на салфетке.
Заполнение первой строки таблицы прошло легко. Заказчик – финансовый директор. Формат и период – ежемесячный дашборд в Excel.
Заполняем левую часть дальше. Ключевой показатель – себестоимость 1 кг продукции, план-факт и отклонение. Этот KPI директору важно видеть по фабрикам, статьям затрат и в помесячной динамике – это вносим в ячейку «категории, фильтры».
Переходим к пункту «выводы»: заказчику необходимо понять, кто виноват в превышении норматива себестоимости. Статей затрат много, но они сводятся к двум группам: те, за которые отвечает сама фабрика, и те, которые формируют конечную себестоимость (маркетинг, логистика и прочие вспомогательные службы).
Что вносим в ячейку «решения»? На основе полученных данных финдиректор принимает решение, платить или нет премию директору фабрики. Если норматив себестоимости превышен, это плохо. Но если при этом фабрика уложилась в свои лимиты, то она получает свой бонус.
В одном из крупных агрохолдингов назревал конфликт между экономистами, ежемесячно предоставляющими финдиректору огромный отчет по структуре себестоимости, факторам отклонений от норматива, детализации по каждой статье, и финдиректором, который все равно вынужден был требовать дополнительных разъяснений.
Получалось, что при наличии всех необходимых данных, сделать их основой для принятия управленческих решений было крайне трудно, если не невозможно. В процессе беседы с заказчиком мне удалось сформировать следующее техзадание на салфетке.
Заполнение первой строки таблицы прошло легко. Заказчик – финансовый директор. Формат и период – ежемесячный дашборд в Excel.
Заполняем левую часть дальше. Ключевой показатель – себестоимость 1 кг продукции, план-факт и отклонение. Этот KPI директору важно видеть по фабрикам, статьям затрат и в помесячной динамике – это вносим в ячейку «категории, фильтры».
Переходим к пункту «выводы»: заказчику необходимо понять, кто виноват в превышении норматива себестоимости. Статей затрат много, но они сводятся к двум группам: те, за которые отвечает сама фабрика, и те, которые формируют конечную себестоимость (маркетинг, логистика и прочие вспомогательные службы).
Что вносим в ячейку «решения»? На основе полученных данных финдиректор принимает решение, платить или нет премию директору фабрики. Если норматив себестоимости превышен, это плохо. Но если при этом фабрика уложилась в свои лимиты, то она получает свой бонус.
Результатом ТЗ на салфетке стало то, что мы получили возможность сфокусироваться на самом важном и не утонуть в согласовании второстепенных деталей. Уже можно нарисовать эскизы для будущей визуализации – как бы на «обороте салфетки» – и сразу показать их заказчику.
Для данного кейса мною были предложены три варианта:
Для данного кейса мною были предложены три варианта:
- горизонтальная водопадная диаграмма, на которой мы видим промежуточную производственную себестоимость и итоговую с учетом всех сопутствующих расходов;
- рейтинг фабрик по себестоимости;
- помесячная динамика плана и факта.
С этим уже можно работать. И даже если итоговый дизайн будет немного отличаться от эскиза, его содержание останется тем же. А ТЗ на салфетке ускорило и упростило реализацию проекта и помогло найти общий язык с заказчиком.
Читайте также
Подпишись на рассылку и получи в подарок «Каталог лучших отраслевых дашбордов»!
Хочешь получать актуальные статьи о визуализации данных?
