У нас уже было более 30 готовых дашбордов для строительного снабжения. Они позволяли подробно разбирать заявки, оплаты, поставки и работу сотрудников. Но при внедрении мы слышали от части пользователей: сложно разобраться, некогда настраивать фильтры, проще спросить коллег. Некоторые прямо спрашивали, можно ли открыть аналитику с телефона.
Сначала мы рассматривали упрощённые десктопные дашборды, но столкнулись с вопросом: что считать лишним, если финансисту, снабженцу и руководителю проекта нужны разные данные?
В итоге мы начали разрабатывать мобильную аналитику. Сначала сделали прототип, почти полностью сохранивший логику десктопной версии, а затем стали пересматривать способы группировки данных, фильтрации и детализации. Я работала над обеими версиями и расскажу, какие решения оказались важнее простого сокращения числа графиков.
Аналитика есть. Времени — нет
«Синтека» помогает строительным компаниям управлять снабжением: от возникновения потребности в материале до его поступления на объект. Упрощённо эта цепочка выглядит так:
Потребность → заявка → запрос поставщикам → счёт → согласование → оплата и доставка → приёмка на объекте.
На каждом этапе появляются сроки, суммы, статусы и ответственные. Если согласование счёта затянулось, это может повлиять на оплату и поставку. Поэтому руководителю недостаточно знать состояние одной заявки: важно видеть, где накапливаются задержки, на каких проектах возникают проблемы и какой объём обязательств предстоит закрыть.
Наша библиотека аналитики росла постепенно. Изначально дашбордов было немного, а разные разрезы находились во вкладках одной визуализации. Например, в анализе доставок можно было переключаться между поставщиками, ответственными за планирование и приёмщиками.
Со временем обнаружился недостаток: информация на второй или третьей вкладке была менее заметна, чем на первой. Мы начали выделять разрезы в самостоятельные дашборды, расширять набор показателей и добавлять аналитику под более узкие запросы клиентов. Так появилась библиотека из более чем 30 готовых дашбордов — пользователям не нужно было собирать отчёты с нуля.
Однако готовый отчёт ещё нужно прочитать. Чтобы получить ответ, иногда требовалось совместить несколько визуализаций, выбрать период, переключить вкладку и настроить фильтры. Для подробного исследования данных это рабочий инструмент. Но если ответ нужен во время совещания или на объекте, такая подготовка отнимает время.
Это было не только наше предположение. При внедрении приходилось повторно проводить обучение, писать инструкции и записывать видео. Некоторые пользователи говорили, что в компании нет человека, готового регулярно разбираться в аналитике. Руководителю снабжения могло быть проще обратиться к сотрудникам и спросить, что происходит сейчас.
Так мы получили две связанные задачи: сделать данные понятнее и дать возможность работать с ними без компьютера.
Что убрать, если каждому нужно разное
Первой идеей было оставить в десктопных дашбордах только основные показатели. Но универсального набора не нашлось: финансовому отделу нужны одни данные, логистике — другие, руководителю снабжения — третьи.
Наша BI-платформа не позволяла пользователю самостоятельно собрать персональный набор визуализаций. Мы могли сделать отдельную версию под конкретного клиента, но индивидуальные варианты пришлось бы сопровождать и обновлять при каждом изменении общей аналитики. Чем больше таких версий, тем больше ручной работы.
Нам нужен был подход, при котором не пришлось бы выбирать один сокращённый набор данных для всех или поддерживать множество персональных копий.
Параллельно команда начала экспериментировать с разработкой за пределами BI-платформы: мобильными приложениями и чат-ботами. Это позволило проверить другую идею — сохранить аналитические данные, но самим управлять тем, как пользователь с ними взаимодействует.
Одни данные — разные способы взаимодействия
Мы не стали переносить BI-модель в мобильное приложение и пересобирать аналитику заново. В BI уже были подготовленные витрины данных, на основе которых можно строить аналитику бизнес-процессов и создавать разные визуализации без необходимости каждый раз писать SQL-запросы с нуля.
Витрины формируются на основе данных «Синтеки» и обновляются каждые 15 минут. Это позволяет регулярно получать актуальную аналитику, хотя изменения в системе отражаются на дашбордах не мгновенно.
Поэтому в BI остались витрины, кубы, меры и базовые расчёты — они стали фундаментом мобильного решения. Через API мобильная версия получает подготовленные данные и меняет способы их представления: группировки, срезы, карточки, навигацию и детализацию.
Исходные данные при этом не подменяются, но иногда для мобильного экрана появляются дополнительные производные показатели. Например, оценка критичности процесса в «Пульсе снабжения». Эта метрика рассчитывается на основе данных, поступающих по API из заранее подготовленных аналитических кубов. В приложении дашбордов показатели группируются по процессам и по заданной формуле преобразуются в единый индекс критичности.
Сейчас доступ к мобильным дашбордам организован через встроенное мини‑приложение в мессенджере MAX — пользователь открывает нужный интерфейс непосредственно из чата.
Кейс: «Пульс снабжения» — пилот без полной переделки
Для первого эксперимента мы выбрали «Пульс снабжения»: десять однотипных карточек бизнес-процессов с переходом к детализации. Каждая карточка позволяет увидеть, насколько задерживается конкретный процесс снабжения, как это сказывается на проектах и кто за него отвечает.
Например, можно посмотреть, сколько счетов необходимо согласовать прямо сейчас, как долго они ожидают согласования и работу какого проекта эта задержка тормозит больше всего.
Это был удобный пилот: не требовалось одновременно осваивать мобильную разработку и заново придумывать аналитическую модель. Даже пользователям, которым другие дашборды казались сложными, «Пульс» был понятен.
Первичный прототип собрал мой руководитель. Я подключилась к его рефакторингу и переработке, одновременно разбираясь с мобильной разработкой. Доведение пилота и освоение нового подхода заняли около двух месяцев.
Эксперимент оказался удачным: карточки помещались на небольшой экран, а основная логика дашборда сохранялась. Мы не заменили графики карточками — карточки были и в десктопной версии. Изменились их представление и взаимодействие с ними.
При этом собственная разработка дала возможность решить старую проблему с фильтрацией.
В исходном дашборде разные роли ответственных были представлены отдельными полями. Чтобы посмотреть нужный рабочий контур, пользователю приходилось учитывать эти различия. В мобильной версии мы объединили выбор в один фильтр «Ответственный».
Ограничение было связано с устройством BI-платформы: её фильтр привязывается к одному полю и не позволяет объединить несколько полей с разными названиями. Чтобы реализовать такую фильтрацию стандартными средствами, пришлось бы создавать отдельный куб для каждого ответственного и дублировать данные по сущностям, у которых несколько ответственных.
В мобильной версии пользователь выбирает ответственного в одном фильтре, а приложение проверяет, указан ли он в любом из соответствующих полей — например, как ответственный за оплату или за принятие в оплату. Так мы сохранили исходные витрины и избежали дублирования данных.
Раньше мы пытались упростить такую фильтрацию через изменение SQL-запросов и подхода к работе с данными. Для мобильного решения удалось оставить базовые витрины и запросы прежними, изменив обработку пользовательского выбора в коде приложения.
Единый фильтр в мобильном «Пульсе»
Добавили и сохранение фильтров. Если руководитель выбрал свои проекты или сотрудников, при следующем открыт
ии дашборд уже показывает этот рабочий срез. Одна и та же настройка больше не становится обязательным первым шагом каждого просмотра.
«Пульс» был важен как пилот переноса и проверка нового подхода к разработке. Он показал, что мобильная версия позволяет не просто открыть аналитику с телефона, но и изменить неудобные взаимодействия. После этого мы стали переносить другие направления, уже не рассчитывая, что каждому дашборду достаточно переоформить существующие блоки.
Принцип 1. Начинать с управленческого вопроса
Мобильный экран не обязан показывать всё, что есть в источнике. Сначала нужно понять, на какой вопрос человек должен получить ответ.
В десктопной аналитике путь к этому ответу часто начинается с последовательности действий: выбрать дату, ограничить проект, указать ответственного. В мобильной версии мы старались вынести типовой вопрос на первый план и заранее подготовить нужный срез.
Кейс «Контроля снабжения»: где заявка может не успеть
Я разрабатывала десктопную версию «Контроля снабжения» и знала, что нужные ответы в ней уже можно получить. Проблема была в том, что пользователю требовалось самому подобрать сочетание фильтров по датам, статусам и визуализациям.
Например, при обучении мы показывали, как найти заявку, по которой материал нужен сегодня, но работа ещё находится на начальном этапе. Для этого нужно было отфильтровать заявки по требуемой дате доставки и посмотреть распределение позиций по стадиям выполнения.
Сам аналитический вопрос был простым: какие заявки с датой доставки на сегодня ещё недостаточно продвинулись в обработке? А подготовка ответа оставалась на пользователе.
В мобильной версии я выделила страницу «Риски». На ней две группы заявок:
Материал требуется доставить сегодня, но больше половины позиций находятся на начальных этапах: запрос не отправлен, счёт не получен или счёт не отправлен на согласование.
Заявки уже просрочены.
Это разные ситуации. В первом случае есть сигнал о возможном срыве срока, во втором срок уже нарушен. Обе группы требуют внимания, но смешивать их в обещание «мы предупреждаем все проблемы заранее» было бы неверно.
Главное изменение здесь — не новая метрика. Я превратила комбинацию условий, которую раньше объясняли на обучении, в самостоятельный аналитический срез. Пользователь сразу получает список для проверки, а не инструкцию, как этот список собрать.
Этот же принцип повлиял на структуру других экранов «Контроля снабжения».
Вместо одного перегруженного представления появились отдельные страницы с ответами на разные вопросы. «Сейчас» показывает текущую работу: сколько заявок находится в обработке, как распределена нагрузка по сотрудникам и на каких стадиях находятся позиции.
«Динамика» позволяет посмотреть выбранный период: сколько заявок и позиций создано, как выполнялись заявки, сколько выполнено вовремя и с просрочкой.
Таким образом, на мобильном мы не переносим последовательность действий из десктопной аналитики, а заранее собираем наиболее частый управленческий вопрос в отдельный маршрут.
Готовые срезы вместо обязательной настройки фильтров
При этом я не убрала ручные фильтры полностью. Можно выбрать даты, проект или сотрудников, если нужен особый сценарий. Но для типового вопроса пользователь не обязан начинать с настройки.
В мобильных дашбордах появились готовые временные срезы: сегодня, последние 7 дней, месяц, 3 месяца и полгода. Это не новая бизнес-логика, а заранее подготовленные способы посмотреть уже имеющиеся данные.
Принцип 2. Выбирать форму под смысл данных
Мобильная версия не должна повторять десктопную визуализацию только потому, что она уже существует. На телефоне важно выбрать форму, которая соответствует самому объекту анализа.
Кейс «Анализа затрат»: календарь вместо относительной шкалы
В десктопной версии «Анализа затрат» платёжный календарь был построен как относительная временная шкала: ноль означал сегодня, минус один — вчера, плюс один — завтра.
Все данные присутствовали, но пользователю нужно было мысленно переводить смещения в реальные даты.
Для мобильной версии я выбрала обычный календарь месяца. Это знакомая модель: человек ищет конкретный день, неделю или месяц, а не интерпретирует относительные значения.
В ячейках можно показать сумму и количество платежей, а дополнительными кнопками — выбрать нужное состояние, например платежи, принятые в оплату.
Сценарий понятен на совещании: финансового руководителя спрашивают, какие платежи предстоят на ближайшей неделе. Вместо поиска нужного диапазона на шкале он открывает календарь, выбирает дни и видит список платежей, из которых сформирована сумма.
Здесь мы пришли к простому выводу: если пользователь мыслит календарными датами, интерфейс должен показывать даты, а не заставлять переводить техническое представление в привычную форму.
Единый язык карточек
Вместо широкой таблицы я стала использовать общий способ построения карточек: заголовок с основной информацией, заметный статус, связанные данные и одинаково оформленные кнопки перехода к исходным записям.
Этот подход затем переиспользовали в других дашбордах. Пользователю не нужно заново выяснять, как открыть заявку, счёт или доставку при каждом переходе между разделами.
Повторяемость карточек становится частью общего языка мобильной аналитики.
Отдельный маршрут для данных, которые не вписываются в общую модель
Календарь оказался не универсальным ответом на все финансовые вопросы.
Если счёт есть, но дату платежа ещё нужно определить, помещать его в календарь запланированных платежей некорректно: даты пока нет.
Для таких счетов мы сделали отдельный маршрут: вкладка «Планирование», блок «Надо запланировать», карточка счёта и переход к планированию в «Синтеке».
Такой раздел появился не ради ещё одной вкладки. Объект без даты требует другого действия и не может корректно участвовать в календарной модели.
Принцип 3. От сводки — к следующему шагу
Мобильный дашборд не должен заканчивать сценарий на общей цифре. После сводки пользователь должен понимать, куда перейти дальше: к заявке, проекту, платежу, доставке или исходной записи.
Иногда следующий шаг — разобраться в деталях, иногда — перейти к действию в системе.
Кейс «Анализа доставок»: от общего состояния к проекту и команде
В десктопной аналитике доставок были самостоятельные разрезы по поставщикам, ответственным за планирование и приёмщикам. Для подробного исследования это полезно. Но чтобы оценить одну проблему, иногда приходилось переходить между дашбордами.
В мобильной версии я начала с другого порядка: сначала понять, что происходит с доставками, а затем посмотреть проект и людей, связанных с ситуацией.
Обзор показывает объём и распределение доставок по состояниям: что уже доставлено, что запланировано, где есть просрочка или недовоз. Для текущей работы выделены очереди планирования и приёмки.
Отдельно можно посмотреть доставки с отклонениями: состоявшиеся позже срока, с недовозом или с отметкой «Груз не приехал».
Календарь здесь переиспользует знакомый по платежам способ просмотра, но отвечает уже на вопрос о поставках. А вместо отдельных страниц для каждой роли появились представления по проектам и команде.
При работе с проектным разрезом обнаружилось, что обычного списка карточек для детализации недостаточно. Руководителю может понадобиться не только перечень доставок, но и динамика, отклонения и команда именно этого объекта.
Можно было предложить ему открыть фильтры, найти проект, выбрать его и затем пройти по нескольким страницам.
Я выбрала другой путь: нажатие на проект открывает детализацию с относящимися к нему показателями, динамикой и сотрудниками. Это уже локальный аналитический обзор, а не просто список доставок.
Так у детализации появились два уровня: обзор выбранного проекта и данные конкретной доставки. Возможность вручную выбрать проекты, людей и даты осталась, но для типового перехода она больше не обязательна.
Общий экран «Анализа доставок», выбранный проект и его детализация
В результате сводка становится способом перейти к объекту, где можно разобраться в ситуации и при необходимости что-то сделать, а не конечной точкой маршрута.
Избранное как личный список контроля
Во время работы с доставками возник ещё один сценарий. Руководитель заметил проблему, обсудил её с сотрудником, а на следующий день хочет проверить, изменился ли статус.
Для этого не хочется заново искать запись и повторять вчерашние фильтры.
Поэтому мы добавили блок «Избранное»: заявку, доставку или платёж можно сохранить для повторного просмотра.
Например, руководитель отметил просроченную доставку и позже открывает её в избранном, чтобы посмотреть актуальное состояние.
Когда запись больше не требует внимания, её можно убрать из списка. Это не система постановки задач и не подтверждение выполнения поручения, а личный список объектов, которые сейчас важно держать на контроле.
Как принципы работают вместе
Дашборд «Исполнение проектов» не вводит отдельный принцип, а объединяет уже найденные решения.
Он собирает финансовую и логистическую части снабжения вокруг проекта: сколько оплачено и доставлено, какие обязательства остаются и что запланировано на ближайшее время.
В детализации сохраняется логика обзорного экрана, но данные относятся к одному объекту. При необходимости можно перейти дальше — к заявке и статусам её позиций.
Руководитель начинает с общей картины проекта, а затем переходит к платежам, поставкам и заявкам, которые её формируют.
Получается маршрут, основанный на всех трёх принципах мобильной аналитики:
Управленческий вопрос → подходящая форма → сводка → объект → следующий шаг.
Что мы вынесли из этой разработки
В результате мы разработали пять мобильных дашбордов. Сейчас работаем над другими способами доступа: через дополнительные платформы или собственное приложение.
Пока это результат разработки и проектирования, а не измеренный эффект клиентского использования. Но уже на этом этапе можно сформулировать несколько выводов для похожих задач.
Для пилота полезно выбрать понятную и востребованную модель. «Пульс» позволил проверить мобильный формат без одновременной переделки всей аналитики. Не каждый десктопный дашборд требует полной перестройки.
Оценивать стоит не только число графиков, но и путь к ответу. Даже небольшой набор показателей может требовать множества действий. Поэтому важно понять, что пользователь должен выбрать, сопоставить и вспомнить, прежде чем получит нужную информацию.
Разделы нужно проектировать с учётом того, чего ещё нет в данных. Если платёж не сформирован и у него нет даты, календарь его не покажет. Для таких случаев нужен отдельный сценарий.
Детализация должна соответствовать следующему вопросу. Иногда достаточно карточки платежа, а иногда после выбора проекта нужен полноценный аналитический обзор с динамикой, отклонениями и командой.
Ручные фильтры стоит сохранить, но не делать обязательными для каждого просмотра. Готовые периоды, выбор проекта прямо на экране, сохранение настроек и избранное позволяют не начинать повторную проверку с нуля.
Десктопная аналитика при этом остаётся инструментом подробного исследования. Мобильные дашборды дают другой способ работы с теми же данными: открыть нужный вопрос, увидеть подготовленный срез и при необходимости перейти к источнику цифры.
Комментарии 0