“Один дашборд, чтобы править ими всеми”
Привет! Как мы писали в предыдущих постах, наша команда создает удобные дашборды для разных департаментов СИБУРа, от хозяйственной деятельности до продаж.
Но всегда есть кто-то уровнем повыше, которому нужно как-то централизованно и быстро получать самую верхнеуровневую информацию по всем департаментам сразу (читай — по всем дашбордам).
Для этого мы создаем так называемый Царь-Дашборд. Control Tower. Мета-дашборд. Он содержит информацию о самых важных дашбордах, которые есть в компании, по сквозным процессам (это такие процессы, которые касаются нескольких разных функций, нескольких различных исполнителей в одной компании). Целевая аудитория такого дашборда — первые лица компании: CEO и, что называется, «минус 1» от его должности. Также данные с дашборда могут пригодиться и операционным специалистам, если им удобно воспринимать данные в таком формате.
Какие проблемы помогает решить такой дашборд
Например, мы смогли создать общий дашборд с основными индикаторами по примерно 200 метрикам из разных сквозных процессов.
Представьте ситуацию. Вот есть член управления, который отвечает только за производство. Он отлично знает производственный процесс, в курсе про нефтехимию, хорошо понимает, какие у него показатели, у него каждый день проходят оперативки, куда ему кто-то приносит отчетность. Но, допустим, в какой-то момент замечает, что общекорпоративные показатели по какой-то причине не выполняются.
Сам он в своем производстве делает все нормально, старается, у него выше плана, всё круто, но стоимость акций СИБУРа почему-то не растет. И он хочет в этой ситуации разобраться.
Для этого ему нужно понять, например, как обстоят дела дальше в следующих за его процессом этапах цепей поставок. Понятное дело, что существует дашборд по логистике. Но где он и нельзя ли, не заходя в него, понять какие-то основные цифры, основные метрики, что у нас вообще сейчас в логистике происходит и в других сквозных процессах тоже?
А можно.
Наш Control Tower призван давать управленцам общую картину по тому, что прямо сейчас происходит в компании. На всех уровнях. Данные в него планируется затягивать настолько актуальные, насколько возможно.
Человек просто открывает этот дашборд и видит все сквозные процессы.
Если зайти на этот экран и увидеть сразу все 200 метрик, можно решить, что как-то их тут слишком много, и хорошо бы посмотреть только на основные или на те, которые интересны конкретному человеку. Для этого мы сделали набор фильтров, на картинке в верхней части экрана, с их помощью можно из 200 показателей оставить только те, которые нужны.
Мы предусмотрели сохранение всех выбранных фильтров в качестве набора по умолчанию для конкретного пользователя — просто сохраняешь нужную выборку как шаблон, и всё, в любое время можно вывести только ее.
Главная концепция Царь-Дашборда в том, что всегда можно провалиться вглубь по конкретной метрике, в детальный дашборд, который посвящен именно этому сквозному процессу.
Давайте на живом примере — сейчас мы начали прорабатывать процесс S2P, если там нажать на срочные заявки, то мы проваливаемся в дашборд здоровья S2P. Если не нужно подробнее, то наоборот — возвращаемся на шаг назад и смотрим, как у нас процессы друг с другому дружат.
Именно подобные кейсы мы хотим этим дашбордом закрыть: показать все основные индикаторы из всех сквозных процессов по всем бизнесам и дать возможность пользователю по интересующему индикатору получать детальную картинку.
Пререквизитами при создании этого дашборда для нас служат, во-первых, витрины с данными в озере данных, во-вторых, готовые дашборды. Из витрин мы забираем индикаторы и постоянно их обновляем, а на дашборды даём ссылки.
На каком этапе продукт сейчас и что он может
Это MVP. В конце 2021 нашей задачей было продумать архитектуру, собрать MVP-решение, показать всем, как это вообще будет выглядеть. С этой задачей мы справились, теперь у нас новый этап — надо построить этот дашборд на продуктивных данных, хотя бы на некоторых сквозных процессах. А к концу года — уже по всем сразу.
Кажется, что ничего особенно, но тут есть пара занятных штук именно с точки зрения продуктового подхода.
Во-первых, здесь нет какого-то явного одного бизнес-заказчика, нет одного человека, который бы предоставил нам функциональные и функционально-технические требования. Я писал выше, что ЦА — члены правления. Когда вы разрабатываете какой-то продукт для более или менее привычной ЦА, у вас есть крутая возможность собрать представителей в одной комнате и провести нормальный качественный custdev. Можно ли это сделать с членами правления? Вообще нет, все всегда занятые, поодиночке кого-то еще можно выдернуть, но чтобы централизованно собрать всех — увы.
В итоге какой-то полезный фидбек собирается обрывками из коридорных разговоров. В нашем случае получилось найти такого связного, человека, который входит в эти круги и стал нашим единым окном входа, благодаря которому мы и получаем отзывы и хотелки по продукту.
На чём всё работает
Изначально у нас не было понимания, будем ли мы этот мета-дашборд делать в Tableau. Был просто заказ о том, что нужен конструктор дашбордов. То есть надо было создать некую систему, куда человек сможет заходить и там как-то пробовать отрисовывать графики один за одним, какой-то график добавлять на дашборд, добавлять нужные масштабы, нужные разрезы, нужную гранулярность. В общем, казалось, что от нас хотят систему, которая сможет заменить известные на рынке BI-инструменты.
Так что мы оказались на распутье: на каком решении нам нужно останавливаться. Либо мы генерим что-то свое, кастомное, сложное, привлекаем множество ресурсов, у нас будет полноценная команда разработки, то есть бэкендеры, фронтендеры, тестировщики, дизайнеры, QA, системные аналитики и так далее. Либо мы делаем что-то «наколеночное» с имеющимися уже в компании коробочными инструментами, как, например, Tableau, но, может быть, немного ограниченное по функционалу.
По мере работы мы остановились на втором варианте.
Решили, что порядка 80%-90% тех потребностей, которые нам сейчас заявлены, мы можем решить в Tableau. Чего-то решить не можем, скажем, не можем достичь максимально красивого дизайна, не можем достичь всех возможных сортировок, которые, наверное, были бы полезны, но основные кейсы с помощью Tableau закрываются.
Всё, что мы будем делать по продукту в этом году, будет сделано именно в Tableau. Может быть, потом, по мере перехода в прод или в какую-то коммерческую эксплуатацию, решим подключить что-то ещё. Возможно, начнем с нуля и будем делать какое-то дорогое кастомное решение, но пока это кажется маловероятным.
В общем, я хочу отметить, что мы не пошли по пути дорогостоящей разработки, а выбрали agile.
Вот как все работает.
Заходит юзер, проходит аутентификацию, выбирает метрики, которые ему нужны, бэкенд ему выдает набор этих метрик, он нажимает «Apply», на UI ему выводится выбранный набор метрик.
Мы из бэкенда (то самое озеро данных) подсасываем те числа по индикаторам, которые нам нужно показать. Дальше можно нажать на конкретный показатель и провалиться в конкретный дашборд.
Резюмируя
Цель Control Tower«а — создать достаточно низкий порог входа в дашборды: чтобы юзер, даже не владеющий навыками разработки дашбордов в Tableau Desktop, запросто мог понимать, в каких сквозных процессах у нас проблемы. Без каких-то хард-скиллов в программировании и без опыта работы в BI-инструментах.
Это может быть любой сотрудник компании, у кого есть доступ к Control Tower.
Итоговая архитектура на вид достаточно проста. Есть системы-источники, соответствующие команды, которые отвечают за отдельные дашборды по сквозным процессам, эти данные забирают.
Данные из систем-источников попадают в холодные и горячие хранилища, соответственно, в Hadoop и Vertica, 99% сейчас попадает в Vertica.
Оркестрируется это все с помощью NiFi и Airflow.
Мониторится с помощью ELK Stack.
В части Control Tower«а мы хотим просто настроить отдельные на бэкенде ETL-процессы, которые бы нам генерили витрины с этими индикаторами.
Для таких индикаторов мы планируем создать отдельный ETL-процесс, чтобы в Vertica витрины с таким индикатором собирать, а потом с сервера Tableau смотреть на эти витрины и отображать тот дашборд, который у меня был на первом слайде. А клиенты со своих терминалов — это те самые юзеры с предыдущего слайда — могли бы запросто и без проблем с низким входным порогом заходить на сервер Tableau и получать необходимую аналитику.
Процесс ещё идет, как я и рассказывал, так что будем писать об обновлениях!
