Почему никто не пользуется дашбордом. Три типичные ошибки при создании дашборда и как их избежать
Перевод. Оригинал
Представим, что вы потратили массу времени на подготовку шикарного дашборда для своей организации. Спустя несколько месяцев вы понимаете, что его никто не использует. Вам не жалуются на дашборд, но никто и не хвалит. Вот это настоящий удар под дых, особенно после усилий дать организации то, что по её словам ей нужно.
Ниже основные болевые точки разработчика и как их избежать.
Боль №1: Ваш дашборд красив, но не пригоден для бизнеса.
Дашборд должен содержать жизненно важную информацию для бизнеса. Он должен отражать ключевые показатели эффективности бизнеса. Организация разработала и внедрила эти показатели в своих процессах. Аналитик создает дашборд на основе существующих данных и не задумывается как бизнес будет использовать эти данные в будущем для принятия решения. Это может привести к появлению красивого, но, в конечном счете, неэффективного и ненужного дашборда.
Рассмотрим пример. В организации есть обязательства реагировать на обращения клиентов в течении четырех часов с момента получения заявки. На дашборде мы вывели количество обращений клиентов и общее количество всех обращений за месяц. Эта информация может быть интересна, но вряд ли полезна. Управленцам нужны конкретные измерения: какой процент обращений обработали по нормативу времени реакции. Как разработчик, представьте эту информацию в разрезе по командам ответственных, временным рамкам и продуктовым линейкам или подразделениям. Менеджеру надо определить, увеличился ли объем обращений, насколько плохо обучена команда, или у продукта есть серьезные недостатки. Дашборд должен подвести менеджера к принятию решения.
Разработчику нужно обязательно понимать метрики, которые отслеживает бизнес, чтобы создать эффективный и полезный инструмент. Разработчику следует сходить на несколько совещаний, где используется дашборд, чтобы понять: отвечает ли дашборд на заданные вопросы и что проблемы бизнеса решаются.
Боль №2: Ваш дашборд не заслуживает доверия
Как только дашборд становится доступным, на нем должны быть достоверные данные, которые регулярно обновляются. Дашборд измеряет реакцию команды на запросы клиентов. Члены команды замечают, дашборд показывает что только несколько обращений достигли четырехчасового порога, когда сами они знают, что почти все заявки у этого порога. Команда это знает, потому что отвечает на запросы клиентов и заносит информацию в базу данных.
Дашборд будут игнорировать, если его аудитория не будет доверять информации. При разработке дашборда необходимо убедиться, что вы понимаете правила любых расчетов метрик. Данные не будут отражать реальность, если пользователи не обновляют базу данных оперативно. Таким образом, измерения дашборда будут выглядеть неточными. Очень важно, чтобы вы проверяли дашборд с реальными результатами перед развертыванием и публикацией. Таким образом, команда поймет свою роль в поддержании точности информации на дашборде.
Другие проблемы могут возникнуть, когда команда отслеживает информацию ежечасно, а дашборд обновляется ежедневно. А вот это, отличная тема, она означает, что команда использует дашборд и хочет больше. Это то требование, которое меняется со временем. Первоначально информация измерялась еженедельно, но по мере того, как команда растет и организация созревает, бизнесу надо отслеживать производительность более пристально. Нужно предусмотреть на ранней стадии развития дашборда, будет ли поддерживаться подобное требование и как дашборд сможет наилучшим образом развиваться вместе с бизнесом.
Боль №3: Ваш дашборд — это «пропавший без вести»
Независимо от размера, как большие, так и малые компании сталкиваются с проблемой труднодоступности дашбордов. Они публикуются на сайте, который требует странной процедуры входа, он переезжает несколько раз или может находиться в нескольких кликов от главной страницы портала. В некоторых случаях организация использует облачные технологии для разработки и размещения дашбордов и не может получить к нему доступ из корпоративной сети. Аудитория дашборда либо не знает о его существовании, либо не может его найти.
По готовности дашборда, следует провести мероприятие его развертывания и публикации. Во время подобной церемонии, разработчик или его представитель знакомит пользователей с дашбордом, объясняет как его применять, проводит начальное, быстрое обучение по работе с ним. На мероприятии необходимо убедиться в том, что у пользователей есть доступ к дашбордам в системе или на портале. Этот процесс-представление гарантирует, что пользователи знают и смогут найти дашборд. Если дашборд содержит полезную информацию, остальная часть процесса проста. Этот ритуал гарантирует, что организация сможет идентифицировать и использовать новый инструмент.
Первый признак проблемы с дашбордом
Побеспокойтесь, если никто не жалуется и не просит модифицировать дашборд. Когда он приносит пользу, у пользователей всегда есть идеи по улучшению или им требуется видеть еще больше информации. Вы как разработчик должны стремиться к наращиванию функциональности дашбордов, которые управляют решениями в организации. И если это происходит, организация понимает ценность управления процессами на основе фактических данных.
