Дашборды логистики для Сибура: как упростить сложные данные

Сибур пришёл к нам не за тем, чтобы «сделать дашборды красивее».

Дашборды уже были. Команда работала в Tableau, пользовалась отчётами, проводила регулярные встречи, смотрела на план-факт, склады, порты, виды транспорта, отклонения и десятки других показателей. То есть задача была не в том, чтобы с нуля придумать аналитическую витрину.

Проблема была в другом: данных стало слишком много, а считывать главное стало сложно.

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

Подробные метрики, итоговые макеты и скриншоты мы не показываем из-за NDA. Поэтому это не кейс в формате «было / стало» с картинками. Зато можно рассказать о подходе: как мы перепроектировали сложные Tableau-дашборды для промышленной логистики и почему в таких проектах дизайн начинается не с визуала.

Сначала нужно понять, как люди принимают решения

В промышленной аналитике нельзя просто открыть Figma и начать раскладывать карточки.

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

• Руководителю важно быстро увидеть, где есть отклонение. 
• Докладчику — опереться на данные во время оперативки и ответить на вопросы. 
• Аналитику — проверить цифры, источники и разрезы. 
• Человеку, который отвечает за конкретный участок процесса, — понять, корректно ли дашборд отражает реальность.

Все смотрят на одни и те же данные, но задают им разные вопросы.

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

Поэтому мы начали не с визуала, а со сценариев.

• Как проходит встреча?
• Кто докладывает?
• В каком порядке обсуждаются блоки?
• Где возникают вопросы?
• Какие данные нужны сразу, а какие можно увести глубже?

Без этого легко сделать аккуратный макет, который не совпадает с реальной работой команды.

Главная задача — не убрать сложность, а навести порядок

Логистика — сложная система. Её нельзя свести к одному индикатору «всё хорошо / всё плохо».

Есть производственные площадки, внешние склады, порты, морская логистика, разные виды транспорта, продукты, периоды, ответственные, план, факт, отклонения, остатки, показатели безопасности, эффективности и результативности. Если всё это просто вынести на экран, получится большая таблица с цветами.

Нам нужно было не спрятать сложность, а разложить её так, чтобы пользователь быстрее понимал, куда смотреть. Где достаточно общего сигнала, где нужен разрез по направлению или площадке, а где уже начинается детальная аналитика для тех, кто разбирается в причинах.

Это важная разница. Упрощать B2B-дашборд до трёх красивых цифр нельзя: слишком много контекста и ответственности. Но можно сделать так, чтобы данные не спорили друг с другом за внимание.

Мы смотрели не только на экраны, но и на рабочий процесс

Один из важных этапов — разбор оперативки.

На таких встречах дашборд работает не как самостоятельный продукт, а как часть процесса. Кто-то докладывает, кто-то задаёт вопросы, кто-то фиксирует поручения, кто-то заранее собирает данные. Если интерфейс не совпадает с этим процессом, он начинает мешать.

Например, доклад идёт по одним блокам, а экран собран по другой логике. Или руководитель ждёт быстрый сигнал, а видит набор равнозначных таблиц. Или аналитик должен объяснить отклонение, но нужный разрез спрятан слишком глубоко.

Часто бизнес думает, что проблема в «неудобном графике». На практике проблема может быть в том, что интерфейс не повторяет реальный путь пользователя.

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

Красивую схему ещё нужно уметь внедрить

В какой-то момент почти всегда хочется сделать «интереснее таблицы».

Особенно в логистике. Там есть движение: заводы, склады, порты, транспортные плечи, потоки, задержки. Рука сама тянется к схемам, графам, Sankey-диаграммам и визуализациям, где всё куда-то красиво течёт.

Но BI-интерфейс — не презентационная картинка. Его нужно поддерживать на реальных данных. Он должен фильтроваться, обновляться, не тормозить, нормально работать в Tableau и оставаться понятным не только дизайнеру, но и пользователю на совещании.

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

• Можно ли это реализовать без костылей? 
• Будет ли работать фильтрация? Не станет ли интерфейс медленным? 
• Поможет ли это быстрее считать ситуацию?
• Не потеряем ли мы точность ради эффектной картинки?

Иногда ответ был неприятным: да, выглядит интересно, но как рабочий инструмент будет слабым решением.

И это нормальная часть работы. В сложных B2B-интерфейсах хороший дизайн часто не добавляет эффектов, а вовремя отказывается от лишнего.

Tableau задаёт свои ограничения — их нельзя игнорировать

Отдельная часть проекта была связана с возможностями Tableau.

В Figma можно нарисовать почти всё: скругления, сложные иконки, нестандартные блоки, большие интерактивные схемы, красивые переходы между уровнями. Но дальше начинается реальность. 

• Как это будет собрано в Tableau? 
• Что будет с производительностью? 
• Как поведут себя фильтры? 
• Можно ли поддерживать такой экран дальше? 
• Что произойдёт, если появятся новые метрики? 
• Как дашборд будет смотреться на большом экране? 
• А если его выгрузят в PDF?

Это не мелкие технические вопросы. Для корпоративного дашборда они критичны.

Если интерфейс долго открывается, пользователи возвращаются к старым отчётам. Если фильтров слишком много, ими перестают пользоваться. Если визуальное решение красиво только в макете, но плохо живёт в BI-системе, оно не решает задачу.

Поэтому мы проектировали не просто красивый экран, а систему, которую реально перенести в Tableau и развивать дальше.

Figma была не про картинку, а про проверку логики

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

Параллельно мы использовали подходы CJM и User Flow: разбирали путь пользователя от сбора данных до обсуждения и фиксации решений.

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

Современный промышленный интерфейс не обязан быть декоративным

У индустриальных дашбордов есть две частые крайности.

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

Обе крайности слабые. Если оставить всё как есть, интерфейс продолжает перегружать. Если уйти в декоративность, он теряет рабочую точность.

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

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

Что важно в таких проектах

Если у компании уже есть BI-система, но люди всё равно продолжают пользоваться Excel, PDF и ручными пояснениями, проблема не всегда в данных.

Иногда данные просто плохо организованы для принятия решений.

Перед редизайном дашборда стоит ответить на несколько вопросов: 

• Кто первый смотрит на экран?
• Что он должен понять за несколько секунд?
• Какие метрики нужны сразу, какие можно увести глубже?
• Какие роли работают с дашбордом?
• Что реально позволяет BI-инструмент?

Ещё один важный вопрос — что будет, когда метрик станет больше.

Хороший дашборд — это не разовый красивый экран, а система, которая выдерживает развитие. Если каждое новое направление ломает сетку, перегружает фильтры и заставляет заново пересобирать экран, значит проектировалась не система, а конкретный отчёт.

Что получилось

Мы не можем показать итоговые экраны и конкретные показатели, но можем сказать, какая работа стояла за проектом.

• Мы разобрали существующие Tableau-дашборды, сценарии пользователей и структуру логистических данных. 
• Разделили уровни: быстрый управленческий взгляд, рабочая аналитика, детализация по направлениям и отдельным метрикам. 
• Проверяли решения не только на уровне Figma, но и на уровне реализации в Tableau. 
• Продумывали визуальную иерархию, фильтры, тултипы, переходы и основу UI-kit для дальнейшего развития дашбордов.

По сути, мы работали не с «красотой дашборда», а с тем, как команда читает логистику и где в этом чтении теряется фокус.

Вместо вывода

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

Тогда он становится не местом, где лежат цифры, а рабочим интерфейсом для управленческого разговора.

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

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