Реестр исполнительной документации: контроль по подрядчикам

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

Почему список имеющихся файлов не показывает готовность

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

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

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

Какие поля нужны в карточке документа

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

Практический набор полей:

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

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

Разделите статусы и события передачи

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

Нельзя считать документ принятым только потому, что сотрудник поставил галочку «файл загружен». Также важно различать внутреннюю проверку ПТО подрядчика и рассмотрение внешней стороной. На сводке должны быть видны оба состояния.

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

Как вести замечания, чтобы они действительно закрывались

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

Условный пример: в приложении отсутствует нужная привязка к участку. ПТО возвращает документ с конкретным замечанием, подрядчик загружает новую редакцию и отвечает, что изменено. Проверяющий рассматривает ответ и фиксирует результат. Сам факт новой загрузки не закрывает замечание автоматически.

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

Версии, дубликаты и неактуальные документы

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

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

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

Реестр по подрядчикам: видимость и ответственность

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

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

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

Что можно автоматизировать в первой версии

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

Генерацию актов, электронные подписи, передачу в систему заказчика или надзора рассматривают отдельными задачами. До обещания такой функции нужно проверить требования, доступные интерфейсы и полномочия участников. Простая нарисованная отметка «подписано» не заменяет предусмотренный способ подписания.

Что нейросеть может проверить до передачи ПТО

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

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

Если ИД уже ведётся в EXON, приоритетно использовать доступные реестры, замечания и версии этой системы. Заказная надстройка оправдана, например, для предварительного разбора входящих сканов. Связка: файлы подрядчика → черновик ИИ → проверка ПТО → установленный реестр. Перенос результата возможен согласованной выгрузкой или отдельно проверенной интеграцией, без обещания универсального API.

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

По сообщению НОСТРОЙ от 22 июля 2026 года, в опросе первого полугодия 2026 года участвовали более 2 000 компаний, членов СРО. Практическое использование специализированных продуктов с ИИ при работе с рабочей и исполнительной документацией подтвердили менее 1% из них, ИИ при работе с технической документацией применяют не более 7%. Это границы из публикации, точных долей НОСТРОЙ не приводит. Категории могут пересекаться, складывать их нельзя. Выборка состоит из членов СРО, поэтому на весь строительный рынок России вывод не переносится. Практический вывод для подрядчика: помощника стоит показывать на конкретном документе и проверяемом результате, а пользу пилота измерять отдельно.

Как оценить пилот без ложных процентов

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

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

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

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

Комплект к передаче: проверяйте связи между файлами

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

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

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

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

Как отличить задержку подготовки от задержки рассмотрения

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

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

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

Источники

EXON, действия в Реестре ИД. EXON, исполнительные схемы, версии и замечания. Проверено 18 октября 2026 года. Описан внутренний контроль подготовки и комплектности, без заявления о соответствии самописного сервиса всем требованиям формального ведения ИД.

Смежные разборы: Кассовый разрыв подрядчика: как связать работы, акты и платежи; ИИ и база знаний: помощник по внутренним документам компании.