Бригадир
Создаёт проект, распределяет материалы по зонам и этапам, принимает замены и подтверждает комплектацию.
Ограничение
Нужна готовность объекта и позиции, требующие решения, а не весь ассортимент.
Кейс: Портал закупок сантехники
B2B-портал оптового поставщика, где единица работы — закупочный проект объекта, а не корзина каталога. Портал замыкает контур от чернового списка материалов до подтверждённой комплектации и выдачи со склада.
Карточка проекта
Содержание
Отрасль и клиент
Рынок и задача
Клиент — оптовый поставщик сантехники в Беларуси. Он обслуживает частных монтажников, бригады и небольшие ремонтные организации: комплектует объекты не разовыми позициями витрины, а связанными узлами — водоснабжением, канализацией, отоплением, инсталляцией, котельной или санузлом. Это не дилерский заказ у дистрибьютора сантехники: там салон пополняет матрицу в кабинете оптовика. Здесь единица работы — закупочный проект конкретного объекта.
Монтажник мыслит не артикулами каталога. Ему нужно собрать обвязку бойлера, заменить участок канализации, подготовить материалы для двух санузлов или закрыть очередной этап ремонта квартиры. В одной заявке встречаются трубы, фитинги, запорная арматура, крепёж, расходные материалы и оборудование разных производителей. У каждой позиции есть ограничения: диаметр, тип резьбы, материал, рабочая среда, способ соединения, монтажная длина и совместимость с соседними элементами.
Портал не заменяет учётную систему поставщика. Он замыкает процесс от чернового списка до подтверждённой комплектации и выдачи. Пять складов клиента — это точки отпуска номенклатуры, а не выбор площадки под технологический процесс: такой контур закрывает подбор склада и производства.
Масштаб первой версии
Склады5
Позиции каталога~18 000
Профессиональные клиенты240
Заказы~900 / мес.
| Показатель | Значение |
|---|---|
| География | Беларусь |
| Склады отпуска | 5 |
| Активные позиции каталога | ~18 000 |
| Профессиональные клиенты | 240 |
| Заказы отдела продаж | ~900 в месяц |
| Контур пилота | 12 бригад, два менеджера, один склад |
| Категории пилота | Водоснабжение, канализация, запорная арматура |
| Основной процесс | От списка материалов до резерва и выдачи этапа |
Каталог не равен комплектации: бригаде нужна рабочая среда закупочного проекта, а не ускоренная витрина.
Роли
Монтажник
Добавляет недостающие материалы с объекта, уточняет параметры и фиксирует фактическую потребность.
Ограничение
Работает с телефона, без сложного администрирования.
Менеджер поставщика
Разбирает исключения: неоднозначные позиции, конфликты, отсутствие товара и замены.
Ограничение
Главный экран — очередь комплектаций, а не общий dashboard.
Сотрудник склада
Собирает подтверждённые этапы, фиксирует недостачу и готовит выдачу.
Ограничение
Не меняет техническое решение без возврата задачи менеджеру.
Как было
Закупка начинается с фотографии списка
До портала заявка приходила фотографией рукописного списка, голосовым сообщением или таблицей. Менеджер вручную распознавал позиции, задавал уточняющие вопросы, искал товары в учётной системе и предлагал замены. Если части комплектации не было на одном складе, заказ разбивался на несколько выдач. Когда состав менялся, новая версия оставалась в переписке, а бригадир не всегда понимал, какие позиции подтверждены, какие заменены и что ещё докупить.
Восемь шагов из мессенджера
- Бригадир собирал потребности от монтажников в мессенджере или по телефону.
- Список переносился менеджеру поставщика в произвольном формате.
- Менеджер вручную сопоставлял бытовые названия с номенклатурой каталога.
- Наличие проверялось отдельно по каждой позиции и складу.
- Недостающие товары заменялись в переписке, иногда без явного подтверждения всей бригады.
- Обновлённая комплектация пересобиралась вручную.
- После подтверждения менеджер создавал заказ в учётной системе и сообщал статус клиенту.
- На объекте обнаруживались пропущенная мелочь, несовместимый переходник или позиция из старой версии списка.
Корневая проблема
У процесса не было единой точки правды. Каталог знал товары, учётная система — остатки и заказы, менеджер — договорённости, а бригада — реальную потребность объекта. Ни один инструмент не связывал эти четыре слоя.
Обычный интернет-магазин предполагает, что покупатель уже знает, что ему нужно. Для профессиональной закупки сантехники этого недостаточно: потребность описывается языком монтажа; ошибка проявляется на объекте, а не в карточке товара; наличие меняется во время согласования; заказ поставляется этапами. Одна общая корзина это не отражает — подробнее о такой границе в интервью Почему бизнесу иногда нужен Laravel, а не WordPress. Когда процесс держится на Excel и мессенджерах — в материале интервью: micro-SaaS вместо Excel и мессенджеров.
Центральная сущность продукта — не корзина и не заявка в чате, а закупочный проект объекта.
Решение
Закупочный проект объединяет объект, спецификацию, совместимость, наличие, замены, этапы и следующее действие в одной рабочей области.
В проекте фиксируются объект и плановая дата работ, ответственный бригадир и участники, зоны или монтажные узлы, спецификация с количеством и единицами, технические связи, наличие и выбранный склад, предложенные и подтверждённые замены, этапы поставки, комментарии, файлы, журнал изменений и текущее состояние.
Вместо статусов «черновик» и «готово» проект получает состояния реальной работы: «Собирается», «Нужны уточнения», «Проверяется поставщиком», «Есть замены», «Готов к подтверждению», «Зарезервирован», «Комплектуется», «Частично выдан», «Закрыт». Статус вычисляется по незавершённым действиям: несопоставленная позиция блокирует проверку, неподтверждённая замена не даёт статус готовности, частичная выдача отражается отдельно.
Как работает новый процесс
- Бригадир создаёт проект, выбирает тип работ и добавляет зоны — например, «Санузел 1», «Санузел 2» и «Котельная».
- Внутри зоны использует шаблон узла, поиск по профессиональным синонимам или вставку списка из таблицы.
- Система нормализует единицы, предлагает карточки номенклатуры и показывает обязательные параметры.
- Портал проверяет диаметры, типы соединений, материалы, сопутствующие элементы и кратность упаковки.
- Спорные случаи уходят менеджеру; формальная проверка не заменяет инженерное решение.
- Позиции сверяются со складским снимком; бригадир выбирает склад и допускает или запрещает разделение.
- Менеджер предлагает замену с пояснением: какие характеристики совпадают, какие отличаются и затронуты ли соседние элементы.
- После подтверждения замен проект фиксируется как версия; дальнейшие правки создают ревизию с разницей.
- Подтверждённые позиции резервируются через учётную систему, этапы уходят на комплектацию склада.
- На выдаче склад отмечает собранные позиции; расхождение возвращает этап в очередь исключений.
Менеджер перестаёт сопровождать каждую строку вручную. Он подключается там, где система не может принять безопасное решение.
Основные сценарии
Сбор комплектации нового объекта
Бригадир создаёт проект, формирует зоны, добавляет товары вручную, из шаблона или импортом таблицы. Портал объединяет дубли, проверяет единицы и показывает незаполненные характеристики.
Результат: структурированная спецификация, которую можно передать на проверку поставщику.
Добавление материала с объекта
Монтажник открывает мобильную версию по приглашению, выбирает зону, находит позицию или сканирует штрихкод, указывает количество и комментарий. Изменение попадает в черновик ревизии.
Результат: потребность фиксируется без звонка и не смешивается с подтверждённой версией.
Проверка совместимости
Система анализирует пары компонентов и обязательные элементы узла. Формальные конфликты — разные диаметры, тип соединения, отсутствие переходника — попадают в список.
Результат: обнаруживаемые несоответствия устраняются до подтверждения.
Согласование замены
Менеджер выбирает аналог и заполняет структурированное пояснение. Портал показывает исходную и предложенную позиции рядом, подсвечивает отличия и затронутые элементы.
Результат: в проекте остаётся проверенное решение с автором и временем, а не сообщение «поставим аналог».
Разделение по этапам
Позиции распределяются между «Черновым монтажом», «Установкой оборудования» и «Чистовой сборкой». Портал предупреждает, если зависимая позиция назначена позже нужного элемента.
Результат: склад получает самостоятельные комплекты, объект не перегружается материалами впрок.
Изменение после подтверждения
Новая ревизия показывает добавленные, удалённые и изменённые строки и влияние на уже собранные этапы. Подтверждённая версия остаётся в истории.
Результат: участники согласуют изменение, не теряя исходную договорённость.
Смета собственника квартиры — другой продукт: управление ремонтом квартиры собирает план, подрядчиков и бюджет владельца. Здесь рабочий центр — кабинет поставщика для бригады.
Главный интерфейс: рабочая область проекта
Главный экран бригадира строится вокруг проекта, а не вокруг витрины. В шапке — объект, готовность комплектации, ближайший этап и одно основное действие: исправить замечания, отправить на проверку, подтвердить замены или передать на резервирование.
Левая колонка — зоны и этапы. Центр — спецификация по монтажным узлам: товар, параметры, количество, наличие, состояние проверки и этап. Справа — панель замечаний: несовместимость, отсутствующая характеристика, неподтверждённая замена или изменение после фиксации.
Режим «Требует решения» скрывает корректные строки и оставляет только блокирующие вопросы. Каталог открывается боковой панелью внутри проекта: пользователь не теряет контекст зоны и видит комплектующие, связанные с текущим узлом или закрывающие замечание.
Мобильный сценарий монтажника
Мобильный интерфейс не повторяет весь портал. Монтажнику доступны назначенные объекты, зоны, подтверждённая спецификация и действие «Добавить потребность». Поиск поддерживает профессиональные синонимы и недавние позиции объекта; можно отсканировать штрихкод или выбрать товар с соседнего узла.
При нестабильной связи незавершённая форма сохраняется локально. Полноценный автономный каталог в первой версии не загружается: это усложнило бы синхронизацию остатков. Пользователь фиксирует текст, количество, фотографию и комментарий, а сопоставление с номенклатурой завершает после восстановления связи.
Очередь исключений для менеджера
Менеджер не просматривает все активные проекты. Очередь формируется автоматически и содержит только ситуации, где нужно профессиональное решение. Карточки сортируются по близости этапа поставки и типу блокировки.
- позиция не сопоставлена с каталогом;
- обязательный параметр не указан;
- обнаружен технический конфликт;
- товара нет на выбранном складе;
- замена затрагивает соседние элементы;
- изменилась подтверждённая версия;
- склад сообщил о расхождении при комплектации.
Внутри задачи менеджер видит не изолированный товар, а его место в узле: соседние компоненты, параметры, комментарий монтажника и этап.
Бизнес-правила
Версионность спецификации
После передачи на проверку состав фиксируется. Любое изменение создаёт ревизию. Система повторно проверяет только затронутые связи. Удалить историю подтверждённой ревизии нельзя.
Наличие и резервирование
Наличие — информационный снимок, резервирование — подтверждённое действие учётной системы. Портал не обещает товар только потому, что тот отображался доступным во время подбора. Перед финальным переходом выполняется повторная проверка. Тот же разрыв между витриной и полкой закрывает заказ корма с самовывозом. Это резерв номенклатуры, а не койко-место: жизненный цикл жилья сотрудников закрывает портал размещения сотрудников. Подтверждённый состав в резерв передаёт и заявка на подбор комплекта автозапчастей.
Управляемые замены
Замены делятся на полное совпадение контролируемых параметров, совместимую замену с отличиями и замену, требующую пересборки узла. Даже полное совпадение не применяется автоматически: решение принимает бригадир или назначенный участник.
Зависимости внутри узла
Правила проверяют формализуемые условия — диаметры, соединения, обязательные элементы. Они не определяют, соответствует ли весь узел проектной документации. Интерфейс отделяет автоматическую проверку от профессиональной ответственности. Схожая проверка связанного состава в интерьерном шаблоне ведётся в проект комплектации санузла готовым комплектом. Спорную связку не красят в автоматический зелёный статус и в магазине инструментов для груминга: там «нужна проверка» уходит консультанту, а не считается совместимостью.
Единицы, упаковки и права
Количество хранится в рабочей единице и в единице отпуска. Если товар выдаётся упаковками, портал показывает округление до кратности до подтверждения. Бригадир управляет составом и приглашениями. Монтажник предлагает изменения, но не подтверждает итоговую версию без отдельного права. Менеджер предлагает номенклатуру и замены, но не меняет потребность клиента. Склад работает только с подтверждёнными этапами.
Расхождения на складе
Если склад не может собрать позицию, она не заменяется незаметно. Этап получает состояние «Есть расхождение», менеджеру создаётся задача, бригадиру уходит уведомление. Остальная часть этапа может продолжить комплектацию, если позиция не помечена как блокирующая.
MVP
Первая версия замыкает один процесс: создать закупочный проект, собрать спецификацию, проверить формальные зависимости, согласовать исключения, подтвердить наличие, передать этап на комплектацию и зафиксировать выдачу. Пилот ограничен тремя связанными категориями: водоснабжение, канализация и базовая запорная арматура.
В первой версии
Организации, пользователи и четыре роли
Каталог с техническими атрибутами, синонимами и остатками по складам
Поиск по названию, артикулу, синонимам и ключевым характеристикам
Закупочные проекты, зоны, узлы, спецификации и ревизии
Импорт списка из таблицы с подтверждением сопоставления
Базовые правила совместимости для категорий пилота
Предложения и подтверждения замен
Этапы поставки, резервирование и статусы комплектации
Очередь исключений менеджера
Адаптивный мобильный сценарий добавления потребности
Обмен каталогом, остатками, резервами и статусами с учётной системой
Уведомления, журнал действий и выгрузка спецификации
Осознанно отложено
Автоматическое распознавание рукописных списков и голосовых сообщений
Полноценный автономный каталог на мобильном устройстве
Совместное редактирование одной строки в реальном времени
Сложный конфигуратор инженерных систем
Рекомендации на основе истории похожих объектов
Подключение нескольких независимых поставщиков
Отдельное нативное мобильное приложение
Расширенная аналитика по нескольким филиалам
ИИ не является ключевой частью первой версии. На следующем этапе он может предлагать сопоставление произвольного текста с каталогом или извлекать позиции из фотографии списка, но каждое предложение подтверждается человеком. Пока структура каталога и словарь синонимов не приведены в порядок, модель лишь скроет проблему качества данных.
UX, стек и план
Рабочая область вместо витрины
Ценность продукта создаётся после поиска товара. Бригадир возвращается в проект и видит готовность, замечания и следующее действие. Цвет и подпись статуса относятся к строке спецификации, а не к рекомендации «купить этот артикул». Рабочая область вокруг версии заказа, а не витрины, есть и у производства кухонь на заказ: там допуск версии до цеха, здесь — подтверждённая комплектация до склада. Ту же рабочую область для шкафов и гардеробных держит заказы корпусной мебели до производства.
Архитектура
Выбран профиль единого операционного B2B-приложения: насыщенный интерфейс со спецификациями, фильтрами, сравнением версий и боковыми панелями без отдельного frontend-сервиса. Обмен с учётом строится через интеграцию Laravel с 1С: каталог, остатки и резерв подтверждаются учётной системой, Laravel ведёт жизненный цикл проекта.
Client
SPA-подобная работа со спецификацией без отдельного публичного API и второго контура аутентификации. Vue закрывает формы, таблицы и зависимые фильтры; Inertia сохраняет единый репозиторий и серверную маршрутизацию Laravel.
API
Модули: пользователи и организации, каталог, закупочные проекты, совместимость, замены, резервирование, комплектация, уведомления, аудит. Laravel хранит бизнес-правила, права, интеграционный обмен и жизненный цикл проекта.
Data
Реляционная модель для проектов, ревизий, позиций и зависимостей. JSONB — только для неодинаковых технических атрибутов категорий. Полнотекст и trigram закрывают поиск по названиям и синонимам без отдельного поискового движка.
Queue / cache
Фоновые задания: обмен каталогом и остатками, пакетная проверка незавершённых проектов, импорт, рассылка. Кэш Redis хранит короткоживущий складской снимок; резервирование всегда подтверждается учётом.
Storage
Изображения товаров, вложения, импортируемые таблицы и сформированные выгрузки. Доступ к внутренним файлам выдаётся с учётом роли и проекта.
Infrastructure
Веб-приложение и workers могут работать на одном сервере; базу допустимо вынести отдельно. Pest покрывает правила совместимости, ревизий, прав и статусов. Playwright проверяет создание проекта, импорт, замену, резервирование и складское расхождение.
Ключевые решения: неизменяемые ревизии после подтверждения; декларативные правила совместимости; разделение остатка и резерва; идемпотентный импорт каталога; поиск средствами PostgreSQL до роста фасетов. Next.js, WebSocket-контур, Kubernetes и отдельный AI-сервис в MVP не входят.
План на 16 недель
Срок реализации MVP и пилота — 16 недель. Внедрение строится вокруг одного филиала и ограниченного набора категорий.
0 нед
16 нед пилот
- 2 нед1
Разбор процесса и данных
Путь реальных заявок, типовые монтажные узлы, структура номенклатуры, категории пилота. Фиксируются обязательные атрибуты, синонимы и правила, которыми уже пользуются менеджеры.
- 3 нед2
Прототипирование рабочего контура
Рабочая область проекта, каталог внутри спецификации, сравнение замены и очередь исключений. Прототипы проверяются на комплектациях разной сложности: небольшой ремонт, два санузла и котельная.
- 6 нед3
Разработка ядра
Роли, каталог, поиск, проекты, ревизии, базовые правила совместимости, замены и этапы. Параллельно — импорт исходных данных и административный интерфейс атрибутов.
- 2 нед4
Интеграция и складской контур
Обмен с учётной системой, резервирование, повторная отправка, расхождения и возврат статусов. Склад получает упрощённый экран комплектации.
- 3 нед5
Пилот
12 бригад, два менеджера, один склад. Первую неделю портал и прежний канал ведутся параллельно только для контроля расхождений. Затем заявки пилотных категорий переводятся в портал. Обучение строится вокруг четырёх операций: создать проект, устранить замечания, подтвердить замену и получить этап.
Метрики
Цифры — результаты пилота: сопоставимые комплектации за четыре недели до запуска и четыре недели после стабилизации процесса. Из измерения исключались проекты, сознательно проведённые по старому каналу из-за недоступной категории или длительного интеграционного сбоя.
| Метрика | Состояние до | Стало в пилоте | Как измеряется |
|---|---|---|---|
| Медианное время активной работы до «Готов к резервированию» | 35 минут | 12 минут | От создания проекта до готовности, отдельно для узлов без исключений и с заменами |
| Ручные переходы между каналами в одном проекте | 5 | 1 | Обращения к мессенджеру, звонку и отдельной таблице; срочная связь может остаться, решение фиксируется в проекте |
| Спецификации с пропущенной обязательной комплектующей | 22% | 8% | Складские корректировки и дополнения до выдачи в пилотных категориях |
| Доля замен с явным подтверждением | фрагментирована по переписке | 100% | Применённые замены с автором, сравнением параметров и подтверждением бригадира |
| Время обнаружения складского расхождения | до следующего контакта в чате | до 15 минут в рабочее время | От фиксации недостачи складом до задачи менеджеру и уведомления бригадира |
| Полнота обязательных атрибутов в категориях пилота | неравномерная | 95% | Доля карточек с заполненными обязательными техническими атрибутами перед расширением пилота |
Риски и выводы
Риски
| Риск | Вероятность | Влияние | Снижение |
|---|---|---|---|
| В каталоге отсутствуют технические атрибуты | Высокая | Проверки совместимости дают мало пользы | Пилот из трёх категорий, обязательность атрибутов, очередь качества данных |
| Остатки в учёте обновляются с задержкой | Средняя | Пользователь воспринимает наличие как обещание | Разделить наличие и резерв, показывать время снимка, повторно проверять перед подтверждением |
| Бригады продолжают отправлять списки в мессенджер | Высокая | История снова становится фрагментированной | Быстрый мобильный ввод, импорт таблиц, портал как единственное место подтверждения версии |
| Слишком много предупреждений совместимости | Средняя | Пользователи перестают реагировать | Начать с блокирующих правил, измерять долю отклонённых предупреждений |
| Менеджеры предлагают замены вне портала | Средняя | Теряется авторство и контекст решения | Автоматическая очередь исключений, запрет резерва без подтверждения замены |
| Интеграция временно недоступна | Средняя | Проект зависает между подтверждением и складом | Идемпотентная очередь, повторные попытки, видимый статус ожидания, ручной регламент при длительном сбое |
| Правила воспринимаются как инженерная гарантия | Низкая | Пользователь полагается на неполную автоматическую проверку | Явная область проверки, подтверждение человека, формулировки без «окончательного проектного решения» |
Развитие после пилота
- Расширение правил и шаблонов на отопление и инсталляции — после требуемой полноты атрибутов.
- Распознавание фотографий и свободного текста как помощник сопоставления, с подтверждением каждой позиции.
- Шаблоны бригад: собственные узлы и нормативные наборы для повторяющихся работ.
- Рекомендации по комплектности на основе успешно закрытых проектов, без автоматического применения.
- Подключение дополнительных складов и филиалов после стабилизации обмена и очереди исключений.
- Кабинет руководителя бригады: готовность нескольких объектов и отклонения по ближайшим этапам.
Как изменилась работа
До
- список жил в фотографии, голосовом и таблице;
- менеджер сопоставлял бытовые названия вручную;
- замены оставались в переписке;
- наличие проверялось по каждой строке отдельно;
- версия спецификации терялась при правках;
- пропущенный переходник находили на объекте;
- склад узнавал состав из заказа в учёте без контекста узла.
После
- потребность живёт в закупочном проекте;
- сопоставление и формальные проверки встроены в спецификацию;
- замена имеет автора, сравнение и подтверждение;
- наличие отделено от резерва;
- изменения создают ревизию с разницей;
- замечания видны до выезда;
- склад комплектует подтверждённый этап с историей проекта.
Главное изменение состоит не в переносе каталога в новый интерфейс. Портал превращает закупку из цепочки сообщений в управляемый процесс комплектации: потребность структурируется, исключения становятся видимыми до выезда на объект, а подтверждённая версия проходит до склада без потери контекста.
Обратная связь после внедрения
Сжатая цитата из обратной связи после пилотного внедрения. Название компании и имя не указаны из‑за NDA.
«Один объект раньше мог жить в трёх местах: список у монтажника, таблица у менеджера и переписка с заменами. И всё это немного отличалось. Сейчас хотя бы работаем с одним составом.»
Обсудить проект
Нужен похожий контур — обсудим. Услуги на Laravel · Каталог решений.
