Концепт B2B-портала «Промконтур»

Подбор оборудования, проверка аналогов и согласование КП с сохранённой историей закупки.

Концепт-проект: «Промконтур» — вымышленная компания. Результатов работы здесь нет: только решения и гипотезы.

О заказчике

• Сценарий: Поставщик насосов и промышленной арматуры для заводов и подрядчиков
• Пользователи: Инженер, снабженец, руководитель закупок и менеджер поставщика
• Первая версия: Каталог, корзина запроса, согласование КП и документы
• Ограничение: Цены и наличие подтверждаются поставщиком; каталог не обещает резервирование
• Данные: Вымышленный ассортимент и условия, только для разбора проектирования

Задача

В демонстрационном сценарии инженер подбирает насос по режиму работы, снабженец собирает позиции нескольких отделов, а менеджер уточняет совместимость. Артикулы приходят из писем и таблиц. Изменение количества создаёт новую версию файла, но никто не знает, какая версия согласована.

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

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

Риски исходного процесса

Параметры трудно сопоставить

Одинаковые характеристики записаны разными словами и единицами. Нормализуем справочник, сохраняем оригинальные значения и явно отмечаем отсутствующие данные.

Цена без контекста

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

Аналог требует проверки

Карточка сравнения показывает совпадения и различия по критическим параметрам. Непроверенный аналог нельзя принять одним кликом как подтверждённую замену.

Переписка теряет версии

История изменений связывает новую редакцию предложения с исходным запросом. Согласование старой редакции не распространяется на новые условия.

Решение

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

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

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

Как устроен продукт

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

Что помогает пройти сценарий

Запрос без обязательной регистрации

Первичный запрос содержит контакт и спецификацию. Кабинет предлагается после получения запроса; создание аккаунта не блокирует начало закупки.

Одна корзина для разных отделов

Позиции можно пометить объектом или подразделением. Комментарии остаются у конкретного артикула, а не теряются в общем письме.

Контакт с сохранённым контекстом

Менеджер видит состав, версию и согласие на связь. Уведомление отправляется после сохранения запроса и получает отдельный статус доставки.

Ключевые сценарии

Подобрать оборудование

Инженер ищет насос и фиксирует требования до выбора аналога.

На входе: Артикул или рабочие параметры, единицы измерения и среда эксплуатации.

1. Применить критические фильтры
2. Сопоставить отличия и непроверенные параметры
3. Добавить выбранную позицию с комментарием

На выходе: Корзина запроса с исходными требованиями и выбранными позициями.

Если что-то пошло не так: Если подходящих данных нет, предлагаем запрос инженеру; пустая выдача не означает отсутствие решения.

Критерий приёмки: Нельзя выдать непроверенный аналог за согласованный. Требования сохраняются при переходе к запросу.

Запросить предложение

Снабженец передаёт поставщику подготовленную спецификацию.

На входе: Состав корзины, организация, количество, желательный срок и контакт.

1. Проверить количество и допуски замены
2. Приложить спецификацию
3. Отправить запрос и получить номер

На выходе: Сохранённое обращение с номером и независимыми статусами уведомлений.

Если что-то пошло не так: При повторном нажатии возвращается тот же номер; временный сбой CRM не уничтожает запись.

Критерий приёмки: Повторный запрос не создаёт дубль, вложение относится к правильной версии, статус сохранения виден пользователю.

Согласовать редакцию

Руководитель закупки подтверждает конкретные условия.

На входе: Актуальная версия КП и список согласующих сотрудников.

1. Сравнить изменения с предыдущей редакцией
2. Проверить цену, комплект и срок
3. Подтвердить редакцию или вернуть на уточнение

На выходе: Зафиксированное согласование с автором и версией документа.

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

Критерий приёмки: Согласовать можно только доступную организации актуальную редакцию. История сохраняется.

Роли пользователей

Инженер

Проверяет рабочую среду, характеристики и заменяемость оборудования.

Совпадают ли критические параметры и кто подтвердил аналог?

Снабженец

Собирает потребность, сроки и комплект документов в один запрос.

Как передать позиции без повторного ввода в письмо?

Менеджер поставщика

Уточняет комплектацию, срок и персональные условия.

Что уже согласовано, а где нужен ответ покупателя?

Как устроено технически

React + TypeScript

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

PostgreSQL и ролевой доступ

Организации, договоры, предложения и версии документов связаны ключами. Доступ проверяется сервером на каждой операции, включая скачивание файла.

Обмен с 1С

Контракт справочников, контроль ошибок, дата последнего обновления и ручной повтор. Формат обмена выбираем после обследования конкретной конфигурации.

Идемпотентность и очередь уведомлений

Ключ запроса предотвращает дубли при повторном нажатии. Отдельный журнал хранит отправку в CRM и почту, чтобы сбой одного канала не терял заявку.

Что входит в разработку

• Описание ролей и правил работы с договорными ценами
• Нормализация характеристик и импорт демонстрационного каталога
• Прототип каталога, сравнения и корзины запроса
• Кабинет организации, версии КП и доступ к документам
• Контракт обмена с 1С, журнал ошибок и повторная обработка
• Матрица прав, критерии приёмки и пилот на одной группе покупателей

План реализации

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

Что замеряем после запуска

• Запросы с достаточной спецификацией — Сравниваем долю запросов, по которым менеджер может начать расчёт без уточнения артикула и количества. Сначала фиксируем исходный уровень.
• Время до согласованного КП — Измеряем путь от сохранения запроса до подтверждения актуальной редакции. Исключаем время ожидания ответа поставщиков и показываем его отдельно.
• Возвраты на уточнение аналога — Считаем случаи, когда выбранная замена отклонена инженером, и причины отклонения.
• Успешность обмена и доставки — Отдельно измеряем сохранение запроса, обработку интеграцией и приём уведомления внешним каналом; не считаем HTTP 200 доказательством сделки.

Стек

React + TypeScript, PostgreSQL и ролевой доступ, Обмен с 1С, Идемпотентность и очередь уведомлений.

Все кейсы · Услуга · Калькулятор стоимости

Визуализация продукта

Изображение создано с помощью ИИ для демонстрационного проекта. Компания, задания и параметры вымышлены; это не скриншот работающего клиентского продукта.