Цифровизация исполнительной документации⁠⁠

Пособие инженеру ПТО по исполнительной документации

Учет объемов в ИД одним нажатием клавиши

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

При этом многие разработчики программного обеспечения по ИД обещают заказчикам решить все их проблемы. А основной проблемой сейчас для всех является даже не контроль качества выполняемых работ, а именно контроль объемов работ в КС-2 и прикрытие этих цифр ИД.

С этой целью разрабы предоставляют возможность подрядчику вести в едином окне вместе с основными данными о производстве работ из раздела 3 общего журнала работ (ОЖР) также и учет объемов выполненных работ. Такой себе ежедневный КС-6а.

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

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

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

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

Почему так произошло, что основным бенефициаром всего этого геморроя назначен специалист ПТО?

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

Все потому, что результатом очень «удачной» реформы с введением РД-11-02-2006 и РД-11-05-2007 явилось то, что прорабы более не смогли исполнять свои обязанности по ведению ИД.

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

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

Для этого они не нашли ничего более эффективного как заставить ПТО (прораб бы послал на%ер) вести учет выполненных работ в ОЖР и дальше в АОСРах. А точнее и надежнее данных, чем в документах, в которых расписалось 5-7 человек, вы просто не найдете.

Но беда в том, что объемы все пишут по-разному и поди разберись что-куда и откуда. А желательно, чтобы потом легче было проверять КС-2.

И сначала автоматизация с помощью простых средств типа Excel, а затем и цифра просто вдохнули новую жизнь в эту идею, которая у большинства разрабов также сводится к заполнению 3 раздела ОЖР на единой основе, а не просто кто как умеет или как делал на прошлом объекте.

И естественно, нет другого документа, который бы подошел лучше для этой цели, чем смета. С нее типа одним нажатием клавиши проставляются объемы в разделе 3 ОЖР, далее все это зеркалится в АОСР и в итоге из АОСР – в КС-2... Вжух, и все готово!

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

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

В качестве подосновы нам кроме расценок из локальных сметных расчетов (ЛСР) предлагается также использовать позиции сметы контракта и создаваемый для этой цели набор работ.

И сейчас на наших глазах порочная практика ведения ИД ПТО вместо прораба закрепляется еще и алгоритмами ПО.

Плюс также потихоньку поправили профстандарт ПТО под нашу изуродованную действительность.

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

Проблемы учета объемов в процессе стройки и достоверность данных

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

• согласованные изменения в проекте (рабочке), которые пока еще не внесены в смету (смету контракта).

• незавершенное производство (НЗП), которое не дает легко и сразу проставить точный объем. При этом исполнители и проверяющие часто подразумевают под законченным объемом совершенно разное.

• недостоверные данные от прорабов (человеческий фактор), которые также часто не очень соображают в расценках и единицах измерения, либо просто припи%живают, чтобы показать выработку.

• ошибки ручного ввода данных ПТО (опять человеческий фактор).

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

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

Все это если не делает ежедневный и точный учет объемов невозможным, то делает его слишком трудоемким. А если это делать в ОЖР, то переписывать его, подгоняя объемы придется много раз, как и переделывать и переподписывать АОСР.

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

Куча зарубежных исследований по цифровизации ежедневных отчетов Daily Report (аналога ОЖР) таких ученых как Ronie Navon, Issam Haskaya, Alan D. Russel еще с 90-х годов подтверждает вышеуказанное – ручной ввод данных и человеческий фактор являются основными препятствиями на пути цифровизации основных сведений. С тех пор ничего особо не изменилось.

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

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

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

Проблемы учета объемов до начала стройки

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

Отсутствие нормальной структуры ЛСР. Работать с ЛСР настолько неудобно, что в них даже сметчику сложно найти нужную работу из рабочки.

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

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

Главной проблемой тут является отсутствие общего классификатора, как это есть у буржуев, на основе которого структурируются вообще все данные не только по стройке, но и проект, и сметы, и даже нормативы.

Решение этой проблемы вроде как есть – через ЦИМ (3D), которая позволила бы через визуал и КСИ связать эти две сущности. Но ЦИМ стадии строительства (РД или LOD 400) стала не обязательной опцией и потому вся эта работа остается ручной.

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

Несоответствие ЛСР рабочке. Ни для кого не секрет, что ЛСР на выходе из экспертизы никогда не бьются не только с рабочкой, но и с проектом по составу и объемам работ. Почему? – да это не реально. Тем более детализация проекта просто не позволит это сделать с необходимой точностью. И взяв за основу данные из ЛСР мы сразу закладываем кривую базу для дальнейшего учета.

Некоторые тупо не подписывают ИД, если там вписан состав работ с объемом, не соответствующим ЛСР или смете контракта. Типа так страхуются от допов или чтоб четко под подписанную КС-2 лежала подписанная ИД. И эта вынужденная глупость – прямое следствие подробного учета объемов работ в ИД.

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

Например, есть расценки на устройство ж/б конструкций, работу по которым в ОЖР нужно расписывать как это делается по технологии – армирование, опалубка, укладка бетона, уход за бетоном. А если захочется привязать к ним цены – то дополнительно нужно назначать % к каждой части такой расценки.

Еще нужно учитывать, что на один вид работ может быть несколько расценок (типа на каждый последующий слой добавлять…), а многие расценки являются применительными. Поэтому читать записи ОЖР и АОСР по точным наименованиям расценок с целью контроля работ – такое себе удовольствие. Оценка соответствия конструкций, влияющих на безопасность? – не, не слышали! Контроль расценок и деньги – превыше всего!

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

Набор работ. Дополнительно создавать и поддерживать некий набор работ с правильными объемами, с разбивкой и единицами измерения удобными для записей в ОЖР – считай мероприятие, сопоставимое с разработкой сметы контракта. Поэтому он так и остается в зачаточном состоянии. Все это требует длительной ревизии рабочки и смет.

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

Результативность и эффективность

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

При всем этом разрабы и многие заказчики забывают об одной очень важной детали – в какую цену будет достигнут результат?

Сказки про то, что вот сейчас цифрой облегчат ПТО работу с ИД можно сравнить с такими же сказками про сокращение трудоемкости проектирования в BIM.

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

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

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

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

В этом и заключается отсутствие эффективности во всей нашей модели цифровизации стройки.

Никто не отрицает, что учет должен вестись. И это делается.

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

Зачем закладывать это в программном обеспечении, нарушая требования законодательства и стандартов?

И вот когда вы жёстко завязываете ОЖР на первичную учетную документацию, когда оформляете абсолютно все, что есть в смете АОСРами, увеличивая объемы ИД в несколько раз (а многие цифровизаторы другого ничего придумать не могут), вы заставляете ИТР заниматься тупым мартышкиным трудом.

Такая документация априори не может вестись вовремя. Такая документация несколько раз переделывается, в том числе, когда у вас меняется смета по составу или объемам работ (иначе данные с КС-2 не совпадут). Такая документация будет по итогу недостоверной.

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

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

https://t.me/PTOmanual

Автор рукописи "Пособие инженеру ПТО по исполнительной документации"