Что учесть при разработке требований к дашборду, от чего зависит состав и содержимое ТЗ к средству аналитики данных и управленческой отчетности, и почему такой системный анализ непосредственно связан с дата-инженерией.
Пользовательские требования к дашборду и варианты решений
За прошедший год в моей профессиональной жизни было довольно много задач, связанных с инженерией и анализом данных. В частности, построение дашбордов — аналитических отчетов и панелей, которые выводят ключевые значения метрик, нужных стейкхолдеру для принятия решений. Разумеется, в зависимости от роли пользователя дашборда, набор выводимых метрик и виде различных графиков, диаграмм, таблиц и пр., будет меняться. Например, руководителю компании нужны совершенно иные метрики, чем операционному менеджеру. Более того, у них совершенно разный диапазон данных, различные сценарии агрегаций и фильтраций.
Чтобы дашборд был эффективным и действительно помогал делать правильные выводы о трендах в случившихся фактах и/или прогнозировать будущие ситуации, он должен соответствовать потребностям пользователей и бизнес-целям. Для этого необходимо определить и задокументировать требования к дашборду, как к любому программному продукту. Эти требования могут быть функциональными и нефункциональными, но в любом случае они, прежде всего основаны на следующих факторах:
- пользовательские потребности и бизнес-задачи;
- технические возможности и ограничения.
С точки зрения пользовательских потребностей и бизнес-задач, надо сперва определить целевую аудиторию – кто именно будет пользоваться дашбордом. Определение конечных пользователей – первый шаг в выявлении требований к отчету и аналитической панели. Как уже было отмечено выше, топ-менеджеру нужны стратегические показатели эффективности компании в целом, т.е. те, которые непосредственно связаны с деньгами, клиентами и продуктовой линейкой. Причем период представления этих данных, т.е. выборка, должна быть достаточно большой, а сами данные должны быть агрегированы, чтобы по ним можно было делать стратегические выводы. Например, квартальная динамика изменения среднего LTV (Live Time Value) по частным и корпоративным клиентам за год. Операционному менеджеру, ответственному за отдельные процессы, продукты или организационные единицы, обычно нужны более детализированные данные на менее пролонгированных диапазонах. Например, месячная доходность от каждого продукта по клиентам с различными статусами лояльности. Здесь также стоит проработать вопросы безопасности, включая ролевую и/или атрибутивную политики доступа к данным с минимальными привилегиями.
Несмотря на то, что производственные роли конечных пользователей определяют содержимое дашборда, чтобы сделать его более структурированным, надо понимать, для решения каких бизнес-задач он создается. Например, директору по продуктам (CPO, Chief Product Oficer) нужно разработать стратегию развития продуктовой линейки компании на следующие 3 года. Для этого ему нужны агрегированные за год данные по плановым и фактическим продажам текущих продуктов, потребителям и конкурентам. У менеджера по качеству продуктов и услуг стоят задачи его непрерывного улучшения, для чего ему нужна подробная месячная статистика отзывов и оценок, а также данные об оставивших их клиентах. Хотя вся эта информация нужна для решения одной бизнес-задачи, для ее наилучшего восприятия ее можно расположить на разных вкладках дашборда. Хотя расположение и внешний вид визуализаций – это уже вопрос проектирования дашборда, а не разработке требований к нему, он напрямую зависит от исходной постановки задачи, т.е. кому и зачем нужны все эти графики, диаграммы и таблицы.
По сути, пользовательские потребности и бизнес-задачи дашборда можно задокументировать в форме User Story, например:
- как директор по продуктам, я хочу видеть агрегированные за год данные по плановым и фактическим продажам текущих продуктов, потребителям и конкурентам, чтобы разработать стратегию развития продуктовой линейки компании на следующие 3 года;
- как менеджер по качеству продуктов и услуг, я хочу видеть агрегированные за месяц данные и детали по клиентским отзывам и оценкам, а также информацию об оставивших их клиентах, чтобы спланировать корректирующие мероприятия.
Хотя подобные формулировки недостаточно детальны, поскольку в них отсутствуют требования к интерактивности дашборда, с них можно начать проектирование, попутно уточняя потребности пользователей в фильтрации и детализации представляемых данных. Например, нужны ли интерактивные drill-down отчеты с декомпозицией агрегированных значений по различным измерениям. При этом очень полезно сразу получать обратную связь от будущих пользователей, показывая им варианты решений, например, гистограмма для отслеживания динамики продаж или круговая диаграмма для отображения долей клиентов по статусам в программе лояльности.
Технические возможности и ограничения
Можно сказать, что пользовательские потребности и бизнес-задачи, для решения которых строится дашборд, относятся к анализу данных. Но на практике анализ информации довольно тесно связан с дата-инженерией, которая отвечает за сбор и преобразование исходных данных в вид, пригодный для анализа. Далеко не всегда дашборд строится на данных из тематических витрин, где данные из разных источников уже доменно структурированы и денормализованы. В отсутствии корпоративного хранилища данных (DWH, Data WareHouse) приходится строить дашборды на операционных данных, подключаясь к транзакционным системам-источникам (ERP, CRM и пр.). Таким образом, источники данных, их доменная область и структурированность напрямую влияют на то, как эти данные будут представлены на дашборде.
Кроме того, надо учитывать технические ограничения и возможности самой BI-системы или аналитического сервиса для построения дашбордов. Например, период обновления данных при подключении к внешнему источнику, поддержка кэширования, задержка отрисовки визуализаций. Также важно наличие коннекторов, которые реализуют подключения к системам-источникам и включают шаблоны визуализаций. Например, коннектор Yandex DataLens к CRM-системе Битрикс24 уже содержит преднастроенный типовой дашборд с визуализациями по лидам, сделкам и продажам. Однако, большинству заказчиков нужны дополнительные бизнес-метрики, вывод которых надо настраивать вручную. Следовательно, эта возможность должна быть у BI-системы. А если BI-сервис не поддерживает подключение к системе-источнику данных в принципе, придется связываться с промежуточным хранилищем и соответствующими ETL-процессами. К примеру, Kibana визуализирует только те данные, которые лежат в Elasticsearch. А PowerBI, уже упомянутый Yandex DataLens, Apache Superset поддерживают интеграцию с широким набором реляционных и нереляционных хранилищ. Кроме того, многие BI-системы и сервисы позволяют еще больше расширять этот перечень благодаря пользовательским коннекторам и возможностям API. Поэтому текущая и будущая ИТ-инфраструктура Заказчика напрямую влияет на формулирование требований к средству аналитики и отчетности.
Наконец, достаточно важными факторами, которые влияют на разработку требований к дашбордам, являются их стоимость и сложность эксплуатации. При этом надо учитывать схему лицензирования, варианты использования и объемы данных. Ценообразование многих BI-систем и сервисов зависит от количества пользователей и подключений. Кроме расходов на внедрение и сопровождение, возникают эксплуатационные затраты, когда пользователи сталкиваются со сложностью BI-инструмента и не могут самостоятельно настроить/построить нужный дашборд. Поэтому бюджетные ограничения Заказчика и возможности его пользователей тоже необходимо учитывать при разработке требований к дашборду.
Таким образом, из своего опыта я выделяю следующие 7 факторов, которые напрямую определяют требования к дашборду как к средству аналитики и отчетности данных:
- целевая аудитория (конечные пользователи);
- решаемые бизнес-задачи;
- вопросы безопасности предоставления данных;
- текущая и будущая ИТ-инфраструктура;
- технические ограничения и возможности BI-инструмента;
- стоимость и сложность эксплуатации;
- бюджетные ограничения Заказчика и возможности его пользователей.
Как уже было отмечено, дашборд – это тоже продукт, требования к которому можно и нужно оформить в виде технического задания, которое должно быть настолько детальным, чтобы по нему можно было сделать проектирование и реализацию. Какой состав может иметь этот документ требований, рассмотрим далее.
Требования к дашборду: состав ТЗ
Техническое задание на разработку дашборда может включать следующие пункты:
- Назначение дашборда – зачем он нужен. Например, дашборд предназначен для стратегического планирования развития продуктовой линейки компании и ее операционного мониторинга.
- Пользовательские требования – перечень конечных пользователей будущего дашборда с указание, какие данные им нужны и для решения каких бизнес-задач. Это можно сделать, составив реестр пользовательских историй, например, в табличной форме, например, так:
| Пользователь | История | Бизнес-задача
(чтобы что) |
||
| Название роли | Краткое описание | № | Формулировка | |
| CPO | Директор по продуктам | US-1.1 | Видеть агрегированные за год данные по плановым и фактическим продажам текущих продуктов, потребителям и конкурентам | разработать стратегию развития продуктовой линейки компании на следующие 3 года |
| US-1.2 | Фильтровать агрегированные за год данные по плановым и фактическим продажам текущих продуктов, потребителям и конкурентам, задавая параметры этих измерений | |||
| US-1.3 | ||||
| МК | Менеджер по качеству | US-2.1 | Видеть агрегированные за месяц данные и детали по клиентским отзывам и оценкам, а также информацию об оставивших их клиентах | спланировать корректирующие мероприятия |
| US-2.2 | Фильтровать агрегированные за месяц данные и детали по клиентским отзывам и оценкам, а также информацию об оставивших их клиентах | |||
| US-2.3 | ||||
- Данные и их источники – перечень метрик, которые нужно выводить на дашборде с учетом пользовательских требований, а также системы-источники, где хранятся эти данные. Это также удобно сделать в виде таблицы:
| Метрика | Исходные данные | Система-источник | Периодичность | Пользователь с правом просмотра |
| Средняя LTV клиента | Средняя сумма продаж по клиенту | CRM-система | Квартал | CPO |
| Средняя LTV продукта | Средняя сумма продаж по продукту | CRM-система | Квартал | CPO |
| Средняя оценка продукта | Отзывы покупателей в анкетах обратной связи | Яндекс.Карты | Месяц | МК |
- Нефункциональные требования. В этом разделе можно задать требования к безопасности, быстродействию отклика на действия пользователя, максимально допустимую задержку отрисовки визуализаций и прочие условия и показатели качества реализации функций дашборда, описанных в предыдущих пунктах. Сюда же относятся ограничения, влияющие на выбор решения, например, перечисление вариантов BI-систем или сервисов, допустимых с точки зрения корпоративного техрадара, проектного бюджета и пользовательских возможностей.
- Макеты визуализаций – примеры диаграмм, таблиц и графиков. Хотя это уже не требования, а дизайны, т.е. варианты их реализации, они вполне могут оказаться в техническом задании, чтобы утвердить их с заказчиком, а также использовать в качестве исходных данных для проектирования и реализации дашборда.
Как именно разработать понятные требования разработчику к дашборду и другим программным продуктам, вы узнаете на моих курсах Школы прикладного бизнес-анализа в нашем лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве:
