Кейс: Дилерский портал сантехники

Отрасль и клиент

Рынок и задача

Клиент — региональный дистрибьютор сантехники в Беларуси. Он работает с дилерскими салонами, розничными магазинами, монтажными организациями и небольшими строительными компаниями. Закупщик дилера собирает заказ на пополнение салона и комплектацию нескольких объектов сразу: санитарная керамика, мебель для ванных, смесители, душевое оборудование, инсталляции, комплектующие и запасные части. Дистрибьютор автозапчастей ведёт подбор автозапчастей по VIN для автосервисов.

Это не закупочный проект объекта для монтажников: там бригада комплектует конкретный узел на объекте. Здесь единица работы — заказ организации у дистрибьютора: договорной ассортимент, кратность упаковки, два склада отпуска и подтверждённый резерв. Когда «интернет-магазин» на деле оказывается бизнес-системой — в интервью Почему бизнесу иногда нужен Laravel, а не WordPress.

Портал не заменяет учётную систему. Остатки, договорные условия, резервы и документы остаются в существующем контуре. Два склада клиента — точки доступности номенклатуры, а не выбор площадки под технологический процесс: такой контур закрывает подбор склада и производства.

Масштаб первой версии

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

Роли

Складские сотрудники продолжают работать в учётной системе. Портал показывает полученные статусы и не создаёт второй складской интерфейс.

Как было

Заказ существовал сразу в четырёх версиях

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

Семь шагов без общей версии

1. Дистрибьютор выгружал каталог и остатки.
2. Дилер копировал позиции в собственную таблицу.
3. Менеджер вручную проверял артикулы, кратность упаковки и доступность.
4. Недоступные позиции возвращались дилеру на замену.
5. Решение фиксировалось в письме или сообщении, но не в исходном заказе.
6. После очередного изменения проверка повторялась.
7. Подтверждённый состав заново переносился в учётную систему.

Корневая проблема

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

Центральная сущность продукта — не форма отправки и не каталог, а совместная рабочая область дилерского заказа.

Решение

Заказ объединяет организацию, строки, доступность, упаковку, совместимость, замены, резерв и журнал решений в одной версии.

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

Система проверяет формальные правила и показывает отклонения. Дилер принимает решения по ассортименту. Региональный менеджер вмешивается только там, где автоматического правила недостаточно.

Как работает новый процесс

1. Закупщик создаёт заказ вручную, из шаблона или повторяет ранее завершённый.
2. Добавляет товары поиском по артикулу, названию, серии, назначению и характеристикам.
3. Портал сразу показывает доступность, упаковку, обязательные компоненты и ограничения совместимости.
4. Для недоступной позиции система предлагает разрешённые аналоги, но не подменяет товар без подтверждения.
5. Закупщик устраняет предупреждения и отправляет заказ на проверку.
6. Портал создаёт резерв в учётной системе и фиксирует результат по каждой строке.
7. Исключения попадают в очередь менеджера: конфликт условий, нет разрешённой замены, раздельная доступность по складам, неполные данные.
8. Менеджер предлагает решение внутри заказа; дилер принимает или отклоняет его, выбор сохраняется в журнале.
9. После подтверждения состав версии блокируется и передаётся в учёт.
10. Дилер видит этапы подготовки и получает уведомление, когда нужно следующее действие.

Система не решает, подходит ли иной дизайн для проекта дилера, не объединяет отгрузки с разных складов без согласования и не подменяет товар только из-за совпадения части характеристик.

Основные сценарии

Главный интерфейс: рабочая область заказа

После входа закупщик возвращается в последний активный заказ или в список с явным следующим действием. Сводные графики не являются точкой входа.

Четыре зоны экрана: шапка (организация, адрес получения, способ комплектации, ответственный, общий статус); таблица строк (товар, количество, упаковка, доступность, склад, совместимость, состояние); панель исключений — только то, что мешает подтверждению; история решений.

Главное действие зависит от состояния: «Исправить 3 исключения», затем «Отправить на резерв», затем «Подтвердить заказ». Пользователь не угадывает следующий шаг.

Каталог в контексте этого заказа

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

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

Очередь исключений для менеджера

Большинство корректных заказов проходят без участия менеджера. Главный экран — очередь отклонений: какой заказ остановился, что мешает, сколько ждут решения, какое действие ожидается. Та же логика management by exception, что и очередь отклонений клининговой сети, только единица работы здесь — строка дилерского заказа, а не задание на уборку.

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

Бизнес-правила

Состояния и версии

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

Упаковка и совместимость

Количество проверяется по кратности; автоматическое округление требует подтверждения. Совместимость пересчитывается при добавлении и при изменении связанной позиции. Замена — только из утверждённой группы аналогов или после предложения менеджера.

Резерв и права

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

MVP

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

ИИ не является ключевой частью первой версии. Правила совместимости и замены требуют объяснимых справочников. Позже модель может помогать нормализовать входящие таблицы или искать похожие товары по неполному описанию — с проверкой сотрудника.

UX, стек и план

Рабочая область вместо витрины

Ценность появляется после выбора товара. Закупщик возвращается в заказ и видит исключения и следующее действие. Цвет статуса относится к строке, а не к рекомендации «купить этот артикул».

Архитектура

Выбран профиль единого операционного B2B-приложения: насыщенные таблицы, фильтры и боковые панели без отдельного frontend-сервиса. Обмен с учётом — обмен каталогом, остатками и резервом с учётом: портал получает номенклатуру, доступность, жизненный цикл товара и результат резервирования; обратно передаёт проверенный заказ и идентификаторы подтверждённой версии. Пакет имеет технический идентификатор и журнал ошибок, повторный запуск не создаёт дубликаты.

План на 16 недель

Срок первой рабочей версии и пилота — 16 недель. Внедрение начинается не со всех дилеров и категорий: главный риск — качество справочников и параллельный процесс в таблицах.

Метрики

Цифры — результаты пилота на одной товарной категории и сопоставимых типах заказов: повторное пополнение матрицы до запуска и после стабилизации процесса. Заказы, сознательно проведённые по аварийному каналу из-за недоступной категории или длительного сбоя обмена, из сравнения исключались.

Риски и выводы

Риски

Развитие после пилота

1. Шаблоны ассортиментных матриц по типам дилеров.
2. Проектные заказы с группировкой по помещениям — после устойчивого простого заказа.
3. Загрузка дилерской таблицы с предварительным сопоставлением артикулов.
4. API для сетей, которые формируют заказ в собственной системе.
5. Претензии с привязкой к строке поставки и документам.
6. Рекомендации комплектов на основе правил и истории, без автоматического применения.
7. Аналитика причин остановки заказов для справочников и ассортимента.

Как изменилась работа

Главный результат — не перенос формы заказа в браузер. Портал создаёт общий операционный контур между дилером и дистрибьютором: состояние каждой позиции объяснимо, следующее действие видно, подтверждённый состав можно восстановить без звонков.