YMS (Yard Management System) — система управления очередью автомобилей и складским двором распределительного центра. Коробочное решение, использовавшееся ранее, имело ряд ограничений: устаревший интерфейс, частые сбои, неэффективная поддержка со стороны вендора и невозможность гибкой адаптации под изменяющиеся процессы РЦ.
В январе 2025 года я присоединилась к проекту в роли продуктового дизайнера. Наша стартовая команда состояла из продакта, системного аналитика и меня. Мы работали в плотной связке, чтобы с нуля спроектировать собственную систему, учитывающую как потребности бизнеса, так и реальные сценарии пользователей на территории распределительного центра.
Моя роль включала полный цикл: от погружения в процессы и формирования пользовательских сценариев до визуального дизайна, создания UI-кита по дизайн-системе X5 и поддержки внедрения решений.
Проект стартовал с очевидного запроса бизнеса: заменить устаревшее коробочное решение, которое не соответствовало ни современным требованиям, ни текущим задачам распределительного центра. Однако на старте нам предстояло решить сразу несколько серьёзных вызовов:
<aside> 🎯
Цель по SMART
Разработать собственную YMS-систему для управления транспортом на территории РЦ, с полной интеграцией в существующую инфраструктуру и запуском MVP на пилотном складе в течение 4 месяцев, с последующим масштабированием на сеть складов компании.
</aside>
<aside> 📌 Основные цели и показатели успеха:
На старте проекта я погрузилась в изучение текущего коробочного решения: детально проанализировала доступную документацию и просмотрела более 40 часов обучающих видео, предназначенных для сотрудников распределительного центра. Это позволило не только понять существующий функционал, но и выявить ключевые узкие места: сотрудники часто путались в интерфейсе, задавали повторяющиеся вопросы и не могли интуитивно завершать базовые действия.
Основываясь на этих наблюдениях, мы с аналитиком и продукт-оунером составили подробный бэклог. Были сформулированы бизнес-требования, определены технические ограничения, а также зафиксирован приоритетный функционал, который необходимо реализовать в первую очередь. Такой подход позволил заложить прочную основу для будущей продуктовой работы и определить ориентиры для проектирования пользовательских сценариев.
| Персона | Контекст работы | Цели | Основные боли |
|---|---|---|---|
| Водитель ТС | Прибытие на РЦ для загрузки/выгрузки. Использует планшет/терминал для регистрации. | Быстро пройти регистрацию, понимать дальнейшие действия, сократить время визита | Неясный порядок действий, сложность в интерфейсе, ожидание без уведомлений |
| Сотрудник ЧОП | Проверка документов, контроль пропуска/выпуска ТС через КПП. Работает с визитами, стоп-листами и идентификацией. | Проверка и фиксация данных по ТС и водителю, быстрое принятие решения о доступе | Мало информации по визиту, ручной ввод, задержки из-за отсутствия автоматизации |
| Сотрудник СДО | Принимает и оформляет сопроводительные документы, вызывает водителей, назначает ворота. | Быстрая работа с документами, контроль статуса визитов, точный вызов водителей | Разрозненные действия в интерфейсе, отсутствие единого окна, путаница в статусах |
| Менеджер приёмки | Управляет постановкой машин на ворота через генплан, следит за очередями. | Оптимальное распределение ресурсов, избежание простоев | Нет визуализации доступных слотов и статусов, перегруженность интерфейса |
| Оператор склада | Осуществляет приёмку/отгрузку товаров, сканирует продукцию, может отказать в приёмке. | Эффективное выполнение операций, быстрое завершение сессий приёмки или загрузки | Ошибки в назначении визитов, нет сигналов о готовности, неудобства при отказах |
| Диспетчер РЦ | Подтверждает прибытие на загрузку, управляет назначением ворот, может отклонить рейс. | Соблюдение графика отгрузок, контроль хода визитов и загрузки | Ограниченная гибкость интерфейса, нет визуального контроля за процессом |