Что большинство компаний ошибается в отношении аналитики самообслуживания

Опубликовано: 2021-08-15

Gartner определяет аналитику самообслуживания следующим образом:

Аналитика самообслуживания — это форма бизнес-аналитики (BI), в которой профессионалы отрасли могут и поощряются к выполнению запросов и созданию отчетов самостоятельно при номинальной поддержке ИТ. Аналитика самообслуживания часто характеризуется простыми в использовании инструментами BI с базовыми аналитическими возможностями и базовой моделью данных, которая была упрощена или уменьшена для простоты понимания и прямого доступа к данным.

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

Самообслуживание не является целью. Воздействие – это цель.

Давайте рассмотрим здесь некоторые проблемы на трех примерах того, как аналитика самообслуживания может не оправдать ожиданий:

  1. Пример № 1. Команда аналитиков сотрудничает с командой инженеров данных, чтобы создать информационную панель для лица, принимающего решения. Панель инструментов предназначена для самообслуживания и отвечает на точные вопросы, заданные в процессе поиска. Идеально. Пока это не так. А новые вопросы? Как насчет изучения данных?
  2. Пример № 2 : Команда решает использовать подход «в дюйм в глубину, в милю в ширину». Они отслеживают все, но с очень низкой точностью (например, они не используют свойства событий и не применяют таксономию). Теоретически теперь каждый имеет доступ к данным с помощью инструмента самообслуживания. Просто войдите! Но какова цена качества решений?
  3. Пример № 3. Команда из 40 менеджеров по продуктам получает доступ к инструменту самообслуживания. Они идут в город. Таблички появляются повсюду. Инструмент мощный и настраиваемый, но в настоящее время команда не очень хорошо разбирается в данных. Да, это самообслуживание, но оно не приводит к большему эффекту.

Пример №1 слишком жесткий. Пример № 2 ограничен качеством данных. В примере № 3 не удается масштабировать грамотность данных. В быстро меняющемся и непредсказуемом мире продуктов и роста мы постоянно выпускаем новые эксперименты и обновления. Выбранный нами подход должен идти в ногу со временем, не становясь загроможденным и непригодным для использования. Короче говоря, вам нужна устойчивая адаптивность, надежные данные и грамотность в отношении данных.

«Аналитика, в отличие от отчетов, должна быть интерактивной, что требует гибкости и высокого качества данных», — отмечает консультант по управлению продуктами Саид Хан. «Такой гибкости катастрофически не хватает во многих внутренних и внешних решениях. Вы вынуждены концентрироваться на вопросах, вместо того, чтобы оставить дверь открытой для новых областей любопытства. Или быть гибким и поверхностным. Это просто не работает для продуктовых команд».

Но проблемы немного глубже. Создание продукта — это командная работа. Как выглядит самообслуживание для всей команды, а не для одного бизнес-пользователя? Команде нужна свобода инструментировать и отслеживать новые события, не беспокоясь о том, что это может обременять другую команду. Им также нужна свобода доступа к информации, проведения исследовательского анализа, управления данными, совместной работы над идеями, планирования экспериментов и принятия мер.

Даже этот вид отдельной команды немного ограничителен. Учтите, что в большинстве организаций есть «группа данных», хотя эта команда перегружена работой и разбросана. Доминирующая модель — транзакционная: команды отправляют вопросы и запросы, команда данных делает все возможное, чтобы ответить или отклонить их. В ответ на переутомление они создают варианты «самообслуживания», чтобы получить передышку. Но это тоже плохая жертва.

«Самообслуживание в качестве искры любопытства, поиска вопросов и генератора идей — очень реальная и ценная вещь», — объясняет Грант Уиншип, инженер-аналитик в dbt Labs. «Но я думаю, что это должно сочетаться с продуктовым мышлением в команде данных. Менеджеры проектов и бизнес-пользователи должны быть готовы к тому, что их вопросы и аналитические находки будут синтезированы, опрошены и выборочно разработаны». Сотрудничество и образование имеют значение.

Для Елены Дьячковой, старшего менеджера по продуктовой аналитике Peloton, образовательный компонент — настоящий «слон в комнате». Бывший спортивный журналист, она сравнивает масштабирование грамотности данных с обучением спортсменов общим принципам силовых тренировок и «нахождением уникальных адаптаций к анатомии каждого спортсмена». Надлежащее использование данных, структуры для установки KPI и бизнес-контекст, стоящий за определенными показателями, «на самом деле не относятся к одному инструменту SaaS, но являются основой для всех других работающих элементов грамотности данных». Хотя мы видим, что аналитики используют Amplitude для помощи в этих образовательных усилиях, это все равно сводится к согласованным, целенаправленным усилиям.

Для нас в Amplitude этот более командный, совместный и ориентированный на результат подход — это самообслуживание. Не только доступ к приборной панели. Идея достижения целей «без помощи инженеров или специалистов по обработке данных» широко распространена, но она может усилить разрозненность и повлиять на результаты. Самообслуживание должно способствовать сотрудничеству, а не препятствовать ему.

В Amplitude мы пытаемся более целостно взглянуть на аналитику самообслуживания. Философия нашей продукции заключается в следующем:

  1. Поощряйте любопытство . Вопросы первого прохода редко бывают лучшими вопросами. Исследование вдохновляет на новые вопросы. Мы помогаем раскрыть длинный шлейф идей там, где кроются настоящие жемчужины.
  2. Самообслуживание — это свобода действий, устранение зависимостей и влияние. Речь идет не о перекладывании бремени, чтобы некоторые члены команды могли пользоваться легким доступом, в то время как другие члены команды выполняли черновую работу.
  3. Масштабируйте грамотность данных . Могут ли аналитик и менеджер по продукту работать вместе и учиться вместе? Может ли кто-нибудь начать анализ, сделать блокнот, а затем поделиться им с кем-то более опытным, чтобы получить обратную связь?
  4. Склонность к действию и воздействию. Поддерживая тестирование, рекомендации, персонализацию и пометку функций, мы приближаем команды к действию. В конце концов, цель состоит в том, чтобы построить систему, которая создает ценность для клиентов, бизнеса и т. д. Она не состоит в том, чтобы запускать отчеты.

Мы считаем, что самообслуживание вписывается в благотворный цикл. Доступ к полезным данным пробуждает любознательность, а любознательность в сочетании с сотрудничеством и грамотностью в отношении данных приводит к более эффективным решениям, действиям и влиянию.


Продуктовая аналитика для чайников