Тема: дэшборд 4

Недавно на Хабре нам попалась статья Александра Баракова из datanature.ru, где он размышляет о будущем дэшбордов как медиума донесения аналитической информации. Мы посчитали интересным поделиться этим материалом с вами. Публикуем статью целиком. Авторская орфография сохранена.

День футуризма

Длинный отпуск в одиночку — время передумать вопросы, до которых не хватало времени весь год. Последние 10 лет я занимаюсь дашбордингом. Много вокруг него всего остального — data инжиниринга, бизнес-анализа, дизайна, консалтинга и даже data governance, но конечном счете я и мои команды 10 лет делаем дашборды для бизнеса. Сделали их тысячи, столько же похоронили, реанимировали и закопали снова). Достигли мы в этом если не совершенства, то почти его. Отстроили процессы, чеклисты, стайл гайды, пришли к оптимальным шаблонам, знаем как понимать скрытые требования заказчика, как внедрять отчеты в процессы, как обучать; сделали много ошибок и много из них выводов, короче видим задачи насквозь и различаем признаки фейлов до старта. Разве что книг мало читали — в основном те, что с картинками, можно было и больше.

И вот как всегда в жизни, ты приходишь к точке когда уровень насмотренности в какой-то сфере достигает критической точки и генерирует в твоей голове сначала ощущение, потом гипотезу, а потом и убеждение. Так эволюционировали и мои взгляды на дашборд — главную парадигму bi последних 10 лет, ставший для BI тулов как бы абсолютной идеей, острием всей конечной ценности, то куда в итоге все должны смотреть и радоваться обладанию дорогостоящей системой. BI-cистема для крупной компании с условными 2500+ юзерами стоит.. приличных денег, грубо округлив, пусть будет 800$K в год (300$K на софт и 500$K на команду) — у кого-то чуть меньше, у кого-то сильно больше. Чтобы окупить эти затраты нужно генерить много бизнес-пользы, ну прям много — кейсов ускорений решений, повышения их качества и плотности, сейвинга времени сотрудников и т.д. (тема отдельной статьи).

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

Симуляция счастья

Когда-то дашбординг, как форма коммуникации бизнес пользователя и данных, стал передовым, сменив фактически спредшиты (они же эксели для простоты) — прорыв был в красоте, интерактивности, шеринге и автообновляемости. Произошел рывок в Self-Service BI adoption — принятии BI решений в компании как в части работы с готовыми отчетами, так и в самостоятельной разработке пользователями. Но далее рост остановился на уровнях ~ 25-35% целевой аудитории. Есть несколько исследований — от Eckerson Group, BI Survey, Gartner, Thoughtspot на эту тему — сравните с вашим замером — мои данные и ощущения совпали.У того же Gartner была хорошая фраза, что self-service технология оказалась только в той степени полезна, в которой пользователи оказались способны себя обслуживать.

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

• Уводит куда-то в сторону.. — пользователь тратит время на то, чтобы понять, что говорит ему большой, красивый отчёт, а не то, что его реально самого интересует;
• Обсуждать не значит пользоваться.. — пользователи всегда готовы давать замечания и пожелания, но это не значит что они планируют пользоваться этим отчётом в работе.
• Чужому не верится.. — для многих недоверие к чему-то, сделанному не ими, оказывается непреодолимым. Боль всех reporting factory сервисов;
• А, тут начать думать придется.. — люди склонны не пользоваться отчетами после разработки, даже если они объективно оказались полезными. Успокаивает сам факт наличия нужного отчета, а времени чтоб зайти и открыть, отфильтровать и найти инсайт — нет, все убивают текущие бизнес задачи;
• Любая задача = дашборд — пользователь всегда захочет дашборд под любую задачу, слайды для презы или ad-hoc для проверки гипотезы. Делая каждый раз борд, мы размножаем визуальные вариации, которым пользуются недолго, переключаясь на следующую новую задачу и порождая новый борд и т.д.
• Борд сам стремится к перегруженности, как самурай к смерти — в стремлении дать пользователю гибкость и вариативность мы делаем сложные «антидашборды» добавляя +100500 фильтров, переключателей, снижая при этом понятность, инсайтность, быстродействие. До определённого момента это может работать на повышение adoption отчета, но в конечном счете убивает в нем дашборд.
• Self-service не есть однозначное благо — нельзя все, что делают пользовали относить к пользе. Большая часть это пробы и «заброшки», создающие массу, которая выглядит обманчиво внушительно, но дает 0 ценности.
• Дорогая суета.. — классический извращенный цикл аналитической задачи — есть запрос на отчет, запускается анализ доступных данных, их допобработка, дизайн борда, уточнение логики — и когда запрос менеджера отвечен bi-отчетом, запрос уже изменился, уточнился, дополнился, сменился новым. Упорный аналитик не сдается и «бежит за поездом» — уточняет требования, переделывает, напрягает доп. экспертов, добавляет данных. Так создается «движуха», за которой часто не случается deсision support или принятое решение имеет микро-масштаб по сравнению с затратами на производство этой поддержки. Иногда сама эта движуха на пути к абстрактно «желаемому» совершенству логики и визуализации незаметно становится самоцелью работы.

Здесь, я смешиваю и аналитические дашборды и операционные (справедливое замечание Ромы Бунина). Это так, разберемся с этим чуть далее.

Обобщая эти разрозненные набросы, я бы выделил 3 главные причины стагнации в принятии BI:

— фундаментальный информационный разрыв между пользователем и отчетами — пользователи в массе не понимают (не хотят вникать, не могут, не имеют времени — неважно) общекорпоративные отчеты, теряются в их разнообразии и не готовы по разными причинам делать свои. В парадигме дашбординга — решается (1) повышением персонализованности и адресности доставки готовой аналитики, что сразу повышает операционные расходы BI команды на поддержку, тренинги, консалтинг, (2) децентрализаций разработки и продажей идей SS BI. Мы много экспериментируем с пользовательским опытом в этой части, создавая специальные готовые ролевые аналитические рабочие места с отчетами, это дает свой результат, но все равно проблема большая и недооцененная.

— неоперативность дашбординга, его неспособность успеть за меняющимся бизнес вопросами, причем как в формате self-service так и в формате reporting factory. Даже отточенный процесс производства дашборда занимает дни и недели (кто бы, что ни говорил про часы и минуты), это было прорывом 10 лет назад, но это супер долгая итерация для современного аджильного мира. Особенно явно это стало в 2020 когда COVID-19 постоянно менял ситуацию, на которую бизнесу нужно было реагировать. Пока мы делали одну версию бордов про удаленную работу сотрудников, хождение в офисы и вакцинацию — нужна была уже другая с другими требованиями и данными.В части self-service BI — да, мы увидели как в бизнесе выделилась каста power users, те же аналитики с BI навыками просто децентрализованно распределенные в компании. Но это все равно буфер между лицом принимающим решение и данными. Этот буфер остался и несёт в себе неизбежные потери в оперативности и глобально не решает проблему разрыва в цепочке создания ценности. В итоге pixelperfect дашборд — проигрывает не-дашбордовым решениям — «наколеночным» селектам и чартам на актуальных данных.

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

1. Бизнес-заказчик преувеличивает пользу и не хочет признавать, что не часто пользуется правильным отчетом, к разработке которого к тому же имел отношение. Это может быть истолковано как его же некомпетентность.
2. BI разработчик в процессе долгой разработки формирует эмоциональную связь с отчетом, и любит его в итоге больше, чем он реально заслуживает, может не замечать его оторванность от жизни и неактуальность, винить пользователя в низком usage rate. Я часто замечаю, что даже самые крутые наши отчеты, в той или иной степени, переоценены нами.

Аналитики ушли в мир BI ноутбуков

Дашборды, как упоминалось выше, лучше делить на типы. Упрощая, выделим три, как мне кажется, наиболее контрастные: стратегические, операционные, аналитические.

1. Стратегические — быстрый обзор состояния и триггеров для решений; фокусировка на высокоуровневых показателях; простота; интерактивность около нуля; фильтров нет или почти нет; аудитория — топы;
2.  Операционные — мониторинг состояния метрик в различных разрезах, сравнениях, динамиках; больше информации, сложнее и дольше понимание; понятные отработанные пользовательские сценарии; более широкая аудитория middle-, low-level менеджмента;
3. Аналитические — требуют дополнительного контекста; сложные для восприятия и инсайтов, более глубокие по возможностям анализа; неочевидные пользовательские сценарии; высоко-интерактивные, с большим количеством фильтров.

Так вот, первые два типа можно сейчас объединить — оба про операционный мониторинг, просто на разном уровне обобщения, есть отличия в подходах к дизайну, но цели едины — вывести информацию, максимально ускорив принятие решения пользователем. Третий же тип вообще ошибка и наша BI-ная гордыня — строить для всего дашборды. Мы вроде уже все поняли, что цель дата экплорайшна изначально порочна для дашборд-фокусированных BI тулов (типа святой троицы табло, пауэрбиай и клика). Мы делаем вид, что это не так, создавая из отчетов «франкенштейны» с кучей фильтров и переключателей, чтобы заложить в него максимум возможностей для непрогнозируемых пользовательских сценариев исследования. Вендоры по схожим причинам насаждают функции исследования для casual users (а ля web edit) и wrangling tools (типа tableau prep). Но истина — как у классика — для Графа де ла Фер (аналитика) этого слишком мало, а для Атоса (менеджера) этого слишком много. И нет, ситуативное использование отдельными вашими коллегами не опровергает этот факт.

Еще мы видим активное распространение ноутбук-тулов (перерожденных старых SQL IDM систем), объединяющих в себе удобный code-based (иногда drag-and-drop) querying на sql/python и визуализацию данных в таблицы/графики. Такой «BI ноутбук» содержит актуальные данные и контекст — все что нужно, чтобы гибко проводить и менять анализ, визуализировать, описывать, шарить и проверять чужой на разных этапах. Эти условные «BI ноутбуки» расставили точки над «и», отъев себе из BI тулов изрядную часть времени аналитиков. Эта мысль глубже раскрывается в статьях тут и тут правда с выходом на рекламу тула Count — вероятно действительно неплохого (попытка очеловечивания олдскула типа jupiter и zeppelin). Убьют ли ноутбуки data wrangling функции условных табло и клика? — хз, но в них точно больше жизни.

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

По факту, цель нового BI — ликвидировать временной и понятийный блокер между десижн-мейкером и инсайтом-решением-действием при этом:- найти новую форму самообслуживания, исключив не только кодинг, но и поиск данных, drag-drop разработку, верстку и часть анализа данных, а возможно и вообще сократив до нуля сам self-serve компонент как генератор лишних потерь,- объединить для пользователя преимущества оперативного и вариативного BI-ноутбука и преднастроенность, персонифицированность дашборда.

Новые BI формы — что в итоге идёт на смену

Что рассуждать — BI-вендоры для нас уже все придумали. Конечно — все модное из последних конференций — Augumented analytics, NLP search AI based search, insight generation. Многие уже встречали сверхоптимистичный прогноз Gartner о том, что к 2025 году 75% data-историй будут автоматически генерироваться augumented analytics технологиями.Вот только реальное воплощение этих функций для разработчика и пользователя в полном тумане. Ощущение, что вендоры сами пока не понимают нового воркфлоу. BI-команды не видят ценности в сырых AI-сервисах, бизнесу все равно, а проблема низкого качества данных умножают на 0 вcе попытки тесты. Вопросов много. Но давайте сначала с наиболее понятного мне вывода: дашборды не умерли, они и не жили полноценно (как мы с вами хотели). Уровень требуемой персонификации, вариативности и оперативности аналитики будет убирать преднастроенные дашборды как излишнюю, дорогую и местами вредную прослойку, неоптимально предопределяющую пользовательский опыт. Дашборды не умрут, скорее займут небольшую нишу стандартизованного устойчивого во времени менеджерского репортинга, где форма и логика устоялись и не меняются часто. Ресурс и фокус аналитических команд перейдет на новые BI формы — условных приложений-конструкторов, генерируемых пользователем и автогенерируемых под пользователя из разных сущностей. Что это будет? — вот возможные отличительные характеристики нового BI:

• Новый интерфейс с customer grade UX для навигации non-technical бизнес-пользователя к инсайтам (тема пинбординга раскрывается далее);
• Google-like поиск с толковым и обучающимся движком с использованием live-query и без предагрегаций — будет генерировать свои и выдавать чужие чарты по запросам пользователя на естественном языке;
• Текстовые и визуальные AI-генерируемые инсайты — нарративы, подсветка зон для фокуса, потенциальных инсайтов в виде как текста, спец.чартов, цвета;
• Каталоги артефактов своего и чужого поиска и дальнейшим процессингом файндингов через таск-трекинговые системы;
• Нормальные «умные» алерты — текущие опции из коробки реально не взлетели из-за примитивности, ручного привода и ограничений в использовании;
• Проваливание в BI notebooks для ухода в реальный data exploration, обзор логики и lineage для тех, кому хватает дата грамотности;
• Новые средства коммуникаций вокруг BI файндингов с более тесную интеграцией с корп мессенджерами — аналогичные функции в текущих BI решениях не используются главным образом потому, что обсуждать нечего — инсайты очень глубоко в графиках, а общение в BI инструменте ненативно пользователю;
• Лайв коннекты BI-системы с базами хранения данных (часто облачных) — задержка в актуальности будет сводиться к нулю или минимуму стриминговыми DWH решениями. Эффективность NLP функции будет повышаться «дружбой» с моделям данных ключевых вендоров (AWS, Bigquery, Snowflake, etc), новыми коннекторами;
• Conversational BI — корпоративные чат-боты и голосовые ассистенты — следующий шаг за NLG в отказе от self-serviсe операций пользователя, еще менее готовый на текущий момент, но логичный.

Эту концепцию неплохо осмысляет thoughspot, которые не имеют груза дорогостоящего легаси продукта и сразу создают нечто новое, толкаясь от чужих тупиков. Ребята жестко набрасывают на традиционный BI (имея ввиду уже tableau, Qlik, PBI и т.д., как изменчив мир), но вот это демо порадовало проработанностью опыта пользователя. Понравился термин — pinboard (воистину, шаришь в маркетинге — начни со своего нейминга)) — тоже борд, но формируемый пользователем через сохранение элементов (чартов, инсайтов, алертов и т.д.), генерируемых поисковым движком, извлекаемых из чужих наработок или собираемых вручную. Нативно мышлению здесь выглядит и движение пользователя по drill-down / drill-up сценариям.Похожий концент контектной аналитики развивает Yellow Fin BI.

Вообще подход с минимальной преднастройкой, гибким составлением панелей из элементов и интерфейс универсального гугл-поиска — кажется проще текущих сценариев self-service и перспективнее с точки зрения вовлечения новой «спящей» аудитории бизнес менеджмента и нового прорыва в self service BI adoption с 30 до 60-70%. Задача старательно верстать и размещать элементы заранее должна будет уйти — она слишком трудоемкая, и при этом в ней уже все понятно и шаблонировано, чтобы убрать отсюда ручной труд. Пользователь по сути может конструировать себе пинборды по темам с той сложностью, к которой он готов, собирая их из готовых элементов.
Для кого и это будет ту мач, остается сценарий использования готовых ролевых пинбордов (читай здесь «дашбордов»).

Хуже дела у лидеров, имеющих большую инерцию, — Qlik, Tableau и PBI тоже инвестируют в эти идеи, но их разработки, на мой взгляд, не содержат нового понятного и единого интерфейса, связывающего NLP-сервис и инсайт-генерацию с базовым продуктом. Есть отдельно дашборды, отдельно AI сервис. Работа внутри дополнительной прослойки в слое данных (как у tableau и Qlik), вероятно, будет сильно сдерживать взлет технологии — построение всей обвязки со своими published data source кажется большим ограничением того же табло. Инсайт-генерация PBI сейчас похожа на кучу текста с описанием отклонений, большая часть из которых малозначима, а текстовая форма убивает все преимущества визуального анализа, и превращает пользователя в читателя (здравая мысль Димы Гудкова).

Пока сами вендоры дают себе еще 5-7 лет на доработку и обучение еще семантически «глупых» NLG движков, давайте представим модель трансформации самого BI сервиса, процессов и команды, по ходу онбординга этого подхода.

Очевидно, что взлет AI функций будет повышать автономность бизнес-пользователей и снижать поток ad-hoc запросов и запросов на разработку отчетов на data / BI аналитика. Ресурс BI команды начнет высвобождаться, куда его придется перенаправлять? Есть ощущение, что в центр внимания BI команды попадет продукт и всяческая поддержка процесса обучения AI-движка на распознавание данных, поисковую эффективность, настройку интерфейса для пользователя.
Примеры активностей, которые, на мой взгляд, станут приоритетными:

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

Нужно ли менять BI тул? — кажется нет, по крайней мере по причинам эволюции BI. Виденье сейчас у всех похожее, есть отличия реализациях, но говорить кто первый соберет работающий концепт сложно. Вероятно народный рейтинг систем будет меняться в зависимости от успешности адаптации под новые реалии и будет исход клиентов в новых и дерзких игроков. Так, если вы выбираете BI систему и не связаны еще вендорскими предрассудками, посмотрите на thoughtspot из взрослых систем (не на правах рекламы, не является инвестиционной рекомендацией)) или на arria (NLG расширение для PBI, Tableau Qlik и других), или на молодые и нишевые решения типа narrative bi, Outlier, Lexio, datastories (спойлер — скоро их всех купят), а я буду ждать новых откровений от чудотворных крестов tableau.

Что можно начать делать заранее? Работа, как известно, — заполняет все отпущенное ей время, и, если осознанно не букать ресурс, движения не будет. Варианты:— сделать роадмап кардинального решения проблем с качеством для критических данных для компании (сотрудник, клиент, кандидат, затраты, платежи, отгрузки, запасы и т.д.). Если будут дыры в этих данных, скачок в новый BI вы не совершите. Не поздно взяться за вопрос глобально — развернуть хорошее DQM решение.— копить базу инсайт-кейсов, какой бы ни был новый потенциал BI системы, настраивать адекватность ее инсайтов придётся вам с командой тем или иным образом (для этого нужна будет накормленная база)— проинвестировать в модернизацию data стека — data warehouses, data lakes, lakehouses и прочий data mesh)) — устаревшие решения заблокируют вам модернизацию BI— заняться причесыванием метадаты и отладкой процессов ее поддержки— перейти от финансирования BI как кост-центра к новой модели фондирования BI проекта и метрикам эффективности, завязанных на выручке и монетизации репортинга — количество дашбордов и отчетов скоро окончательно перестанет волновать кого-либо.- ничего не делать и не париться (тоже норм вариант).

Все эти рассуждения могут у кого-то вызвать ощущение безотлагательности каких-то перемен или наоборот неважности, нематериальности новых трендов, но это футурология, полезная для формирования направлений трансформации, но не более. Реальное понимание текущих задач, ограничений в вашей компании и потенциала ваших текущих инструментов будет всегда важнее новых фич, до которых ещё надо дожить. А польза от BI должна производится здесь и сейчас. So, god save dashboards)