AI Office Field: от отчёта на объекте к принятым работам и документам

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

AI Office Field — концепция дополнительного модуля AI Office для строительства, монтажа и эксплуатации объектов. Его задача — связать задание, отчёт сотрудника, проверку результата и подготовку документов. Ниже описан предлагаемый сценарий разработки и пилота: готового мобильного модуля Field в текущем продукте пока нет.

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

Проблема возникает между событиями. Фотография не привязана к позиции сметы. Сообщение «готово» не означает приёмку. Присутствие на объекте не объясняет, сколько времени ушло на монтаж, ожидание материалов или устранение замечаний. Даже аккуратный архив файлов не соединяет эти факты сам по себе.

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

Системы для такой работы уже существуют. Например, PlanRadar описывает управление документацией, отчётностью и графиками для строительства и эксплуатации зданий. Сам по себе фотоотчёт с объекта не является новой категорией продукта. Идея Field — встроить полевые данные в общий процесс AI Office, где уже рассматриваются задачи, документы и согласования. PlanRadar · Construction and real estate management platform ↗

В предлагаемом сценарии сотрудник открывает задание на телефоне: объект, зона, вид работ, единица измерения, план и актуальная инструкция. «Смонтировать профлист, западный фасад склада, позиция 24, план на смену 40 м²» гораздо полезнее общего поручения «продолжить фасад».

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

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

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

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

Разберём условный пример учёта выполненных работ. Общий объём позиции составляет 200 м². До сегодняшней смены принято 80 м². Бригада заявила ещё 42 м², но прораб принял только 38 м²: оставшиеся 4 м² требуют переделки.

Прогресс по внутренней приёмке — 118 / 200 = 59%. В оставшиеся 82 м² входят и четыре квадратных метра на доработке. Их нельзя одновременно считать принятыми и включать в остаток. Когда замечание устранят, повторная приёмка добавит только эти 4 м², а не весь исходный отчёт ещё раз.

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

Полезный отчёт отвечает на три вопроса: что заявили, что проверили и что приняли. Одно поле «выполнено» не заменяет эти три состояния.

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

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

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

Геолокация тоже даёт дополнительный контекст. Android позволяет пользователю предоставить приблизительное местоположение вместо точного. Поэтому точку на карте нельзя считать безусловным доказательством нахождения в конкретном помещении. Android Developers · Request location permissions ↗

Для Field разумно предусмотреть фиксацию местоположения только в оговорённых событиях, например при начале задания, с отображением доступной точности. Этаж, помещение, оси здания или QR-код оборудования могут быть полезнее координат внутри большого комплекса. Если местоположение недоступно, отчёт получает отметку для проверки, а выполненная работа не исчезает из учёта.

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

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

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

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

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

На объекте регулярно возникает просьба: «Перенесите ещё три светильника». В сценарии Field это отдельная заявка на изменение: описание, инициатор, место, фотографии, предполагаемый объём и влияние на текущие задания. ИИ может помочь оформить сведения, но изменение базовой сметы требует согласования уполномоченным человеком.

Версии сметы и задания сохраняются. Иначе через месяц будет невозможно объяснить, почему выросли объём и стоимость. Особенно полезно видеть работы, которые уже приняты внутри компании, но ещё не включены в документы заказчику: это повод проверить оформление, а не автоматически признать выручку.

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

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

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

Подвал, технический этаж или удалённый объект могут остаться без устойчивой связи. Сотруднику нужно открыть заранее загруженное задание, сохранить отчёт и фотографии на устройстве и позже передать их в офис. Документация Flutter описывает подход offline-first с локальными и удалёнными данными и отдельной логикой синхронизации. Это архитектурный ориентир, а не утверждённый выбор технологии Field. Flutter · Offline-first support ↗

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

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

Прототип можно начать с мобильной веб-формы, но нельзя обещать одинаковую фоновую загрузку на всех телефонах. MDN отмечает ограниченную доступность Background Synchronization API в браузерах. Поведение после закрытия приложения, блокировки экрана и восстановления связи придётся проверять на целевых устройствах. MDN · Background Synchronization API ↗

Локальная AI-станция в офисе не устраняет расстояние до объекта. Пока соединения нет, руководитель видит последние полученные данные с временем обновления. Работа на устройстве может продолжаться, однако актуальный сводный отчёт появится после синхронизации и проверки.

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

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

Если компания уже использует приложение для стройки или эксплуатации, сначала стоит оценить его API или экспорт. Для полноценной связи нужны устойчивые идентификаторы, статусы, исходные вложения и история изменений. Один итоговый PDF может быть полезен человеку, но недостаточен для надёжного автоматического обмена объёмами.

Разделение ответственности в проекте принципиально:

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

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

В local-first-сценарии основные документы и обработка могут оставаться в инфраструктуре компании. Внешнюю модель подключают только для согласованных задач и данных. При этом телефон становится ещё одним местом хранения: на нём остаются задания, фотографии и незавершённые отчёты.

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

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

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

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

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

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

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

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

Условный расчёт помогает оценить масштаб: если шесть прорабов экономят по 20 минут в течение 22 рабочих дней, это 44 часа в месяц. Ещё 45 минут в день на офисной обработке дают 16,5 часа. Вместе — 60,5 часа высвобождённого времени, если эти предположения подтвердятся. Это не измеренный результат AI Office Field и не автоматическое сокращение расходов на зарплату.

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