Из legacy-системы в современную TMS
01. ОБЗОР
Кейс о том, как отказ от устаревших решений в пользу прозрачной приоритизации и потоковой обработки задач помог логистическому терминалу минимизировать простои транспорта и просрочки хранения.
Примечание: в кейсе затрагивается лишь часть системы (заявки и трекинг). Смежные модули (WMS, клиентский портал, приложение водителей) вынесены за скобки, чтобы не перегружать кейс.
О продукте
Продукт создавался для операторов таможенно-складских комплексов «Карго Плюс» — это крупный логистический хаб, куда непрерывно приходят поезда с грузами из Китая, Индии и Турции.
Интерфейс помогает операторам решать основные задачи в режиме одного окна:
- Контроль приоритетов: оперативное выявление критичных грузов, нарушающих сроки хранения.
- Упрощение проверок: доступ ко всем данным в одном окне, приспособленном для сканирования.
- Эффективное планирование: карта движения грузов и таймеры истечения сроков, для понимания и планирования картины рабочего дня.
02. МОЯ РОЛЬ
Управление вниманием
Главной проблемой операторов была неопределенность: за что взяться в первую очередь, где не хватает документов и горят сроки? На эти поиски уходило ценное время.
Моей задачей стало направлять внимание пользователя. Опираясь на приоритизацию данных и триггеры SLA, нам удалось сделать так, чтобы оператор мгновенно видел критичные риски и действовал без задержек.
Критерии успеха
Успех проекта определялся снижением операционных рисков и ускорением обработки задач:
- Сокращение простоев: предотвращение просрочек хранения для роста пропускной способности терминала и защиты от операционных сбоев.
- Ускорение обработки (SLA): сокращение времени поиска проблемных точек и принятия решений.
- Минимизация ошибок: минимизация человеческого фактора при проверках дкументов и работе с заявками.
Рисковые грузы -56%
Визуальная приоритизация ускорила реакцию операторов на рисковые грузы, позволив предотвращать срывы сроков до их наступления.
Сроки простоя -33%
Наглядные дедлайны и перераспределение задач с неактивных операторов сократили среднее время простоя грузов на терминале.
Время на заявку -38%
Оптимизация интерфейса и формат «одного окна» сократили рутинную нагрузку при разборе документов: оператор быстрее находит нужные данные, не переключаясь между системами.
Процент ошибок 9% → 5%
Новая вёрстка данных заявки и выделенный блок триггеров рисков упростили беглую сверку информации, сведя к минимуму ошибки из-за человеческого фактора.
Примечание: Оценки получены по итогам пилотного внедрения продукта на терминале в течение первых двух месяцев после запуска.
3. КЛЮЧЕВЫЕ ВЫЗОВЫ
Разрозненность исходных данных
В чём была сложность:
Данные хранились в разных источниках с частичным дублированием: например, контейнеры в пути фигурировали и в реестре поездов, и в отдельной базе, но в разных форматах. SLA и документы по заявке отслеживались обособленно. Моей задачей было структурировать эту логику и упаковать разрозненный массив информации в чистый, сфокусированный UI.
Как я это решил:
Вместе с аналитиками систематизировал данные и спроектировал прозрачную UI-архитектуру на основе CJM и Data Mapping. Это позволило выделить ключевые акценты и собрать на каждом этапе работы только ту информацию, которая необходима оператору для принятия решений.
Примечание: часть сценария по выявлению нарушения сроков хранения и определения первичного скрипта действий.
Максимизация рабочего пространства
В чём была сложность:
Требование к максимальной полезной площади продиктовано сразу двумя факторами: плотностью табличных данных и логикой «одного окна» при обработке заявок. Чтобы оператор мог одновременно работать с документами, параметрами заявки и метаинформацией, требовался каждый доступный пиксель интерфейса.
Как я это решил:
Одним из решений стало свёрнутое состояние сайдбара по умолчанию. При выполнении рутинных операций оператор совершает переходы механически, поэтому фиксированное меню избыточно. Это позволило отказаться от горизонтального скролла и вместить все необходимые данные даже на небольших экранах.
04. Исследования
Метод Shadowing
Чтобы увидеть реальный контекст без искажений, я провёл серию очных сессий наблюдения за операторами. Зафиксированный порядок работы вскрыл узкие места и лёг в основу CJM.
Примечание: обычные интервью на старте показали свою неэффективность — операторы упускали детали, о которых не привыкли задумываться. Заполнить эти пробелы получилось только через очное наблюдение.
Организация
процесса
Терминал — режимный объект. Потребовалось убедить заказчика в пользе такого подхода, чтобы получить пропуска прямо в рабочие зоны.
Фокус наблюдения
В процессе работы я фиксировал следующие аспекты:
- Процессы: рутина, порядок действий и места, где процесс спотыкается.
- Данные: с какими источниками, документами и информацией оператор работает на каждом шаге.
- Лайфхаки и костыли: как люди на местах адаптируют систему под себя и обходят неудобства.
- Рабочее окружение: используемый софт, мониторы и физическая эргономика места.
Участники
В наблюдении участвовали 3 оператора терминала с разным стажем — от новичка до ветерана с 10+ годами опыта. Это позволило в одном срезе увидеть как барьеры адаптации, так и автоматизированные привычки.
Особенности операторов логистики:
- Постоянно на телефоне: часто отвлекаются на звонки и уточнение информации.
- Негативно воспринимают изменения: любые апдейты UI ломают паттерны и вызывают сопротивление — «раньше было лучше».
- Нелинейны в процессах: регулярно сталкиваются с разрывом контекста. Задачи встают на паузу в ожидании документов, ответа клиента или подтверждения от склада.
Гипотезы
Строго следуют регламенту
Не подтверждена
Операторы действуют строго по инструкции и точно исполняют прописанный регламент действий.
Реальность: скорость и деловые отношения важны операторам больше формального процесса. Они часто срезают углы, ищут обходные пути и действуют по ситуации, если система их тормозит.
Высокая доля цифровизации
Не подтверждена
Операторы полностью отказались от бумаги и работают только в цифровом контуре.
Реальность: бумага остается мощным параллельным интерфейсом. Столы завалены распечатками, стикерами и рукописными заметками, потому что зафиксировать что-то «на лету» на бумаге пока что единственная возможность.
Высокая когнитивная нагрузка
Подтверждена
Операторы перегружены потоком входящих данных и из-за постоянных отвлечений теряют контекст задач. При возврате к заявке им приходится заново вспоминать, на чём они остановились и что делать дальше, что снижает продуктивность.
Фокус на главном
Подтверждена
Для быстрого решения на каждом этапе оператору нужен только минимальный набор данных, а не весь объём информации. Избыток данных в интерфейсе создаёт шум: чем меньше лишних полей и деталей на экране, тем быстрее оператор принимает решение и тем ниже вероятность ошибки.
Инсайты
Лояльность к клиентам
Бизнес-процесс допускает выпуск груза до получения оплаты или полного пакета документов, поскольку чаще всего строится именно долгосрочное партнёрство. В таких случаях оператор самостоятельно загружает сканы документов и согласовывает отгрузку под гарантии.
Работа на автопилоте
Высокая интенсивность рутины быстро формирует у операторов привычки поведения. Когда человек день за днём выполняет один и тот же сценарий, он начинает кликать «вслепую» по знакомым областям экрана, действуя на автопилоте и переставая вчитываться в детали и подсказки.
Аналоговый кэш
Оперативные договоренности (кому перезвонить, когда пришлют гарантийное письмо, почему сделано исключение) часто фиксируются на стикерах, в личных блокнотах и мессенджерах — в «аналоговом кэше» оператора. При ротации операторов или болезни сотрудника этот важный для работы контекст теряется.
Режим «тушения пожаров»
Операторы планируют смену, но постоянные незапланированные события — от срыва сроков хранения до опозданий поездов — мгновенно ломают линейный план оператора. В результате происходит переход в режим реактивного аврала: текущую рутина откладывается, а просроченные контейнеры спасаются в первую очередь.
Оценка текущих проблем
Накопившийся массив «болей» пользователей и запросов бизнеса потребовал чёткого фильтра и приоритетов. С помощью матрицы Impact vs. Effort мы сопоставили бизнес-эффект от реализации фич со сложностью разработки и сформировали роадмап.
Low-High Imapct/Low Effort
Быстрые победы
Сюда вошли задачи с невысокой сложностью разработки, а также дизайн-решения, которые закрывают важные «боли» без усложнения технической реализации. Они позволяют получить максимальный бизнес-эффект при минимальных затратах ресурсов разработки.
High Impact / High Effort
Стратегический фокус
Фичи с высокой бизнес-ценностью вынесены в стратегический бэклог. Из-за необходимости внедрения новых паттернов и механик для них запланированы отдельные этапы Discovery, UX-проработка и итеративный план разработки.
Low Impact / High Effort
Отсечение лишнего
Задачи с минимальным влиянием на бизнес-метрики, но экстремально высокие по трудозатратам. Сюда вошли как нишевые сценарии, так и трендовые, но ресурсоёмкие гипотезы (ИИ, голосовой ввод). Мы сознательно отложили их, чтобы гарантировать своевременный релиз.
05. UX-РЕШЕНИЯ
Приоритизация данных
Первым делом мы пересобрали таблицы — на них строился почти весь интерфейс. У них было две проблемы: всё выглядело одинаково, глаз замыливался и не цеплялся за главное. Вторая проблема — лишние второстепенные данные, которые забивали экран и мешали заметить срочную задачу.
Legacy-инструмент спроектирован как сырая база данных: на экран выведены десятки полей одинакового визуального веса. Системные ID и служебная инфомарция перемешаны с критическими статусами и датами. Без визуальной иерархии оператор тратит время на ручной поиск нужных параметров глазами, что тормозит работу и ведёт к задержкам.
Новый интерфейс смещает фокус с пассивного просмотра таблицы на быстрое принятие решений. Вместо плоского реестра оператор получает инструмент с чёткой визуальной иерархией:
- Счётчики основных показателей: наверх вынесены агрегированные метрики по критичным контейнерам (досмотр таможни, риски просрочки и др.). Это даёт оператору моментальную картину верхнего уровня и подсвечивает узкие места без обращения к списку.
- Фильтрация фонового шума: информацию по каждому контейнеру структурировали и оставили на первом плане только те атрибуты, которые необходимы для первичного решения. Вся вторичная и служебная информация убрана во внутренний блок с подробными данными.
- Переформатирование данных: вместо текста используем индикаторы сущностей. Например, вместо громоздкого номера документа выведен лаконичный чекбокс его наличия/отсутствия — именно этот факт первичен для принятия решения, а саму информацию по документу можно увидеть при ховере иконки.
Механика распределения задач
Проектируя распределение задач, мы первым делом проверили гипотезу о полной автоматизации — важно было сверить работу алгоритма с реальными процессами операторов.
Первоначальной гипотезой был ввод полной автоматизации: система должна была распределять заявки, чтобы исключить человеческий фактор и предотвратить выбор только «простых» или «выгодных» задач. Однако исследования показали, что автоматический режим разрушает сложившиеся процессы:
- Потеря персонального контакта: операторы годами выстраивают рабочие отношения с постоянными клиентами, знают специфику их грузов и имеют прямые контакты для оперативного решения проблем.
- Снижение скорости: при случайном распределении оператору приходилось заново вникать в нюансы чужого клиента, что затягивало обработку.
Карточка заявки
Раньше операторы видели единый массив заявок и были вынуждены вручную отслеживать, кто какую ведёт. То теперь на экране отображаются только задачи без исполнителя и личный пул оператора «Мои заявки», что исключает отвлечение на чужую работу.
Из громоздкой таблицы на 30+ параметров мы оставили только основные поля, необходимые для первичного решения о выборе заявки.
Список заявок
Правая часть экрана выступает персональным хабом оператора, где статусные теги и таймеры позволяют мгновенно оценить прогресс и приоритетность задач.
Здесь же отображены завершённые и отклонённые заявки. Это осознанный шаг: при разборе претензий или инцидентов оператору нужно быстро вернуться к недавно закрытым заявкам, при этом активные заявки имеют приоритет и всегда находятся наверху списка.
Реализация принципа «одного окна»
На экране одобрения заявки мы полностью убрали переключение контекста. Вместо работы в разных вкладках: интерфейсе оператора, PDF-Veiwer и почте — весь цикл принятия решений сфокусирован в единой рабочей зоне.
Метаинформация
Контрольный блок для принятия решений. Сюда вынесены важные риски и основное целевое действие. Ещё мы добавили возможность менять статус заявки и оставлять комментарии прямо в карточке, чтобы минимизировать число стикеров и записок на столе.
Информация по заявке
Ядро заявки полностью переработано: данные о грузе, маршруте и логистике теперь сгруппированы по смысловым блокам. Благодаря этому оператор быстрее считывает информацию и не упускает важные детали при проверке данных.
Просмотр документов
Оператор может просматривать и сверять документы прямо в заявке, без скачивания и сторонних приложений. Из важных нюансов — индикатор комплектности: система сразу подсвечивает, если число файлов не совпадает с минимумом для одобрения заявки.
Мы протестировали два подхода к представлению данных. Первый выводит информацию полностью, но рассеивает внимание. Во втором применили вертикальную структуру размещения данных: взгляд сканирует значения сверху вниз по прямой траектории, что ускоряет проверку.
Полные данные доступны по ховеру, хотя в 90% случаев они не нужны: оператор считывает суть по первым словам. Взамен мы получили строгую вертикальную ритмику, которая компенсирует редкие сокращения.
Интерактивная карта вместо таблицы
Чтобы снизить когнитивную нагрузку и дать мгновенную аналитику, мы заменили табличный реестр поездов в пути на интерактивную карту, что повысило скорость считывания статусов контейнеров и поездов в пути.
Табличный формат заставлял оператора вручную сопоставлять станции, номера поездов, номера контейнеров и тайминги, чтобы оценить общую картину движения. Карта превращает сухие данные в наглядный контекст: оператор сразу видит географию маршрутов, узлы задержек и текущий статус.
Варианты Layout
Пример итеративной работы по поиску наилучшего решения, где мы последовательно проверили несколько вариантов вёрстки.
Таблица на всю ширину внизу экрана
Оказалась неэффективной из-за малого числа атрибутов по поездам и грузам — свободное пространство экрана простаивало. Дополнительно решение требовало реализации вложенных раскрывающихся списков (accordion/row expansion), что избыточно усложняло разработку, не давая ощутимого UX-эффекта.
Повторение паттерна других страниц
Попытка использовать паттерн других страниц, где карта размещалась в отдельном фрейме под заголовком, оказалась неэффективной: верхняя часть интерфейса занимала полезную площадь экрана, а при раскрытии списка контейнеров карта сдвигалась и меняла размер.
Фоновая карта с оверлей-панелью
Карта занимает 100% рабочей области. Поверх неё размещена компактная панель с вертикальным списком поездов и двухуровневой иерархией (раскрытие состава контейнеров по клику). Это дало максимальный фокус на гео-контексте при сохранении быстрых фильтров и поиска.
06. UX-ТЕСТЫ
Валидация логики и минимизация рисков
Стратегия тестов строилась на принципе «Fail fast, learn faster»: мы привлекали операторов еще на этапе варфреймов. Это позволило за считаные дни отсекать нежизнеспособные концепты и уберегло команду от дорогостоящих переделок на этапе разработки.
Что мы учитывали:
Закон Парето
Начав тестирование на этапе варфреймов мы с помощью небольших усилий смогли избежать дорогих изменений на финальном этапе создания продукта.
Проверка на поздних этапах
Вариант тестирования полностью отрисованного интерфейса нам не подошёл. Визуальный слой отвлекает от проверки логики, особенно в интерфейсах с высокой плотностью данных. Операторы цепляются за детали, а архитектурные ошибки всплывают позже, требуя перекройки уже готового продукта.
Тестирование на ранних стадиях
Мы начали с варфреймов, чтобы проверить исключительно логику сценариев, наполненность и формат данных. Операторы оценивали сами данные, их формат и последовательность действий, не отвлекаясь на «красоту». Выявив системные ошибки на ранних этапах, мы свели риски дорогих последующих изменений к минимуму.
07. ИЗМЕРЕНИЕ ЭФФЕКТА
Отслеживаем результаты
Работа оператора нелинейна, поэтому замерить чистое время обработки заявки без прямого присутствия крайне сложно. Чтобы получить объективные данные, мы применили несколько инструментов.
Прямой замер времени
Проводили контрольные замеры скорости работы непосредственно на рабочем месте. Сравнивали время обработки идентичных по сложности и составу данных заявок в старом и новом интерфейсах.
Контроль ошибок
Осуществляли мониторинг пользовательских и системных ошибок в Grafana, анализируя данные с бэкенда. Это позволяло оперативно анализировать возникающие проблемы.
Регулярные опросы
Внедрили систему постоянного сбора индекса удовлетворенности пользователей. Регулярные опросы помогли отслеживать динамику адаптации операторов и вовремя фиксировать проблемные места.
Какие цифры получили
Чтобы оценить реальный эффект, мы сравнили основные показатели системы до начала разработки и в течение двух месяцев после релиза.
Было
Legacy-система
27 случаев – среднее число задержек в месяц из-за несвоевременного выявления рисков.
3 дня – средние сроки простоя контейнера из-за проблем с заявкой.
13 мин 42 сек – среднее время оформления типичной заявки.
9% – ошибки из-за человеческого фактора (сверка документов).
Стало
Новый интерфейс
12 случаев – среднее число задержек в месяц из-за несвоевременного выявления рисков.
2 дня – средние сроки простоя контейнера из-за проблем с заявкой.
8 мин 31 сек – среднее время оформления типичной заявки.
5% – ошибки из-за человеческого фактора (сверка документов).
08. ЗАКЛЮЧЕНИЕ
Подводим итоги
Этот проект оказался непростым, но действительно интересным вызовом. Наибольшую сложность вызвали начальные этапы: систематизация и сбор данных из legacy-системы. Однако именно системный подход на старте позволил успешно завершить проект.
Чему научился:
- Есть продукты, где формализм оправдан: система жестко блокирует шаг без выполнения всех условий. Но есть сервисы, где скорость и деловые отношения важнее процедур. Задача дизайнера — точно определить контекст и создать рабочий инструмент, а не новый барьер.
- Автоматизация не всегда лучший путь. Выбор заявок вручную оказался эффективнее алгоритма: автоматика не может знать весь контекст, поэтому полезно оставлять гибкие рычаги управления.
Что бы сделал иначе:
- Запросил бы регламенты до старта исследований, чтобы заранее погрузиться в рабочие процессы. При чистой реализации метода shadowing я на старте только наблюдал за работой операторов. Знакомство с документами помогло бы точнее интерпретировать наблюдения.
- Заложил бы дополнительное время на Discovery. Стартовый план опирался на прошлый опыт и не учитывал реальную специфику процессов. При работе с большим legacy важно закладывать время на глубокое погружение.
