DATA NATURE BLOG
DASHBOARD, DASHBOARD -
СКОЛЬКО ТЕБЕ ЖИТЬ ОСТАЛОСЬ?
СКОЛЬКО ТЕБЕ ЖИТЬ ОСТАЛОСЬ?
By alex barakov
Январь, 2022
*Осторожно - в статье много англицизмов в русском спелинге - сорян
*Осторожно - в статье много англицизмов в русском спелинге - сорян
DATA NATURE BLOG
DASHBOARD, DASHBOARD -
СКОЛЬКО ТЕБЕ ЖИТЬ ОСТАЛОСЬ?
СКОЛЬКО ТЕБЕ ЖИТЬ ОСТАЛОСЬ?
By alex barakov
Январь, 2022
*Осторожно - в статье много англицизмов в русском спелинге - сорян
*Осторожно - в статье много англицизмов в русском спелинге - сорян
День футуризма
Длинный отпуск в одиночку - время передумать вопросы, до которых не хватало времени весь год. Последние 10 лет я занимаюсь дашбордингом. Много вокруг него всего остального - data инжиниринга, бизнес-анализа, дизайна, консалтинга и даже data governance, но конечном счете я и мои команды 10 лет делаем дашборды для бизнеса. Сделали их тысячи, столько же похоронили, реанимировали и закопали снова). Достигли мы в этом если не совершенства, то почти его. Отстроили процессы, чеклисты, стайл гайды, пришли к оптимальным шаблонам, знаем как понимать скрытые требования заказчика, как внедрять отчеты в процессы, как обучать; сделали много ошибок и много из них выводов, короче видим задачи насквозь и различаем признаки фейлов до старта. Разве что книг мало читали - в основном те, что с картинками, можно было и больше.
И вот как всегда в жизни, ты приходишь к точке когда уровень насмотренности в какой-то сфере достигает критической точки и генерирует в твоей голове сначала ощущение, потом гипотезу, а потом и убеждение. Так эволюционировали и мои взгляды на дашборд - главную парадигму bi последних 10 лет, ставший для BI тулов как бы абсолютной идеей, острием всей конечной ценности, то куда в итоге все должны смотреть и радоваться обладанию дорогостоящей системой. BI-cистема для крупной компании с условными 2500+ юзерами стоит.. приличных денег, грубо округлив, пусть будет 800$K в год (300$K на софт и 500$K на команду) - у кого-то чуть меньше, у кого-то сильно больше. Чтобы окупить эти затраты нужно генерить много бизнес-пользы, ну прям много - кейсов ускорений решений, повышения их качества и плотности, сейвинга времени сотрудников и т.д. (тема отдельной статьи).
И вот, летишь ты в отпуск и думаешь, что и как делать в новом году еще круче, чтоб верить в это самому и заражать других. Включить в себе, блеать, футуриста. Так вот в дашборд, как в верховный смысл BI, - верить уже не получается. Сейчас модно говорить про смерть bi каким мы его знаем, про смерть дашбордов - звучит прикольно, но это кликбейтный бред вендоров и заканчивается всегда он саморекламой. Мне же хочется не столько накинуть на вентилятор, сколько поразбираться и понять для себя что-то, обрести новые идеи или занизить ожидания. Поэтому притормозим. Тут нужна, мать ее, завязка.
И вот как всегда в жизни, ты приходишь к точке когда уровень насмотренности в какой-то сфере достигает критической точки и генерирует в твоей голове сначала ощущение, потом гипотезу, а потом и убеждение. Так эволюционировали и мои взгляды на дашборд - главную парадигму 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 технология оказалась только в той степени полезна, в которой пользователи оказались способны себя обслуживать.
С тех пор как дашборды пришли всерьёз в корп реальность, помимо самой пользы наблюдается и симуляции и иллюзии пользы дашборда, а также искажения пользовательских вокрфлоу, неосознанные конечно. Мы сами хотим обманываться, они же такие у нас красивые, наши дашборды. Вот несколько примеров таких явлений:
Обобщая эти разрозненные набросы, я бы выделил 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 - здесь сталкиваются два мощных когнитивных искажения.
У того же 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 - здесь сталкиваются два мощных когнитивных искажения.
- Бизнес-заказчик преувеличивает пользу и не хочет признавать, что не часто пользуется правильным отчетом, к разработке которого к тому же имел отношение. Это может быть истолковано как его же некомпетентность.
- 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-ноутбука и преднастроенность, персонифицированность дашборда.
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:
Похожий концент контектной аналитики развивает Yellow Fin BI.
Вообще подход с минимальной преднастройкой, гибким составлением панелей из элементов и интерфейс универсального гугл-поиска - кажется проще текущих сценариев self-service и перспективнее с точки зрения вовлечения новой "спящей" аудитории бизнес менеджмента и нового прорыва в self service BI adoption с 30 до 60-70%. Задача старательно верстать и размещать элементы заранее должна будет уйти - она слишком трудоемкая, и при этом в ней уже все понятно и шаблонировано, чтобы убрать отсюда ручной труд. Пользователь по сути может конструировать себе пинборды по темам с той сложностью, к которой он готов, собирая их из готовых элементов.
Для кого и это будет ту мач, остается сценарий использования готовых ролевых пинбордов (читай здесь "дашбордов").
Скрины, о чем речь, на примере thoughspot:
(возьмем его не в рамках рекламы - не могу назвать тул идеальным, просто не имею о нем полного представления)
Вот только реальное воплощение этих функций для разработчика и пользователя в полном тумане. Ощущение, что вендоры сами пока не понимают нового воркфлоу. 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 операций пользователя, еще менее готовый на текущий момент, но логичный.
Похожий концент контектной аналитики развивает Yellow Fin BI.
Вообще подход с минимальной преднастройкой, гибким составлением панелей из элементов и интерфейс универсального гугл-поиска - кажется проще текущих сценариев self-service и перспективнее с точки зрения вовлечения новой "спящей" аудитории бизнес менеджмента и нового прорыва в self service BI adoption с 30 до 60-70%. Задача старательно верстать и размещать элементы заранее должна будет уйти - она слишком трудоемкая, и при этом в ней уже все понятно и шаблонировано, чтобы убрать отсюда ручной труд. Пользователь по сути может конструировать себе пинборды по темам с той сложностью, к которой он готов, собирая их из готовых элементов.
Для кого и это будет ту мач, остается сценарий использования готовых ролевых пинбордов (читай здесь "дашбордов").
Скрины, о чем речь, на примере thoughspot:
(возьмем его не в рамках рекламы - не могу назвать тул идеальным, просто не имею о нем полного представления)
*тут нигде нет связи с текстом
Хуже дела у лидеров, имеющих большую инерцию, - Qlik, Tableau и PBI тоже инвестируют в эти идеи, но их разработки, на мой взгляд, не содержат нового понятного и единого интерфейса, связывающего NLP-сервис и инсайт-генерацию с базовым продуктом. Есть отдельно дашборды, отдельно AI сервис. Работа внутри дополнительной прослойки в слое данных (как у tableau и Qlik), вероятно, будет сильно сдерживать взлет технологии - построение всей обвязки со своими published data source кажется большим ограничением того же табло. Инсайт-генерация PBI сейчас похожа на кучу текста с описанием отклонений, большая часть из которых малозначима, а текстовая форма убивает все преимущества визуального анализа, и превращает пользователя в читателя (здравая мысль Димы Гудкова).
Пока сами вендоры дают себе еще 5-7 лет на доработку и обучение еще семантически "глупых" NLG движков, давайте представим модель трансформации самого BI сервиса, процессов и команды, по ходу онбординга этого подхода.
Очевидно, что взлет AI функций будет повышать автономность бизнес-пользователей и снижать поток ad-hoc запросов и запросов на разработку отчетов на data / BI аналитика. Ресурс BI команды начнет высвобождаться, куда его придется перенаправлять? Есть ощущение, что в центр внимания BI команды попадет продукт и всяческая поддержка процесса обучения AI-движка на распознавание данных, поисковую эффективность, настройку интерфейса для пользователя.
Примеры активностей, которые, на мой взгляд, станут приоритетными:
Нужно ли менять BI тул? - кажется нет, по крайней мере по причинам эволюции BI. Виденье сейчас у всех похожее, есть отличия реализациях, но говорить кто первый соберет работающий концепт сложно. Вероятно народный рейтинг систем будет меняться в зависимости от успешности адаптации под новые реалии и будет исход клиентов в новых и дерзких игроков. Так, если вы выбираете BI систему и не связаны еще вендорскими предрассудками, посмотрите на thoughtspot из взрослых систем (не на правах рекламы, не является инвестиционной рекомендацией)) или на arria (NLG расширение для PBI, Tableau Qlik и других), или на молодые и нишевые решения типа narrative bi, Outlier, Lexio, datastories (спойлер - скоро их всех купят), а я буду ждать новых откровений от чудотворных крестов tableau.
Пока сами вендоры дают себе еще 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)
- сделать роадмап кардинального решения проблем с качеством для критических данных для компании (сотрудник, клиент, кандидат, затраты, платежи, отгрузки, запасы и т.д.). Если будут дыры в этих данных, скачок в новый BI вы не совершите. Не поздно взяться за вопрос глобально - развернуть хорошее DQM решение.
- копить базу инсайт-кейсов, какой бы ни был новый потенциал BI системы, настраивать адекватность ее инсайтов придётся вам с командой тем или иным образом (для этого нужна будет накормленная база)
- проинвестировать в модернизацию data стека - data warehouses, data lakes, lakehouses и прочий data mesh)) - устаревшие решения заблокируют вам модернизацию BI
- заняться причесыванием метадаты и отладкой процессов ее поддержки
- перейти от финансирования BI как кост-центра к новой модели фондирования BI проекта и метрикам эффективности, завязанных на выручке и монетизации репортинга - количество дашбордов и отчетов скоро окончательно перестанет волновать кого-либо.
- ничего не делать и не париться (тоже норм вариант).
Все эти рассуждения могут у кого-то вызвать ощущение безотлагательности каких-то перемен или наоборот неважности, нематериальности новых трендов, но это футурология, полезная для формирования направлений трансформации, но не более. Реальное понимание текущих задач, ограничений в вашей компании и потенциала ваших текущих инструментов будет всегда важнее новых фич, до которых ещё надо дожить. А польза от BI должна производится здесь и сейчас. So, god save dashboards)
Больше похожего контента в нашем телеграм-канале https://t.me/datanature
Статьи по теме, если кому хочется еще:
Статьи по теме, если кому хочется еще:
- https://www.yellowfinbi.com/blog/2021/03/what-death-of-dashboard-really-means-for-analytics
- https://media.thoughtspot.com/pdf/ThoughtSpot-Dashboards-are-Dead.pdf
- https://www.yellowfinbi.com/blog/2020/10/what-is-contextual-analytics
- https://www.geckoboard.com/blog/are-dashboards-really-dead/
- https://blog.count.co/the-analytical-workflow-is-broken/
- https://blog.count.co/dashboards-are-dead/
- https://manrai-tarun.medium.com/dashboards-are-dead-c1116cfebb60
- https://developer-tech.com/news/2021/dec/15/will-2022-signal-the-death-of-the-dashboard/
- https://www.holistics.io/blog/the-death-of-dashboards-really/
- ThoughtSpot-Building-the-Modern-Analytics-and-BI-Team-White-Paper.pdf
- ThoughtSpot CEO - 'I want to kill BI and I want all dashboards to die' (diginomica.com)
- ThoughtSpot-Become-the-Analyst-of-the-Future.pdf (hubspotusercontent40.net)
- Preparing data for natural language interaction in Ask Data (tableau.com)
- Dashboards are Dead. Dashboards have been the primary weapon… | by Taylor Brownlow | Towards Data Science
Другие статьи по теме