Reveal the Data

Блог Ромы Бунина о визуализации, Tableau и развитии BI-систем
канал в телеграмме | подборки примеров | подкасты и видео

Навигация между дашбордами в Tableau

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

Переходы с фильтрацией

Это один из самых важных и классных видов переходов — когда мы переходим в другой дашборд сразу с фильтров по какому-то срезу. Есть несколько вариантов как это можно релизовать.

Filter Action
Этот способ подойдёт, если у все ваши дашборды живут в одной книге. В этом случае мы создаем обычный Filter Action, но необходимо задать в виде Target Sheet другой дашборд:

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

URL Action с передачей параметров
Этот способ подходит, если необходим переход в другой дашборд, который храниться в другой книге. Кажется, что это более частый вариант для реальной структуры дашбордов.

В этом случае необходимо создать обычный URL Action, но передать в ссылку параметры после знака «?». В параметрах ссылки указывается название фильтра (поля в датасорсах должны называться одинаково на обоих дашбордах) и после равного его значения.

Так же в ссылках можно передавать не только фильтры, но и параметры. Документация по функционалу. У такого способа есть ограничения: есть максимальная динна url, которую может открыть браузер (может получиться если передаем много значений); может понадобиться конвертить пробелы с помощью URL Encoding; могут быть проблемы со спец. символами и русским языком в значениях; не очень удобно передавать даты и время.

Статичные ссылки на графиках

Если честно не очень знаю когда могу понадобиться такие кейсы, что при клике в любую точку графика происходит переход на другой дашборд, но функционал есть. Скорее это может использоваться для создания «псевдо» кнопок и ссылок из графиков (про это в следующем разделе).

Go to Sheet Action
Для перехода на другой лист есть специальный экшен. Дашборды или листы, обязательно должны бать в одной книге. Настройки супер простые — выбираем на какие графики кликаем и на какой дашборд переходим:

URL Action
Второй вариант реализации — это создать статичный URL, который не будет зависеть от данных. В этом случае просто создаем URL Action и прописываем туда статичную ссылку.

Кнопки и ссылки

Такие виды навигации полезны когда нам нужно сделать ссылку на «документацию», какой-то центральный дашборд и т. п.

Картинка с ссылкой
Создать какую-то иконку с ссылкой можно двумя способами, с помощью вставки объекта «Image» или вставки объекта «Navigation»:

Картинка подойдёт когда ведём на лист или дашборд, которого нет в книге и нужно выровнять икону не по центру.

Кнопка Navigation подойдет когда ведём на лист или дашборд из той же книги. Для этого выбираем тип «Image Button» и указываем куда делаем переход. Листы обязательно не должны быть скрыты.

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

Для создания «ссылки» просто создаем лист, используем Text mark и пишём что-то внутри текста. Дальше используем или Go to sheet Actions или URL Actions, в зависимости от задачи.

Тоже самое можно сделать и используя какою-то иконку из шейпов:

Ссылка в тексте
Самый простой и быстрый способ создать навигацию, но, к сожалению, самый некрасивый и о нём, на удивление тоже не все знают. В текстовый объект на дашборде можно вставить ссылку и она будет активной, но обычно длинной и страшной. Чтобы сделать её более понятной можно использовать какой-то сокращятол ссылок аля bit.ly и т. п.

Кнопка
Использованную встроенный элемент навигации, можно создать «кнопку» или «ссылку» (если выставить белый фон и сделать подчеркивание ссылки).

Кнопки работают отлично, а вот «ссылка» получается дурацкой, так как всегда выровнена по центру и имеет внутренние, довольно большие, паддинги.

Вкладки

Вкладки — привычный и удобный вариант навигации. Самый простой из них встроенные вкладки в самом Табло. На паблике они настраиваются вот тут:

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

Вкладки между дашбордами
Такие удобнее всего и проще сделать с помощью встроенного элемнета «Navigation». Суть в том, что делаем кнопки и оформляем их таким образом, чтобы они были «активными» на каждом из дашбррдов. Например, выделяем более ярким цветом. Плюс такого способа — простота, минус — придётся настраивать всё руками и ничего не забыть. Правда с копированием элементов между дашбордами, это стало сильно проще.

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

Вкладки внутри дашборда
Для реализации такого способа используется стандартный приём подмены графиков и создается лист с «псевдо» вкладками в виде шейп-файлов.

При этом понадобиться dummy источник в котором будут жить возможные значения параметров.

Для создания dummy источника я просто использую эксель, куда вбиваю нужное количество вкладок, а потом вставляю это в Табло через ctrl+C → ctrl+V (да, так можно, если вдруг не знали). А ниже примеры шейпов, которые использую я и инструкция как их добавить в Табло.

У Артёма Прыткова есть хорошее видео как собирать подобные кнопки и делать доп. экшены для снятия подсветки.

Зум для графика

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

Итого

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

Dashboard is dead. Long live Dashboard!

Саша Бараков недавно написал отличную статью про то, как он видит будущее развитие BI-систем. Мы с ним немного подискутировали в личке, и я тоже хочу побыть диванным футурологом и рассказать своё видение. А ещё в целом немного похоливарить про BI, у меня есть не очень популярное мнение на этот счёт.

не ищем связи картинки и текста, ее нет

Что в статье у Саши
Точно стоит прочитать её полностью для формирования своего мнения, она очень классная и заставляет думать. Ниже моё субъективное восприятие:

Текущий подход к дашбордам и BI-инструментам плохо решает задачи бизнеса и вера в них слабеет. Дашбордов делается всё больше, а реальную пользу они приносят не всегда. Аналитики любят свои дашборды и переоценивают их пользу, но боятся признаться в этом. А лучше признаться позже, чем никогда. Поэтому в будущем мы откажемся от повсеместного создания дашбордов и будем управлять метаданными данных и отчетов, чтобы «умные» BI-системы с помощью AI и NLP/NLG генерировали инсайты, готовые визы и подсказки пользователям. А пользователи же собирали из этих блоков как конструктор пинборды для своих задач (не очепятка, от слова pin). При этом BI-отделы будут собирать «подборки» самых полезных пинбордов для разных ролей сотрудников, заниматься мастер-данными и иногда делать сложные отчеты.

В целом всё примерно так, но я вижу две проблемы, которые не охватывает данный подход, хочу их обсудить.

тут тоже нет связи с текстом)

Один инструмент для всех задач

Почему дашборды стали воспринимать аналитическими инструментами я не знаю, на мой взгляд это одна из основополагающих проблем отношения к ним. Почему-то операционные дашборды для управления бизнесом путают с аналитическими инструментами поиска новых знаний, а также формирования и проверки гипотез. Рассмотрим классическую аналогию. Приборная панель автомобиля говорит вам «что сейчас происходит», но не говорит куда ехать. Вы можете встроить в машину 20 спидометров, но они всё равно не подскажут направление. Итого смешиваются две задачи — операционная аналитика (хочу знать с какой скоростью еду) и поисковая аналитика инсайтов (куда и как ехать). То есть ожидания от дашбордов завышены — спидометр позволяет не схватить штраф или не вылететь на повороте, но путь вам он не укажет.

При этом и вендоры, и руководители BI-отделов, осознанно или нет, играют в «сколько денег компания заработает/сэкономит на том, что сотрудники увидят в дашборде новые идеи». Но на самом деле деньги экономятся на автоматизации создания отчётов и сокращении времени реагирования на проблемы и реже на инсайтах и новых идеях. Поэтому я считаю, что часто от BI-систем есть завышенные ожидания и в итоге разочарование, когда они не совпадают с реальностью.

Окей, во многом это вопрос терминологии. Проблема в том, что под Business Intelligence понимают разные вещи. Если посмотреть википедию, то это целый набор систем и действий от репортинга (как раз дашборды) до предиктивной аналитики и циклов улучшения процессов. Так же себя стараются позиционировать и вендоры — «мы не просто дашбордики, мы экономим вам деньги».

Но при этом большинство людей, которые слышат термин Business Intelligence, в первую очередь, думают именно о дашбордах:

Получается конфликт — изначально закладывалось, что это будет чуть ли не философия работы бизнеса, а все понимают под этим отчеты и дашборды.

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

Современные BI-системы неплохо справляются с операционной аналитикой, но не идеально. При этом вендоры усердно идут именно в область поисковой аналитики и пытаются демократизировать данные с помощью модных AI и NLP и т. п. Мне жe кажется, что им бы стоило в первую очередь заниматься скоростью и стабильностью работы отчетов, сквозной провязкой данных, упрощением поиска отчетности, удобством администрирования и доступа к этим системам, а не «модными» направлениям. По сути, медленно работающий дашборд (частая, к сожалению, история всех BI-систем) — это нарушение минимально необходимых ожиданий пользователя по модели Кано, но этим занимаются далеко не в первую очередь.

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

И давайте, пожалуйста, не стесняться говорить, что мы делаем Reporting. В последнее время слышу от коллег, что как будто что-то нехорошее делаю. Стоп-репортинг-шейминг! =) А то такое ощущение, что надо делать везде только Self-Service и повсеместно развивать Data Literacy. Давайте, кстати, их тоже обсудим.

тут тоже нет связи с текстом, ну почти нет =)

Повсеместный Self-Service и Data Literacy

Сейчас говорят, что Excel — это плохо и ужасно, давайте сделаем везде Self-Service (я говорю про доступ к данным операционным менеджерам и сотрудникам, а не аналитикам в подразделении бизнеса). При этом, если Self-Service не взлетает, то впадают в две крайности: или ругают инструменты и пытаются сделать их проще с помощью NLP, Ask Data, AI и т. п.; или уходят в сторону людей — это не инструмент плохой, это пользователи не умеют работать с данными, давайте всех обучим Data Literacy.

Я уверен, что и тот, и тот путь приводят к одному — вендоры продают все больше лицензий и новых инструментов (думаю отчасти эта тема поэтому так и двигается), а люди так же плохо работают с данными и скоро будут ругать уже не Эксель и Кубы, а Табло и PBI. Так как суть будет та же — это просто прямой доступ к данным на стороне бизнес-пользователя, такой же, как был в Экеселе, который, о боже, тоже умеет подключаться к базам данных и OLAP. Проблема не в инструменте, а в управлении генерируемым контентом и решениями, которые делают пользователи на основе этих данных. Окей, тогда виноват не инструмент, давайте всех обучим работать с данными. И тут возникает вопрос: а почему это должно помочь?

Кажется, что мы, в целом, переоцениваем Data Driven подходы (здесь имеется ввиду анализ данных для принятия решения, построение гипотез и их проверка). Данные важны, но, к сожалению или к счастью, они не дают +100500% к эффективности просто своим наличием. Ты смотришь на данные и видишь, что есть проблема, но часто или не можешь повлиять на метрику, или, чтобы на неё повлиять, надо менять процессы и людей, а это супер сложно и часто понятно, что делать и без дашборда. Приведу личный пример — я собираю много данных о себе: и вес, и шаги, и сколько сижу за компом. Казалось бы: класс, наверное можно взять и получить кучу инсайтов! Но, как говорится «фигвам». Я столько раз крутил эти данные, делал красивые визы, но, по сути, это всё превращалось только в fun facts. Реальных инсайтов получить из них я не смог, а вот наличие контроля часто напоминает, что нужно что-то делать. А вот что нужно делать для улучшения здоровья, понятно и без дашборда, кеп. =)) Кажется, что так и в бизнесе, иногда надо просто взять и сделать, а не ждать красивого отчета.

Поэтому я считаю, что Data-Driven подходы должны работать не на всех уровнях компании, а только в нужных местах — на нужном уровне управления и там, где данные хотя бы в теории могут содержать инсайты и быструю выгоду. Плюс, в реальности, даже самые «цифровые компании» принимают и будут принимать многие решения далеко не только на основе данных. И чем более эти решения стратежные, тем меньше структурированных данных используется при принятии. Получается, что обучая всех сотрудников работе с данными в компании, компания не начнёт волшебным образом зарабатывать больше. Раздавая доступ к данным, нужно ещё параллельно строить процессы и культуру изменения на местах. Такими вещами занимаются методологии PDCA, DMAIC, бережливое производство и другие методики повышения эффективности. Но это совсем другие процессы и сроки, чем просто научить пользователя новому BI-инструменту или чем среднее отличается от медианы.

тут нигде нет связи с текстом

Что дальше

Окей, и что же будет дальше, спросите меня вы. Я думаю, что будет примерно так:
— В компаниях всё больше будут появляться BI-отделы или BI-аналитики как отдельная профессия. При этом лучше всего будут работать команды, где есть отдельный центр компетенций, а BI-аналитики привязаны к командам бизнеса. Все успокоятся и поймут, что дашборды — это просто удобный инструмент управления, но не панацея, перестанут делать дашборды на каждый чих и будут применять принцип: «лучший дашборд — это дашборд, который не пришлось делать». Критично важным станет дизайн набора дашбордов как системы и умение классно проектировать отдельные дашборды.

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

— Хайп Self-Service пройдёт и большинство компаний разочаруются в нём. При этом появятся удобные NoCode и NLP инструменты, которые снимут часть работы с аналитиков данных, когда их используют в качестве переводчика с «человеческого на SQL-ный» для выгрузок и презентаций. Со временем это будет превращаться в свалку дашбордов, запросов и рабочих книг, но кто-то придумает крутой полуавтоматический процесс чистки таких завалов. Это упростит и ускорит работу бизнеса, но глобально не позволит сэкономить огромное количество денег, только сократит время на получение данных. При этом аналитики данных станут заниматься более важной работой по построению гипотез и изменениям продукта и процессов. Грань между аналитиками данных, продуктовыми аналитиками, бизнес-аналитиками процессов и менеджерами продукта будет стираться.

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

— Эксель не умрёт =)

Вух, режим футуролога выключен. =) Очень хочу взглянуть на эту статью через пару лет, скорее всего ошибусь и десять раз поменяю своё мнение, но в данный момент лично я вижу всё именно так. При этом скорее это крик души, чем скрупулёзное и выверенное исследование, будьте осторожны. =)

The Dashboard is dead. Long live the Dashboard!

Связи правда нет, я просто подрезал идею у Саши в статье и захотел его немного потроллить =)
Модель — длиннопёс Юччи, фотограф — Валерия Бунина
 2 комментария    5796   4 мес   теория

Метрики BI-системы как продукта

Недавно познакомился с Сергеем Колосковым, продакт-менеджером Озон и автором канала Fresh Product Manager. Мне было интересно помучить настоящего менеджера продукта на тему выбора метрик для внутренних продуктов, например таких, как BI-система. Особенность таких продуктов заключается в том, что чаще всего они не генерируют прибыль компании напрямую и было интересно как же тогда оценивать успех или неуспех продукта. Обсудили какие группы метрик подходят для внутренних продуктов и я рассказал как устроено у нас. В целом сошлись на том, что хороши те метрики, которые комплексно показывают состояние дел и отвечают на задачи стейкхолдеров продукта. Если сейчас важен рост — концентрируемся на DAU/MAU и т. п., если важна непрерывная работа системы — на uptime системы и т. п. То есть какой-то идеальной и полной системы метрик скорее нет и над формировать её под каждый кейс.

Ниже расскажу какие метрики мы используем у себя для измерения «BI-системы как продукта». Наша BI-система построена на базе Табло и поэтому некоторые метрики будут специфичны именно для неё, но в целом подойдут для любой BI-платформы и универсальны.

Я считаю, что главная задача BI-системы помогать бизнесу быстро принимать решения, без рисков связанных с утечкой данных и ошибок из-за неправильных данных. Поэтому идеальной метрикой работы системы могли бы быть Time to Insight или денежная выгода от принятых решений с помощью это системы. Но я не придумал, как измерить это «по-честному» без аппроксимации в виде опросов «оцените сколько времени сэкономило вам внедрение дашборда». Кажется, что померить реальный экономический эффект от внедрения почти нереально или будет настолько затратно, что съест всю эффективность. Поэтому я выделяю группы метрик, которые, я верю, являются прокси к этим двум true north метрикам и их можно довольно просто померить. Эти группы следующие:
— Качество отчетности
— Скорость использования
— Вовлеченность
— Инфраструктура

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

Качество отчетности

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

«Аля NPS»
Качество отчетности можно проверять качественно и количественно. Для качественного исследования можно использовать опросы, мы проводим такой раз в полгода и узнаем у всех пользователей насколько им удобно пользоваться нашей системой. В итоге мы не измеряем именно NPS, но смотрим за средним баллом от 1 до 10 в целом и по отдельным вопросам. Основной вопрос: «Оцени по шкале от одного до десяти отчетность, которой пользуешься в Tableau. Интересуют любая отчетность в целом, которой ты пользуешься регулярно.» И девять дополнительных: Выбери наиболее важные пункты и не ставить много одинаковых оценок. 1 — «ужасно, займитесь в первую очередь», 10 — «всё и сейчас отлично»:
— Отчеты позволяют принять нужные бизнес-решения
— В отчетах есть нужные метрики/разрезы
— Понятно как считаются KPI в отчете
— В отчетах качественные данные (полные и правильные)
— Данные обновляются своевременно
— Легко найти нужный/новый отчет
— Отчеты работают быстро
— В отчетах понятная визуализация данных
— В отчетах понятный и удобный интерфейс

Ответы на эти вопросы помогают понять общую обстановку + узнать конкретные слабые места системы. Так же есть возможность оставлять текстовые комментарии, оттуда мы получаем много полезной информации. По результатам опроса мы конечно же строим дашборд =)

Целевые значения, на мой взгляд, должны быть 8.5 баллов.

Процент просмотров сертифицированных отчетов
Следующая метрика, не менее важная, чем предыдущая и я верю, что она во многом влияет на Time to Insight — процент просмотров приходящихся на качественную отчетность. Это значит, что мы делим все отчеты на нашем сервере на «хорошие» (сертифицированные) и на «плохие» (не прошедшие сертификацию) и верим, что «хорошие» отчеты быстрее решают задачу бизнеса.

Сертификация проходит в процессе ревью отчетов, которое проходит каждый отчет который попадает в продуктовую среду. Ревью отчет предполагает проверку на формальные признаки: наличие описания и понятного названия отчета, правильность выставления доступов, использование стандартов оформления. Так и признаки, которые проверяет эксперт в своей области — удобство и UX-отчета, правильность выполнения расчетов, оптимальность написанного «кода» в Табло. По-сути данный процесс похож на ревью кода программистами, но чуть менее стандартизирован с точки зрения проверки качества работы. Если отчет проходит проверку, то он попадает в когорту «хороших» и мы сравниваем соотношение количества просмотров сертифицированных отчетов к общему количеству.

Для того что бы избежать «накручивания» метрики за счет частотного просмотра небольшого количества отчетов мы учитываем только одни просмотр человека за день, плюс взвешиваем просмотр человека на его уровень в иерархии компании, так как верим, что решения топ-менеджмента влияют на развитие компании больше, чем решения принятые на местах. То есть, условно, просмотр одного из топ-менеджером равноценен просмотрам десяти обычных сотрудников. При этом так как количество топ-менеджеров небольшое, то мы получаем баланс интересов и учтем и те, и те голоса.

В первый год нашей работы — это была наша основная метрика для управления и классно позволяла принимать решение — какие отчеты нужно улучшать в первую очередь. Я считаю, что данная метрика должна стремиться к условным 80% и не обязательно все-все отчеты должны быть сертифицированы, главное, чтобы качественными были основные, а «длинный хвост» большого количества мелких отчетов может оставаться «плохим». При этом важно только, чтобы этот хвост не мешал поиску остальных отчетов.

Данную метрику нам с командой помог придумать крутейший Женя Козлов. И у него недавно вышел классный пост, где одна из историй посвящена процессу создания этой метрики и к чему это привело. Рекомендую почитать и статью, и канал Жени.

Скорость использования системы

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

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

Мы измеряем простоту получения доступа количеством индивидуальных ролей, которые пришлось получить человеку для доступа к отчету. То есть метрика — среднее количество персональных ролей для доступов на одного сотрудника. Если видим, что это число растёт — создаем новые группы и проводим обучение для аналитиков как правильно давать групповые доступы для сотрудников и создавать новые группы. Целевое значение для этой метрики нам ещё предстоит определить, но пока ориентируемся на не больше чем 5 персональных ролей на человека.

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

Скорость работы отчетов
Это самая очевидная вещь с которой, к сожалению, есть проблемы в большинстве BI-систем. Скорость отклика и загрузки дашбордов зависит от большого количества переменных: от скорость работы баз данных и качества «кода» дашборда, до количества людей на сервере в моменте и действий пользователя. Мы измеряем скорость первичной загрузки отчетов и ставим себе цель, чтобы 80% отчетов на сервере открывались за 5 и менее секунд.

Вовлеченность

Чтобы от отчетов была польза, надо чтобы им пользовались (спасибо, кэп!). Поэтому важными метриками являются так же метрики вовлечения сотрудников в работу с ними.

% пользователей системы от общего количества сотрудников компании
Это метрика косвенно показывает насколько развита data driven культура внутри компании и очень важна на первых этапах внедрения и особенно при внедрении self-service подходов. Целевое значение метрики может варьироваться от отрасли компании, но, кажется, что для современной компании из IT сектора данный показатель должен составлять 60-80% от компании.

MAU/DAU
Ежемесячная и ежедневная аудитория позволяют отследить нагрузку на сервер и понимать скорость роста продукта. Здесь важны скорее не абсолюты, но темпы прироста. Целевых значений для этой метрики я бы не ставил и использовал бы её справочно.

RFM
Мы стараемся применять классические продуктовые методы анализа и для внутренних инструментов. Поэтому используем и анализ вида Recency, Frequency, Monetary. Где за частоту использования берём количество просмотров, за «недавнось» количество дней с последнего захода на сервер, а вот за количество принесённых денег принимаем «топовость» пользователя в системе, то есть количество сотрудников между руководителем компании и самим сотрудником. Чем выше уровень человека, тем в большей степени его решения влияют на судьбу компании, поэтому мы перемножаем частоту заходов на коэффициент соответствующий уровню человека. Условно топ — 10, топ-1 — 5, топ-2 — 3 и т. п. Также смотрим и за когортами пользователей. Здесь нет каких-то целевых значений, зато есть проявляются паттерны и зная ретеншен по когортам, можно планировать закупку лицензий и т. п.

Инфраструктура

Последняя часть за которой мы следим с помощью метрик — это технические метрики качества работы системы.

Доступность
Это классическая метрика для любых систем. Здесь мы измеряем uptime системы и стараемся держать его на уровне 99%.

Процент ошибок
В зависимости от технических особенностей BI-системы можно следить за ошбиками в логах сервера или в обновлении данных. Мы следим за процентом неудавшихся обновлений экстрактов источников данных и количеством критических ошибок в логах сервера.

Загрузка мощностей
Здесь ничего волшебного — следим за загрузкой CPU и RAM сервера. Мы отслеживаем это в Графане, так как она позволяет смотреть за этим в реальном времени.

Пример дашборда

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

Итого

Описанные метрики составляют экосистему, которая помогает нам принимать решения о том, что сейчас стоит улучшить в продукте и мы верим, что она подходит для решения наших задач. Но, например, так как у нас нет развитого self-service на стороне бизнес-пользователей, то мы, например, не следим за метриками активности создания дашбордов и т. п. Поэтому как и говорил в начале статьи — каждый кейс требует проработки системы метрик под свои задачи. Если хотите посмотреть какие ещё метрики бывают для BI систем, загляните в раздел «9. Эффективность» на доске про стратегию от Саши Баракова.

Матрица компетенций BI-аналитика

Сделал матрицу компетенций, она родилась за год большой работы по менторству BI-аналитиков и «сериала» с Русланом. С радостью и гордостью хочу поделиться ей с комьюнити. Получилось круто.

Матрица будет полезна и новичкам — есть подсветка проседающих навыков и ссылки на учебные материалы. И компаниям  — для составления планов развития сотрудников.

Необходимо оценить себя по 69 навыкам из 6 направлений, которые важны BI-аналитику на мой взгляд. Каждый навык имеет уровень «прокачки» от 1 до 4 и описание, с примером ожиданий знаний от уровня. Но это только пример, при сомнениях, оцените навык по ощущениям от «джун» до «лид».

Матрица — не истина в последней инстанции, а ориентир и быстрый способ оценить себя. В идеале должна заполняться вместе с ментором, кто мог бы валидировать результат и дать практику.

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

🔗 Ссылка

Итоги первого сезона «Залетай в BI»

Статья подготовлена в рамках сериала «Залетай в BI»

Завершаем первый сезон сериала. =) В этот раз задачей Руслана было разработать овервью отчет для компании, который бы стал финальной вишенкой на торте системы отчетности, что мы делали. И вишенка прям удалась, получился очень стильный дашборд про основные показатели компании и топы по основным срезам.

Предполагается, что из него будут вести ссылки на другие овервью и страницы сущности, разработанные в рамках нашего приключения. Такой дашборд отвечает на вопрос — всё ли в порядке в компании на сегодня и позволяет быстро перейти на нужное направление бизнеса, чтобы увидеть детали. Я бы такой дашборд с удовольствием повесил на экран в кабинете или даже как плакат. =) Особенно мне понравились диаграммы проигрыш-выигрыш над спраклайнами.

Хочу подвести итоги первого сезона сериала. Для меня это был интересный опыт — я в первый раз проводил менторинг внешнего человека, а не коллеги или сотрудника. Получилось очень удачно! Но тут большая заслуга Руслана — он очень круто и структурно впитывал информацию, скрупулёзно подходил к домашним и заданиям и был классным партнёром по написанию постов. Прогресс от первого дашборда, до того, что получается сейчас просто огромный. Так же получился и огромный рост чисто по техническому знанию Табло. Дальше мы будем работать над тем как лучше собирать требования и есть моменты по граф. дизайну, которые нужно отшлифовать.

Это последняя серия с Русланом, возможно нас ждут новые герои. Но у истории Руслана счастливый конец — Руслан уже несколько месяцев работает у нас в команде. Здесь не было никакого кумовства и он отлично прошёл наши собесы на позицию.

Мне понравился такой формат «сериала» — он позволяет рассказать и про интересные технические моменты и вдохновить тех, кто только пришёл в область. Я размышляю о том, чтобы запустить второй сезон в новом году, если это будет интересно аудитории (так как это ест много ресурсов, а в планах ещё и хочется делать его с видео).

А ниже будут впечатления Руслана.

Залетайка для меня — это история про менторство, проектное обучение и удачу, которые соединились и превратились в “сменить профессию за 3 месяца”. Я сделал для себя несколько выводов, которые могут быть интересны всем, кто хочет попробовать себя в чем-то новом или прокачаться в своей области.

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

Мы познакомились с Ромой на курсе по датавизу от Лаборатории Данных и там я впервые попробовал поработать в Табло. Курс был хорошим стартом, но недостаточным, чтобы идти куда-то даже джуном. Я продолжил учиться на онлайн курсах, но везде упирался в то, что примеры задач были слишком абстрактными, не похожими на реальные задачи или на вопросы, с которыми я мог бы столкнуться на собеседовании.
Тогда я предложил Роме стать моим ментором. И с первого же занятия, я получил то, что хотел. Оно проходило в формате собеседования — ассесмента и там я узнал свой реальный уровень знаний (а точнее незнаний), но вместе с тем и указание, что нужно выучить в первую очередь, а что во вторую. Важный момент: если бы я пришел на такое собеседование с нулевым знанием табло и датавиза, то получил бы стандартный малополезный ответ — “иди учи азы”. Но чем выше твоя база, тем более специфична и обратная связь: “подтяни конкретно вот этот навык, а тут хорошо”

Вывод 2. Удачное менторство — это интерес и ответственность двух сторон.

Взаимодействие учитель-ученик не похоже на взаимодействие ментор-менти. У учителя есть обязательство научить и программа, а ученик идет по рельсам этой программы. Отношения ментора и менти более гибкие и персональные: программа у ментора может быть, а может и не быть, но в любом случае обучение должно подстраиваться под менти. Ответственность менти в том, чтобы этой возможностью активно пользоваться: задавать вопросы, просить обратную связь и даже придумывать самому себе упражнения.
Когда я пришел к Роме у него не было готового формата и залетайка, какой она получилась, это результат совместного обсуждения и доработок в процессе.

Вывод 3. Проектное обучение — будущее образования.

Если вы когда нибудь изучали Табло, то вы знаете что такое Sample Superstore. Это встроенный в Табло учебный набор данных, который используется в подавляющем большинстве обучающих материалов. Это удобно для первых шагов и простых примеров, но жутко скучно, если делать проект для портфолио. Мы сразу решили что хотим делать дашборды максимально приближенные к реальности и чтобы весь процесс был похож на настоящий. Поэтому нашли на kaggle хороший датасет с реальными данными, я проводил с Ромой настоящие интервью, а он играл аккаунт менеджера Джейкоба Бунина). Сейчас, уже сделав на работе настоящие боевые дашборды могу сказать, что опыт полученный при обучении был релевантным.

Вывод 4. Удача важна, но без действий она не приходит

С помощью менторства я реально быстро залетел в BI, но я понимаю, что сложилось много факторов:
— Я сходил на обучение и познакомился с Ромой
— У меня была возможность активно учиться
— У Ромы было время и возможности стать ментором
— Появилась вакансия
И т. д.

На удачу нельзя повлиять, но нужно дать ей шанс проявиться. Если бы я не пошел на обучение, то и не подумал бы о менторстве. Если бы не спросил Рому о менторстве, то не узнал бы, что у него есть возможность. Не сказал бы что ищу работу, Рома не предложил бы попробоваться на вакансию. Так что да, вот оно, банальное “Везет тому кто везет”.

P.S Это был отличный опыт и я желаю удачи всем, кто хочет развиваться и попробует менторство как инструмент своего развития

Оптимизация работы отчетов

Статья подготовлена в рамках сериала «Залетай в BI»

После небольшого перерыва Руслан продолжает осваивать премудрости Табло. В этот раз мы сконцентрировались на производительности и разбирались с тем как записывать Performance Recording. Скорость работы отчетов — очень важный показатель, для счастья пользователей. Если вы научитесь делать быстрые дашборды, они будут вам очень благодарны. =)

В этот раз задача была сугубо техническая — разобраться, что влияет на скорость работы отчета, как это замерить и улучшать. Для этого Руслан проштормил кучу материалов и попробовал применить усвоенное к одному из дашбордов, что мы делали до этого. Был записан исходный перфоманс, сделаны гипотезы по улучшениям и проведены повторные замеры.

Исходный дашборд: https://public.tableau.com/app/profile/ruslan6180/viz/olist_new/Dashboard_City

Исходный перфоманс рекорд отчета:

Чтобы перфоманс рекорд был максимально идентичным все записи запускались через макрос-кликер, записывающий движение мышки. Также был отключен фильтр на длительность операции < 0.01 секунды, чтобы видеть все операции. Записи проводились локально

За точку старта берется событие с параметром tabdoc:navigate-to-sheet, а точкой окончания — последняя операция render, не относящаяся к окончанию работы перфоманс рекорда.

Гипотезы по улучшению отчета:

  1. Уменьшить кол-во выводимых строк в Sellers List (сейчас выводится 5к+ marks), используя пагинацию и оставить только топ 100 городов на карте (вместо 4к)
  2. Переделать график с боксплотами, оставив только диапазоны, без отдельных значений

Проверка гипотезы 1

Теперь в таблице sellers list выводится только 30 строк, а на карте только 100 значений. Результаты:

Проверка гипотезы 2

Переделаны боксплоты, чтобы не было выбросов. Результаты:

Итого

Финальный дашборд: https://public.tableau.com/app/profile/ruslan6180/viz/olist_new_performance/Dashboard_City
Результат в серднем для первичной загрузки -0,5 сек от исходного времени в 3,7 сек (или -13%). Дашборд и так был быстрый, но процентный прирост довольно значимый.

 Нет комментариев    11370   7 мес   табло
Ранее Ctrl + ↓