Специалист по подбору
Собирает проверенный комплект, фиксирует применимость, предлагает версии и запускает резерв.
Ограничение
Главный экран — очередь заявок, а не обзорная панель.
Кейс: Портал подбора автозапчастей
Закрытый B2B-портал дистрибьютора, где единица работы — заявка на подбор: VIN, работы, версии комплекта, согласование и резерв. Портал замыкает контур от потребности автосервиса до однозначного задания складу.
Карточка проекта
Содержание
Отрасль и клиент
Рынок и задача
Клиент — региональный дистрибьютор автозапчастей. Он работает с независимыми автосервисами: мастер-приёмщик присылает VIN, пробег, перечень работ и фотографии, специалист поставщика уточняет комплектацию, ищет оригинальные номера, сравнивает аналоги и проверяет остатки. Для салона у оптовика единица работы — дилерский заказ у дистрибьютора сантехники. Для автосервиса единица работы — заявка на подбор: VIN, работы, версии комплекта и резерв.
Проблема не сводится к медленному поиску по каталогу. Пока сервис согласовывает вариант с владельцем автомобиля, часть позиций заканчивается. При замене одной детали приходится заново проверять весь комплект. Заказ хранит артикулы и количество, но не хранит контекст: почему выбраны именно эти позиции и какие альтернативы уже отклонены.
Портал не заменяет учётную систему, каталоги поставщиков или складской контур. Он становится рабочим слоем между обращением автосервиса и созданием заказа: собирает разрозненные данные, делает решение проверяемым и передаёт согласованный результат в существующие системы. Для шинного центра другой контур той же ниши — подбор комплекта шин и запись на шиномонтаж: там типоразмер и слот установки, здесь VIN, работы и версии ремонтного комплекта.
Масштаб первой версии
Сотрудники поставщика35
Автосервисы~180
Заявки на подбор250–350 / день
Пилот15–17 нед.
| Показатель | Значение |
|---|---|
| География | Беларусь и близкий по практике рынок СНГ |
| Сотрудники поставщика | 35 |
| Активные автосервисы | ~180 |
| Заявки на подбор | 250–350 в рабочий день |
| Контур пилота | 5–7 автосервисов с регулярными заявками |
| Основной процесс | От потребности автосервиса до согласованного и зарезервированного комплекта |
| Формат продукта | Закрытый B2B-портал и рабочее пространство отдела подбора |
Эти значения нужны для проверки интерфейсов, прав доступа и фоновых операций, а не являются фактическими показателями конкретной компании.
Роли
Мастер-приёмщик
Создаёт заявку по VIN и работам, отвечает на уточнения, согласует конкретную версию комплекта.
Ограничение
Короткие действия с телефона между работой с автомобилями, без знания точных артикулов.
Комплектовщик склада
Собирает актуальную подтверждённую версию: артикул, количество, ячейка, склад.
Ограничение
Не меняет аналог самостоятельно: расхождение возвращает заявку специалисту.
Руководитель отдела
Видит заявки без ответственного, просроченные проверки и исключения, где процесс остановился.
Ограничение
Управляет отклонениями, а не всеми открытыми обращениями подряд.
Как было
Обращение начинается с VIN в мессенджере
Типовой процесс начинается без единой точки входа. Один сервис присылает VIN текстом, другой — фотографию свидетельства о регистрации, третий диктует данные по телефону. Перечень деталей выглядит как список артикулов, названия узлов или фраза «всё для замены ГРМ». Специалист сначала восстанавливает исходные данные, затем работает сразу в нескольких системах.
Девять шагов из переписки
- Мастер-приёмщик отправляет VIN, модель автомобиля и список работ.
- Специалист поставщика переписывает данные в заметку или внутреннюю таблицу.
- По VIN и параметрам определяется модификация, двигатель, дата выпуска и ограничения применимости.
- В каталогах находятся оригинальные номера и возможные аналоги.
- В учётной системе проверяются остатки, склады и ожидаемые поступления.
- В мессенджер уходят один или несколько вариантов.
- После ответа клиента специалист вручную восстанавливает актуальный состав.
- Согласованные артикулы переносятся в заказ и резервируются.
- Склад обнаруживает недоступную или неоднозначную позицию уже при комплектации.
Где возникает операционный риск
| Наблюдаемая ситуация | Корневая причина | Последствие |
|---|---|---|
| VIN есть в переписке, но отсутствует в заказе | Обращение и заказ существуют отдельно | Нельзя восстановить основание подбора |
| Клиент согласовал один вариант, а в заказ перенесли другой | Нет зафиксированной версии комплекта | Спор о составе заявки |
| Аналог подходит к модели, но не к конкретной модификации | Применимость проверяется вне рабочего объекта | Ошибка после выдачи или во время ремонта |
| Пока клиент отвечает, остаток меняется | Согласование не связано с резервом и сроком его действия | Приходится пересобирать комплект |
| Одна позиция недоступна на основном складе | Доступность проверяется построчно, без оценки всего комплекта | Заказ разбивается на несколько сроков и складов |
| Специалист заболел или сменился | Логика выбора хранится в личной памяти и сообщениях | Коллега повторяет подбор с нуля |
Корневая проблема
На каждом переходе теряется часть контекста. В заказ может попасть артикул без ограничения по дате выпуска. Согласованный аналог остаётся сообщением между фотографиями. Замена на более доступную позицию меняет не одну строку, а связку компонентов: тормозные диски, колодки и датчик износа. При повторном обращении история подбора почти не помогает — специалист снова начинает с VIN и каталога.
Центральная сущность продукта — не каталог и не сообщение в чате, а заявка на подбор.
Решение
Заявка на подбор объединяет автомобиль, работы, позиции комплекта, варианты, наличие, согласование, резерв и следующее действие в одной рабочей области.
В заявке фиксируются идентификация автомобиля и подтверждённая конфигурация, перечень ремонтных работ, позиции комплекта и связи между ними, найденные варианты с уровнем уверенности в применимости, наличие по складам и срок актуальности данных, решение специалиста и основание выбора, согласование автосервиса, резерв и статус комплектации, история версий и действий.
Состояния заявки: «Черновик» → «Нужны данные» → «В подборе» → «Требует проверки» → «Отправлена на согласование» → «Согласована» → «Резервируется» → «Готова к комплектации» → «Закрыта». Отдельные исключения не смешиваются с основным статусом. Система показывает сигналы: «VIN распознан не полностью», «Есть конфликт применимости», «Остаток изменился», «Согласование истекает», «Резерв частичный», «Комплект требует одного склада». Очередь сортируется по следующему действию, а не по дате последнего сообщения.
Как работает новый процесс
- Автосервис создаёт заявку: сохранённый автомобиль или новый по VIN, планируемые работы, обязательные параметры товарной группы.
- Заявка попадает в очередь отдела подбора. Приоритет зависит от срока ответа, полноты данных, истории автомобиля и типа исключения.
- Специалист собирает комплект: оригинальный номер, допустимые аналоги, источник проверки, ограничение применимости, связи между позициями.
- Автосервис согласует версии комплекта — «Оптимальный срок», «Минимум замен», «Допустимые аналоги» — а не набор сообщений.
- После подтверждения система повторно проверяет доступность и запускает резерв. Изменение остатка возвращает исключение с контекстом.
- Склад комплектует однозначный состав актуальной версии. Расхождение создаёт структурированное исключение без звонка.
Система не принимает решение о совместимости вместо специалиста. Она подсвечивает противоречия, обязательные параметры и ранее проверенные комбинации. Финальное подтверждение остаётся за сотрудником, действие записывается в журнал.
Основные сценарии
Создание заявки автосервисом
Мастер выбирает автомобиль по VIN, указывает работы вроде «замена передних тормозных дисков и колодок» или «обслуживание ГРМ», прикладывает фотографии. Неполная заявка получает статус «Нужны данные» и список вопросов.
Результат: специалист видит потребность, а не буквальный список из сообщения.
Сборка проверенного комплекта
В рабочем пространстве одновременно видны автомобиль, потребность, дерево позиций и панель вариантов. Для связанного набора действует правило: если меняется основной компонент, зависимые позиции возвращаются на проверку. Комплектация узла объекта — закупочный проект сантехники для монтажных бригад.
Результат: комплект держит связи между позициями, а не набор независимых строк.
Согласование версии
Клиент получает варианты с операционным отличием: все позиции на одном складе, сохранённые производители с разбитой поставкой или замены в пределах подтверждённой применимости. Подтверждение относится к конкретной версии.
Результат: последующее изменение создаёт новую версию и требует повторного согласования только затронутых позиций.
Резерв после подтверждения
Система повторно проверяет доступность. Если все позиции доступны, создаётся запрос на резервирование. Если остаток изменился, специалист видит, какая позиция выбыла, какие проверенные альтернативы существуют и какие зависимые строки перепроверить.
Результат: «есть на складе» не равно «зарезервировано».
Комплектация однозначного состава
Комплектовщик видит артикул, количество, ячейку, склад, допустимость частичной выдачи и особые отметки. При расхождении создаёт исключение «Не найдено в ячейке» или «Повреждена упаковка».
Результат: склад не уточняет состав по телефону и не теряет историю.
Исключение вместо скрытой ошибки
VIN не распознан, модификация неоднозначна, каталог противоречит параметру автомобиля, нет допустимой замены, остаток изменился после согласования, резерв распределён между складами.
Результат: руководитель видит заявки, где процесс не может продолжиться, а не все обращения подряд.
Рабочее пространство специалиста
Главным экраном становится очередь заявок. Слева — сохранённые представления: новые и неразобранные, нужны данные, конфликт применимости, изменился остаток, ожидают согласования, резерв частичный, мои просроченные. В таблице — номер, автосервис, автомобиль, работы, полнота данных, статус, обещанный срок и следующее действие. Цвет используется только для статусов и риска срока.
Карточка строится из трёх областей: контекст автомобиля и заявки; дерево комплекта со статусом проверки каждой строки; варианты и действия — применимость, наличие, склад, срок актуальности, причина выбора. Комментарий привязывается к заявке, версии или позиции: фраза «эта не подходит» больше не существует без объекта.
Кабинет автосервиса
Кабинет мастера-приёмщика оптимизирован под короткие действия. На главной он видит активные заявки и следующее действие: «Добавить код двигателя», «Выбрать вариант», «Подтвердить замену», «Заказ готов к выдаче». Интерфейс не заставляет знать точные артикулы. История прошлых подборов по автомобилю показывается, но не переносится автоматически: применимость и состояние автомобиля требуют новой проверки.
Мастер выбирает сохранённый автомобиль или добавляет новый по VIN. Карточка автомобиля сервиса с VIN — основа сценария диагностика батарей электромобилей на СТО.
Бизнес-правила
Идентификация автомобиля
VIN хранится в нормализованном виде вместе с исходным вводом. Расшифрованные параметры не считаются безусловно верными: специалист видит источник и может подтвердить или исправить значение. Если одного VIN недостаточно, система требует дополнительный параметр только для затронутой товарной группы. Изменение ключевого параметра возвращает связанные позиции на повторную проверку.
Применимость и аналоги
У позиции есть статус: «Не проверено», «Подходит», «Подходит при условии», «Не подходит». Статус «Подходит при условии» требует текстового ограничения и подтверждения параметра. Аналог не наследует применимость от исходной детали автоматически. Решение содержит автора, время, основание и версию данных. Система может предложить ранее проверенную комбинацию, сотрудник подтверждает её для текущего автомобиля.
Версии комплекта
Любое изменение артикула, количества, склада или условия применимости создаёт новую версию. Согласование привязано к версии, а не к заявке в целом. Если изменение затрагивает одну независимую позицию, повторное подтверждение требуется только по ней. Если позиция связана с комплектом, зависимые строки возвращаются на проверку.
Наличие и резерв
Остаток показывает время последней синхронизации. «Есть на складе» не равно «зарезервировано». Резерв запускается только для подтверждённой версии. Частичный резерв создаёт исключение и не переводит заявку в полную готовность. Комплектовщик не заменяет артикул без возврата специалисту.
Полнота заявки
Система вычисляет готовность по обязательным данным и состояниям позиций. Процент не используется как декоративная метрика: рядом всегда показывается, что мешает следующему этапу. Например: «Готово к согласованию: 5 из 6 позиций проверены; для тормозных дисков нужен PR-код».
MVP
Первая версия замыкает один процесс: автосервис передаёт потребность, специалист формирует проверенный комплект, клиент подтверждает версию, система создаёт резерв, склад получает состав к комплектации.
В первой версии
Организации и пользователи: автосервисы, сотрудники поставщика, роли и доступ к заявкам
Автомобили: VIN, подтверждённые параметры, история заявок без автоматического повторного применения
Заявки на подбор: потребности, работы, вложения, статусы, ответственный и сроки
Комплекты и версии: позиции, связи, аналоги, условия применимости, согласование изменений
Рабочая очередь: фильтры по следующему действию, срокам и исключениям
Остатки и резерв: доступность из учётной системы и передача подтверждённого состава на резервирование
Комплектация: однозначный список актуальной версии и фиксация складских исключений
Журнал: история изменений, решений и согласований
Осознанно отложено
Автоматическое распределение заявок по специалистам
Интеллектуальное ранжирование аналогов
Распознавание документов и перечней работ с фотографий
Полноценный публичный каталог для частных покупателей
Управление доставкой и маршрутами
Прогнозирование спроса и пополнения запасов
Отдельное нативное мобильное приложение
ИИ не является ядром первой версии. Распознавание VIN с фотографии или преобразование свободного текста в черновик можно добавить позже, но результат должен проходить человеческую проверку. На старте важнее получить качественные структурированные данные и устойчивый рабочий процесс.
UX, стек и план
Очередь вместо витрины
Ценность продукта создаётся после того, как артикул найден. Специалист возвращается в заявку и видит следующее действие, а не список последних сообщений. Цвет и подпись статуса относятся к строке комплекта и риску срока, а не к рекомендации «купить этот артикул».
Архитектура
Выбран профиль единого операционного B2B-приложения: насыщенные очереди, карточка заявки, версии комплекта и несколько ролей без отдельного frontend-сервиса. Обмен с учётом строится через интеграцию Laravel с 1С: остатки и резерв подтверждаются учётной системой, Laravel ведёт жизненный цикл заявки.
Client
SPA-подобное рабочее пространство без отдельного публичного API и второго контура аутентификации. Vue закрывает таблицы, формы, фильтры и состояние заявки; Inertia сохраняет единый репозиторий и серверную маршрутизацию Laravel.
API
Модули: пользователи и организации, автомобили, заявки, каталог и применимость, комплекты и версии, остатки и резерв, комплектация, уведомления, аудит, интеграции. Подтверждение версии, повторная проверка остатка и запрос на резерв выполняются как одна управляемая операция.
Data
Реляционная модель для автомобиля, заявки, версий, позиций и журнала. JSONB — только для необязательных параметров товарных групп. Индексы, полнотекст и trigram закрывают поиск по артикулам, VIN, автомобилям и заявкам без отдельного поискового движка.
Queue / cache
Фоновые задания: регулярная синхронизация остатков, импорт каталоговых данных, уведомления и повторяемые интеграционные команды. Обновление статуса резерва — polling раз в несколько секунд; WebSocket в MVP не нужен.
Storage
Фотографии документов, деталей и вложения доступны нескольким сотрудникам и не привязаны к одному серверу. Доступ выдаётся с учётом роли и заявки.
Infrastructure
Минимальная production-инфраструктура: веб-контур, фоновые процессы, резервное копирование и мониторинг ошибок. Kubernetes и микросервисы в MVP не входят: границы нагрузки не требуют независимого развёртывания модулей.
Ключевые решения: неизменяемая подтверждённая версия комплекта; идемпотентная команда резерва с внешним идентификатором; снимок условий решения вместе с выбранной позицией; поиск средствами PostgreSQL; polling статусов интеграции. OpenSearch, отдельный AI-сервис и WebSocket-контур в MVP не входят.
План на 15–17 недель
Срок внедрения до устойчивого пилота — 15–17 недель. Он зависит прежде всего от качества каталоговых данных и готовности учётной системы принимать резерв с внешним идентификатором.
0 нед
17 нед пилот
- 2 нед1
Подготовка данных и правил
Обязательные параметры пилотных товарных групп, статусы применимости, причины исключений, справочник автосервисов, сопоставление складов и идентификаторов с учётом. Для пилота выбираются 5–7 автосервисов с регулярными заявками.
- 8–10 нед2
Разработка ядра MVP
Заявки, автомобили, очередь и карточка подбора; комплекты, версии и согласование; синхронизация остатков и команда резервирования; интерфейс комплектации, журнал, уведомления и базовые отчёты по состояниям процесса.
- 3 нед3
Параллельный пилот
Пилотные заявки создаются в системе, команда может сверить результат со старым процессом. Каждое расхождение классифицируется: данные, бизнес-правило, интерфейс или интеграция. Параллельный режим ограничен по времени, иначе переписка снова станет главным источником.
- 2 нед4
Закрепление процесса
Обучение на реальных сценариях, инструкции для автосервисов, ежедневный разбор исключений первой недели, запрет изменения согласованного состава вне версий, постепенное подключение остальных клиентов и товарных групп.
Метрики
Показатели ниже — результат внедрения. До запуска фиксировалась базовая линия на сопоставимой выборке заявок. После запуска те же показатели считались по журналу системы.
| Метрика | Состояние до | Целевое состояние | Как измеряется |
|---|---|---|---|
| Время до первого содержательного ответа | размазано по переписке и повторным сверкам | сократить на 30–40% | От создания полной заявки до отправки проверенного варианта |
| Ручные переносы данных | VIN, артикулы и количество вводятся между каналами повторно | сократить минимум вдвое | Число повторных вводов между мессенджером, таблицей, каталогом и учётом |
| Заявки без следующего действия | не видно, кто отвечает и что делать | не более 5% активных заявок | Доля заявок без ответственного и действия |
| Изменения после согласования без повторного подтверждения | состав может уйти в заказ молча | исключить технически | События правки подтверждённой версии |
| Время обнаружения изменения остатка | до следующего сообщения или комплектации | до нескольких минут после синхронизации | От получения нового остатка до появления исключения |
| Полнота истории подбора | контекст остаётся в чате и памяти специалиста | не менее 95% закрытых заявок | Доля закрытых заявок с автомобилем, версией, решением и резервом |
| Складские возвраты на уточнение | комплектовщик звонит специалисту | снизить на 40–50% | Доля комплектов, которые склад не может собрать без обращения к специалисту |
Значения уточнялись на пилоте после измерения исходного процесса и проверки качества интеграционных событий.
Риски и выводы
Риски
| Риск | Вероятность | Влияние | Снижение |
|---|---|---|---|
| Каталоговые данные противоречат реальному автомобилю | Средняя | Высокое | Статусы уверенности, фиксация основания, обязательная проверка специалистом |
| Остатки обновляются с задержкой | Средняя | Высокое | Время актуальности, повторная проверка перед резервом, явное исключение |
| Сотрудники продолжают вести решения в мессенджере | Высокая на старте | Высокое | Быстрые комментарии в карточке, ограниченный параллельный период, контроль заявок без истории |
| Автосервисы присылают неполные данные | Высокая | Среднее | Динамические обязательные поля и короткий сценарий запроса уточнения |
| Правила комплектности отличаются между специалистами | Средняя | Среднее | Пилот на ограниченных группах, журнал спорных решений, постепенное формирование правил |
| Интеграция создаёт дубли резерва | Низкая | Высокое | Идемпотентные команды, внешний идентификатор, журнал попыток и сверка статуса |
Развитие после устойчивого MVP
- Рекомендации проверенных комбинаций для совпадающих параметров — без автоматического утверждения применимости.
- Распознавание VIN и списка работ из фотографии или сообщения в черновик; мастер или специалист подтверждает результат.
- Ранжирование вариантов по полноте комплекта, одному складу, сроку доступности и истории подтверждённых применений.
- Правила комплектности по ремонтным операциям: обязательные сопутствующие элементы и причина предложения.
- Контроль качества подбора: причины повторных проверок, складских исключений и отменённых замен.
- Внешний API для крупных автосервисов: создание заявок и статусы без повторного ввода.
Как изменилась работа
До
- обращение, подбор и заказ существуют отдельно;
- актуальная версия восстанавливается по сообщениям;
- применимость хранится в памяти специалиста;
- клиент подтверждает текст и фотографии;
- остаток проверяется в момент поиска;
- склад уточняет спорные позиции по телефону;
- руководитель считает открытые обращения.
После
- весь путь связан заявкой на подбор;
- каждое изменение создаёт версию комплекта;
- решение фиксируется с условиями, автором и основанием;
- автосервис подтверждает конкретную версию;
- доступность повторно проверяется перед резервом;
- комплектовщик получает однозначный состав и создаёт структурированное исключение;
- руководитель видит отклонения и заявки без следующего действия.
Главное изменение происходит не в скорости поиска артикула, а в управляемости решения. Заявка больше не распадается на каталог, переписку и заказ: автомобиль, потребность, проверка применимости, согласованная версия и резерв образуют одну историю.
Обратная связь после внедрения
Сжатая цитата из обратной связи после пилотного внедрения. Название компании и имя не указаны из‑за NDA.
«По простым заявкам мы и раньше справлялись быстро. Проблемы начинались, когда несколько аналогов, разные поставщики и нужно ещё проверить применимость. Вот там единая карточка заявки действительно удобна.»
Обсудить проект
Нужен похожий контур — обсудим. Услуги на Laravel · Каталог решений.
