Портал складских и производственных помещений

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

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

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

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

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

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

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

Роли

Как было

Требования уходят письмом

Руководитель проекта начинает с формулировки задачи: нужна площадка площадью от 4 500 до 6 500 м², с отдельными производственной и складской зонами, доступной электрической мощностью не менее 800 кВт, высотой рабочей части от 9 м, нагрузкой на пол от 5 т/м² и возможностью движения крупнотоннажного транспорта.

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

Семь шагов проверки

После первой подборки начинается отдельный процесс:

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

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

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

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

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

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

Концепция продукта

Портал состоит из трёх связанных пространств: публичного каталога, технического паспорта объекта и закрытого проекта подбора.

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

Что хранит параметр

• значение и единица измерения;
• зона объекта, к которой оно относится;
• источник — документ, измерение, заявление представителя или результат осмотра;
• дата актуализации;
• статус «не заполнено», «заявлено», «подтверждено документом», «проверено на осмотре»;
• комментарий и вложения.

Как меняется процесс

Новый процесс начинается не с просмотра объявлений, а с создания профиля потребности.

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

Автоматизация не принимает окончательное решение. Она приводит данные к единому виду, обнаруживает пропуски, подсвечивает противоречия и не позволяет незаметно заменить подтверждённое значение новым заявлением.

Главный экран — рабочая матрица проекта

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

Верхняя часть показывает параметры проекта: «Производство и склад», «Минск и до 35 км», «4 500–6 500 м²», «Готовность — до 1 марта 2027», а также состояние процесса: 18 найдено, 7 добавлено, 3 в коротком списке, 2 ожидают осмотра.

Центр экрана занимает сравнительная матрица. Строками идут критерии, колонками — объекты. Ячейка одновременно показывает результат и качество данных:

• зелёный — соответствует и подтверждено;
• жёлтый — значение подходит, но требует проверки;
• красный — критическое несоответствие;
• серый — данных нет;
• синий маркер — параметр изменился после последнего просмотра.

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

Карточка объекта: характеристики вместе с доказательствами

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

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

В шапке видны три независимых статуса: публикация объекта, полнота паспорта и актуальность данных. Объект может быть опубликован, но иметь только 68% заполненных обязательных характеристик. Это честнее, чем скрывать пробелы за общей отметкой «проверено».

У каждой характеристики есть источник. Если представитель указал мощность 1 000 кВт, а приложенный документ подтверждает только 630 кВт, система не заменяет одно значение другим. Она создаёт противоречие и требует решения модератора или инженера проекта.

Что система проверяет автоматически

• единицы измерения и допустимый формат значений;
• логические противоречия между общей площадью и площадями зон;
• наличие вложения для параметров, где проект требует документального подтверждения;
• истечение срока актуальности сведений;
• изменение критичного параметра после добавления объекта в короткий список;
• дубли объектов по адресу, координатам и сочетанию характеристик;
• незакрытые вопросы перед переводом на следующий этап.

Что остаётся человеку

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

Осмотр без отдельного фотоархива

Осмотр проводится через адаптивную PWA-страницу. Отдельное мобильное приложение для MVP не требуется: инженер получает доступ к назначенному осмотру со смартфона, а черновик сохраняется локально при нестабильной связи.

Перед выездом портал формирует чек-лист не из универсального шаблона, а из требований проекта и пробелов конкретного объекта. Если высота подтверждена, но нет данных о зоне разгрузки, соответствующий пункт получает повышенный приоритет.

На объекте инженер:

1. открывает маршрут осмотра по зонам;
2. сверяет заявленные параметры;
3. вводит измеренное значение или выбирает «не удалось проверить»;
4. прикрепляет фото с подписью и зоной объекта;
5. фиксирует дефект, ограничение или вопрос;
6. отмечает влияние на критерий проекта;
7. подписывает итог и отправляет отчёт на проверку.

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

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

Бизнес-правила, которые удерживают процесс

1. Критерий имеет тип. Обязательное несоответствие блокирует перевод в короткий список, пока руководитель явно не оформит исключение.
2. Неизвестное не равно несоответствию. Пустое значение создаёт запрос на уточнение, а не автоматический отказ.
3. Источник обязателен. Для каждого подтверждённого параметра сохраняется документ, осмотр или ответственное лицо.
4. Версии не перезаписываются. Изменение мощности, площади или высоты создаёт новую версию и уведомляет участников проекта.
5. Проверка привязана к проекту. Один и тот же параметр может быть достаточным для одного арендатора и критичным для другого.
6. Закрытие требует причины. Объект нельзя просто удалить из проекта; он получает структурированную причину исключения.
7. Актуальность ограничена. Параметры, способные измениться, переходят в статус «требует подтверждения» после заданного периода.
8. Модерация не подменяет инженерную экспертизу. Модератор проверяет структуру, источник и непротиворечивость, но не гарантирует пригодность объекта.

MVP

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

ИИ не является основой MVP. На следующем этапе он может извлекать параметры из технических паспортов и планов, но каждое распознанное значение должно попадать в очередь человеческой проверки с указанием исходного фрагмента документа.

UX, стек и план

Рабочая матрица как главный экран

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

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

Архитектура

Публичная часть и закрытый кабинет имеют разные требования, поэтому используется разделённый frontend при едином бизнес-ядре. Бизнес-правила не дублируются в Next.js: статусы, пригодность, версии характеристик и права рассчитывает backend.

Интеграции MVP ограничены email-уведомлениями, импортом объектов из табличного шаблона, картографическим отображением и экспортом итогового комплекта. Корпоративная авторизация и документооборот остаются расширениями для отдельных клиентов.

Модель данных

Система строится вокруг семи основных сущностей.

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

Срок реализации MVP до запуска пилота — 16 недель.

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

Метрики

Метрики оценивают управляемость процесса, качество данных и скорость принятия решения. Они не подменяют инженерную проверку объекта.

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

Риски

Развитие после устойчивого MVP

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

Как меняется процесс

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

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