Статьи

Autodesk Field 360, або Польовий журнал будівельника

Дмитро Саричев
Керівник проектів з впровадження BIM і PLM / PDM, компанія Consistent Software Distribution

Будівництво можна назвати однією з найконсервативніших галузей економіки. Питання оптимізації та економії мало хвилюють зростаючий рік від року сектор, що цілком логічно. Оптимізація процесу зведення будівлі, як правило, зводиться або до впровадження нових технологій виробництва робіт, або до застосування нових управлінських підходів. За даними інституту CII (Construction Industry Institute), 90% інновацій в будівництві доводиться виключно на проектування. І це в століття мобільних технологій, інтерактивного лазерного сканування та інформаційного моделювання! Виникає закономірне питання: а чи можливі взагалі будьякі поліпшення від застосування сучасних технологій «в полі»? Чи не можна при збереженні вже існуючої системи виробництва будівельних робіт забезпечити економію коштів за рахунок підвищення прогнозованості, гнучкого управління, безпеки та, нарешті, підвищення якості виконуваних робіт?

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

Кількість незапланованих додаткових робіт, викликаних збоями поставок, помилками будівництва або недостатньою якістю проектної документації, до сих пір досить велике

Щоб подивитися на будівництво з точки зору ІTрешеній, потрібно попередньо припустити, що всі вони націлені на управління даними. Відповідно, щоб знайти застосування цих технологій, слід розуміти, які потоки даних циркулюють на будівництві.

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

Основним колектором всіх вироблених робіт, відповідно до СНиП 12012004 «Організація будівництва», є документ «Загальний журнал робіт». Самі ж роботи, в свою чергу, генерують безліч закривають актів, контрольних листів та інших документів, пов'язаних з процесом зведення будівлі. Більш того, більшість матеріалів і готових конструкцій, які використовуються при будівництві, вимагають вхідного контролю якості, який також відбивається в різних документах. І, звичайно ж, все інспекційні перевірки органами державного контролю та авторським наглядом генерують додаткові роботи і завдання, які потрібно контролювати, документувати і враховувати.

Вирішуючи завдання оперативного управління і планування, можна було б на основі змісту журналу робіт і пов'язаних з ним документів виконувати в режимі реального часу всеосяжний моніторинг стану будівництва, реагувати на будь-які нестандартні ситуації і координувати графіки і плани. Навіть неспеціаліст за допомогою прикріплених до журналу фотографій і 3Dпредставленій моделі цілком може оцінити обсяг виконаних робіт. Тобто формально забудовник і інвестор в процесі будівництва «тримають руку на пульсі», дотримуючись регламентованого нормами процесу. Здавалося б, ситуація на папері ідеальна і поліпшити її вже неможливо.

Здавалося б, ситуація на папері ідеальна і поліпшити її вже неможливо

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

З цього випливає, що першим очевидним кроком до оптимізації існуючого процесу будівництва є впорядкування інформації журналу робіт в єдиному просторі. А крім того - забезпечення доступного представлення процесу зведення будівлі для людей, що не володіють будівельною освітою, але вирішальних глобальні фінансові завдання. І крок цей повинен гармонійно влитися в процес виробництва робіт на будівництві.

Ефективність же такого першого кроку безпосередньо залежить від того, наскільки контроль процесу будівництва актуальний для забудовника і наскільки своєчасне управління дозволяє прискорити процес зведення будівлі.

Для ІTслужб технічно організувати єдиний простір - значить, створити якийсь віртуальний журнал робіт, систему, в якій будуть об'єднані:

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

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

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

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

Юридично організувати єдиний електронний журнал робіт, що не вимагає додаткового паперового, - це ще і домогтися визнання електронної системи як офіційного документа і встановленого користувачем в електронній системі прапорця як юридично значимої підпису. У цьому питанні не все так гладко, як в технічному плані.

У затвердженому замість СНиП 3.01.0185 * документі СНиП 12012004 з'явилося явне дозвіл на електронну форму журналу робіт (пункт № 16 «Вказівок щодо ведення загального журналу робіт»). Цитую: «За дозволом органу архітектурностроітельного нагляду допускається ведення журналу у вигляді електронного документа. При цьому повинні бути забезпечені надійний захист від несанкціонованого доступу, а також ідентифікація підписів відповідальних посадових осіб ».

Хоча, якщо забудовник змушений виконувати вимоги документа РД11052007, він вже набагато більш обмежений у використанні електронних систем, тому що, цитую: «Загальний журнал повинен бути пронумерований, прошнурований, оформлений усіма підписами на титульному листі і скріплений печаткою будівельної організації, яка його видала».

У підсумку, щоб зробити електронний журнал робіт повноцінної самостійної системою, необхідно дотримати всі технічні і юридичні вимоги. Юридичні обмеження - це проблема тимчасова, ми з кожним роком отримуємо все більше актуализированную під сучасні умови законодавчу базу. Відповідно, зараз найбільш актуальною є рішення саме технічної задачі. Перебуваючи на вістрі технічного прогресу, необхідно бути готовим до визнання електронного польового журналу повноцінним документом. Адже навіть та електронна система, яка буде дублювати набір паперових документів, але дозволить вирішити поставлені спочатку завдання, надасть значно більше переваг, ніж витрат.

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

  • 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

Виникає закономірне питання: а чи можливі взагалі будьякі поліпшення від застосування сучасних технологій «в полі»?
Але що ж робити з нашою первинним завданням оптимізації будівельних процесів?
Чекати появи функціоналу в вітчизняних системах або спробувати застосувати закордонні розробки?

Новости