4 - 2014

Autodesk Field 360, или Полевой журнал строителя

Дмитрий Сарычев
Руководитель проектов по внедрению BIM и PLM/PDM, компания Consistent Software Distribution

Строительство можно назвать одной из самых консервативных отраслей экономики. Вопросы оптимизации и экономии мало волнуют растущий год от года сектор, что вполне логично. Оптимизация процесса возведения здания, как правило, сводится либо к внедрению новых технологий производства работ, либо к применению новых управленческих подходов. По данным института CII (Construction Industry Institute), 90% инноваций в строительстве приходится исключительно на проектирование. И это в век мобильных технологий, интерактивного лазерного сканирования и информационного моделирования! Возникает закономерный вопрос: а возможны ли вообще какие­либо улучшения от применения современных технологий «в поле»? Нельзя ли при сохранении уже существующей системы производства строительных работ обеспечить экономию денежных средств за счет повышения прогнозируемости, гибкого управления, безопасности и, наконец, повышения качества производимых работ?

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

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

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

Основным коллектором всех производимых работ, в соответствии со СНиП 12­01­2004 «Организация строительства», является документ «Общий журнал работ». Сами же работы, в свою очередь, генерируют множество закрывающих актов, контрольных листов и прочих документов, связанных с процессом возведения здания. Более того, большинство материалов и готовых конструкций, используемых при строительстве, требуют входного контроля качества, который также отражается в различных документах. И, конечно же, все инспекционные проверки органами государственного контроля и авторским надзором генерируют дополнительные работы и задачи, которые нужно контролировать, документировать и учитывать.

Решая задачу оперативного управления и планирования, можно было бы на основе содержания журнала работ и связанных с ним документов выполнять в режиме реального времени всеобъемлющий мониторинг состояния стройки, реагировать на любые нестандартные ситуации и координировать графики и планы. Даже неспециалист при помощи прикрепленных к журналу фотографий и 3D­представлений модели вполне может оценить объем выполненных работ. То есть формально застройщик и инвестор в процессе строительства «держат руку на пульсе», придерживаясь регламентированного нормами процесса. Казалось бы, ситуация на бумаге идеальна и улучшить ее уже невозможно.

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

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

Эффективность же такого первого шага напрямую зависит от того, насколько контроль процесса строительства актуален для застройщика и насколько своевременное управление позволяет ускорить процесс возведения здания.

Для ИT­служб технически организовать единое пространство — значит, создать некий виртуальный журнал работ, систему, в которой будут объединены:

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

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

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

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

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

В утвержденном взамен СНиП 3.01.01­85* документе СНиП 12­01­2004 появилось явное разрешение на электронную форму журнала работ (пункт № 16 «Указаний к ведению общего журнала работ»). Цитирую: «По разрешению органа архитектурно­строительного надзора допускается ведение журнала в виде электронного документа. При этом должны быть обеспечены надежная защита от несанкционированного доступа, а также идентификация подписей ответственных должностных лиц».

Хотя, если застройщик вынужден исполнять требования документа РД­11­05­2007, он уже гораздо более ограничен в использовании электронных систем, потому что, цитирую: «Общий журнал должен быть пронумерован, прошнурован, оформлен всеми подписями на титульном листе и скреплен печатью строительной организации, его выдавшей».

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

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

  • Aconex Field;
  • Autodesk Field 360;
  • Penta;
  • Procore;
  • ViewPoint.

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

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

  • «1С: Подрядчик строительства»;
  • «Галактика Строительство»;
  • «АЛТИУС — Управление строительством»;
  • «Стройбизнес Standard»;
  • «Адепт»;
  • «КОРУС».

Отсутствие Field Management в этом списке объяется легко. До тех пор, пока не появится законодательная база для использования «в поле» данных продуктов, довольно рискованно инвестировать в разработку функционала Field Management.

Но что же делать с нашей первоначальной задачей оптимизации строительных процессов? Ждать появления функционала в отечественных системах или попытаться применить зарубежные разработки?

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

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

Из приведенного выше списка программных продуктов наиболее ориентированной на работу «в поле» и наиболее перспективной является система Field 360 компании Autodesk. Этому способствует и интеграция с распространенной платформой Revit, и безопасная аутентификация пользователей OAuth, и поддержка функционалом Glue 360, и множество других возможностей. Хотя, конечно, до официального выхода на российский рынок Field 360 должен еще подрасти функционально. Скорее всего, он успеет значительно развиться, поскольку изначально разрабатывался как облачное приложение, способное эволюционировать гораздо быстрее «десктопных» решений. Более того, к моменту выхода на российский рынок Field 360 придется конкурировать с отечественными разработками в чужом для него правовом поле, и это наверняка подстегнет компанию Autodesk к внесению в свой продукт качественных изменений, в числе которых нам хотелось бы увидеть в первую очередь поддержку утверждения документов и интеграцию с аналитическими системами.

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

САПР и графика 4`2014