Статья в печатном СМИ.
Владимир Малахов Генеральный директор ООО «Современные технологии генподрядного менеджмента» - СТГМ, Член президиума национальной ассоциации инженеров-консультантов в строительстве – НАИКС.
Сдвиг в отношении к проблемам внедрения BIM-технологий, который произошел в сознании, как отраслевого строительного сообщества, так и в представлении многих государственных служащих, в том числе высокого ранга, начал создавать благоприятное ощущение достижимости поставленных целей. Степень иллюзорности этих ощущений еще предстоит оценить, но сам факт возникновения дискуссий о необходимости системного макроэкономического подхода к решению этой задачи, говорит об осознании важности внедрения информационного моделирования и BIM-технологий в принципе. В то же время, сегодня встал серьёзный вопрос о качестве исполнения поручений Президента в части внедрения BIM-технологий, выданных Минстрою России на весеннем Госсовете 2016 года, их своевременности и адекватности поставленным стратегическим целям. Если еще год назад можно было говорить о том, что в критической массе экспертного сообщества и чиновников от строительства наступило понимание необходимости и эффективности внедрения BIM, то сегодня многие говорят о системной остановке этого процесса в силу необходимости реальных шагов по изменению законодательства и стандартов, на которые нет ни политической воли, ни лидеров, которые могут её проявлять. Как отмечает большинство экспертов строительной отрасли, главным препятствием в развитии BIM-технологий остается отсутствие системной государственной логики в реализации поручений Президента.
Любая дорожная карта по внедрению BIM так или иначе заканчивается абсолютно бюрократическим перечислением этапов, которые можно переписывать из года в год без особых изменений: внести изменения в законодательство, разработать стандарты и сформировать инфраструктуру подготовки кадров и сертификации BIM-менеджеров. Отличие таких дорожных карт друг от друга заключается только в перемещении дать и сроков для реализации этапов, но никак не касается ни позитивной концепции появления новых участников рынка, ни плана создания единого информационного пространства отрасли (BIM-среды), ни правил позиционирования, идентификации и деятельности основных участников BIM-инфраструктуры.
Как мы уже не раз отмечали, технологии информационного моделирования – это, прежде всего, технологии объединения цифровых инструментов управления инвестиционно-строительным проектом, включающим этап создания объекта недвижимости и управления его жизненным циклом после начала эксплуатации. Именно такая бинарная проектная специфика связывает задачи управления ЖЦ будущего объекта недвижимости и задачи концептуального и иного проектирования на первом проектном этапе, а, соответственно, требует и сквозного инструментария для эффективного связывания этих главных этапов проекта. Второй, не менее сложный вопрос, это, собственно, инструментальный состав BIM-платформы. Почему-то сложилось некое «про-проектировочное» представление, что внедрение BIM – это обязательно какие-то графические 3D-редакторы с расширенным опционалом вплоть до 6D(7D)-технологий, которая является главенствующей надстройкой над прочими программами по управлению отдельными разделами проекта, начиная от банальных инвестиционно-аналитических и расчетно-математических приложений и заканчивая специализированным инструментами контроля графика, бюджета, документооборота, электронной коммуникации и диспетчеризации, управления персоналом и, в том числе, бухгалтерского учета. Между тем, мы всегда понимаем BIM, именно, как интегральный подход комплексного управления инвестиционно-строительным проектом, как в процесс создания, так и в процессе эксплуатации, который обязательно включает возможность подключаться всем участникам проекта и участвовать в реализации проекта путем электронного взаимодействия. Это говорит о том, что управление проектом через BIM-платформу возможно только при условии равенства использования любого программного обеспечения, имеющего соответствующий допуск на присоединение к единой BIM-платформе.
Вместе с тем, именно необоснованная концентрация на графическом воплощении проектных решений, их экспертизе и верификации, по сути, приводит к искусственной синонимизации BIM и 3D-графики, что абсолютно разрушает парадигму информационного моделирования как самостоятельного управленческого феномена. BIM-платформа предполагает необходимость и возможность создания таких приложений, которые и вне графических редакторов существенно облегчают взаимодействие, делают управление проектом открытым и прозрачным. В некотором роде, BIM-платформа должна предоставлять возможность своеобразного режима OPEN BOOK, который одновременно дает участникам проекта совместно воспринимать новую информацию, и, в то же время, работать со своим пулом информации без помех.
Одним из примеров возможного неграфического приложения является ЕЭК – единого электронного контракта, о котором мы уже рассказывали. В рамках настоящей статьи мы не будем углубляться в детали создания Единого Электронного Контракта (ЕЭК), но постараемся повторно обратить внимание на создание такого программного продукта, поскольку он не просто превращает работу по контрактации в управление открытой самостоятельной базой данных, но и формирует некую поведенческую привычку для всех участников проекта. Эта привычка, или навык, или устойчивый механизм взаимодействия заключается в том, что участники проекта привыкают к обязательности привязки каждого нового документа к истории и логике реализации проекта в прошлом и будущем. Исчезают, так называемые, «понятийные договоренности», уходят риски забывчивости исполнителей, уходит возможность манипулирования документами, особенно если каждый электронный документ в контрактах имеет завершенную форму и последствия для графика и бюджета.
Можно с уверенностью сказать, что наиболее опасен ЕЭК будет как раз не для исполнителей – они и так всегда подстраиваются под требования Заказчиков, а именно для Заказчиков, поскольку именно его управленческая и бюджетная неэффективность станет необычайно наглядной. Внедрение ЕЭК заставляет акцентировать внимание на том, что важным эффектом такого решения является уничтожение псевдо-обоснованного «бумажного творчества» юристов всех уровней и всех участников проекта с долгим и непродуктивным согласованием каждой строчки контракта, а, тем более, приложения или дополнения. Подобное контрактное творчество не только создает бесконечную путаницу в контрактных отношениях участников проекта, но и заведомо провоцирует участников на коррупционные и иные неправовые действия, связанные с реализацией контракта.
Понятно, что отсутствие возможности быстро и легко менять условия контракта – это первый шаг в повышение открытости и прозрачности реализации проекта. ЕДИНЫЙ ЭЛЕКТРОННЫЙ КОНТРАКТ – это, как мы отметили, специальная база данных о всех контрактах проекта в течение его ЖЦ, установленная в сертифицированном программном обеспечении, но не просто уровня СУБД, а гораздо выше – системы управления информационной моделью (СУИМ), поскольку должна привлекать данные и из других информационных сервисов и баз. Чем мы сегодня можем дополнить тему оптимизации управления инвестиционно-строительными проектами в разрезе неграфического BIM-инструментария? Стоит начать с того, что основная результативность от внедрения BIM-технологий начнет сказываться на экономике по мере ввода новых объектов в эксплуатацию и появления критической экономии от эффективного управления недвижимыми активами в ближайшей перспективе. Но мало кто говорит о том, что для оценки такой эффективности и релевантного сравнения одних активов с другими требуется наличие какого-то универсального инструмента, который бы позволял сравнивать затраты и эффективность реализации проекта до ввода актива в эксплуатацию. Существующие сегодня индексы и система разработки сводного сметного расчета (ССР) никак не отвечает целям прозрачности, сравнимости и учетной сопоставимости затрат всех участником инвестиционно-строительного процесса, хотя в мире существует достаточно положительных примеров такого учета (см. Рис.1).
Эксперты строительной отрасли сегодня довольно уверенно констатируют практическую невозможность проведения актуальной оценки активов разного времени постройки, тем более с учетом того, что у них была большая разница в нефизическом CAPEX. Так или иначе сегодня приходится сравнивать исключительно физический CAPEX и для это требуются данные многих исполнителей проекта, которых сегодня фактически не существуют как юридических лиц (см. Рис.2). А тот факт, что нет и самих строителей, инженеров, проектировщиков или архитекторов этих проектов – является причиной абсолютной несопоставимости подобных оценок.
Одно из важнейших управленческих решений в этой области – введение понятия ПРОЕКТНОГО УЧЕТА, как самостоятельной опции Единого Электронного Контракта, который, в свою очередь, является самостоятельной опцией BIM-платформы. Первый вопрос, который обычно возникает при обсуждении проектного учета – зачем это нужно и имеет ли смысл порождать дополнительные понятийные сущности, усложняющие нашу жизнь? Прежде всего, надо попытаться сначала дать точное определение ПРОЕКТНОГО УЧЕТА как самостоятельного когнитивного явления, из которого можно самостоятельно сделать вывод о его важности и актуальности. Проектный УЧЕТ – это, по аналогии с бухгалтерским учетом (см. Рис.3), самостоятельная электронная система сбора, регистрации и обобщения информации в денежном выражении обо всех операциях с ресурсами, контрактами, имуществом и иными активами всех участников ПРОЕКТА, осуществляемого путём непрерывной электронно-документальной фиксации всех событий и изменений, происходящих В ПРОЦЕССЕ ЕГО РЕАЛИЗАЦИИ.
Сегодня можно уверенно заявить, что Единый Проектный учет стал возможным именно благодаря появлению BIM-философии, как единой методологической основы управления ЖЦ объекта недвижимости на всех этапах его существования и создания. Отсутствие единой базы, олицетворенной в виде BIM-платформы, не позволяло участникам проекта формировать однородные системы управления и эффективно взаимодействовать внутри проектной деятельности в части учета и контроля затрат, оценки эффективности капитальных вложений или ценообразования и анализа себестоимости отдельных элементов капитальных вложений. Дискретность процесса управления инвестиционно-строительным проектом, сопряженная с его длительностью, стоимостной волатильностью, постоянными изменениями структуры и состава участников, не говоря уже о проектной эффективности и умышленного сокрытия информации, не позволяла четко отслеживать все элементы СКВОЗЬ ПРОЕКТ. Именно BIM-технологии стали основой для появления такой возможности в рамках деятельности системных BIM-операторов.
Организация единого проектного учета позволяет не только формировать базы реальных стоимостных данных по элементам затрат, но и формировать реальные сравнительные базы модельных аналогов, как комплексных, так и единичны, для моделирования стоимости новых объектов. Не говоря уже о чистоте, прозрачности и борьбе с коррупцией. Сегодня фактически не существует ВООБЩЕ возможности вести аналоговое моделирование: половина затрат или не входит в CAPEX или сознательно скрыта Заказчиком. Мы многократно говорили о том, что отсутствие в ССР затрат на управление проектом, является одной из причин неэффективности управления проектами в России и неконкурентоспособности продукции российских Заказчиков и Инвесторов, скрывающих затраты на управление проектами в операционных издержках вне проекта. Проектный учет будет призван для точного отражения затрат ЗАКАЗЧИКА, относимых на проект в принципе, в результате чего, скрыть многие затраты в составе текущих операционных расходов просто не получится. Разумеется, в первое время эксплуатации систем проектного учета потребуется серьезная разъяснительная работа в том, что каждый участник проекта должен честно и открыто учитывать свои издержки, которые он хотел бы отнести на конкретный проект. Развитие проектного баланса включает (см. Рис.4) разделение затрат на физический и нефизический CAPEX, тем самым формируя базу для сравнительного анализа аналогов и сходных однородных объектов, зданий или сооружений. Такое разнесение позволит быстро сформировать единичные или укрупненные издержки по реальным физическим ресурсным затратам, а не по относимым на них нефизическим финансовым или иным косвенным издержкам.
Правая часть проектного баланса представляет собой разбиение на внутренний и внешний исполнительский корпус, который подразумевает, что часть функций в проекте Заказчик или Застройщик может закрывать сам, с помощью своего персонала. Понятно, что здесь как раз и должны появиться те самые специалисты Заказчика, которые реально занимаются управлением проектом, даже если это входит в их обязанности в размере 1 час в месяц. Точное распределение функций между внешним аутсорсером и собственным нанятым работником позволяет не только выявить аналитически выигрыш или потери от неправильной контрактной модели, но и показать направления для управления исполнительским блоком. Вполне вероятно, что на части проектов внутренние специалисты будут дешевле внешних (им не требуется платить прибыль), но, как показывает практика, чаще всего это иллюзорное преимущество. У сильных Заказчиков и внутренняя стоимость специалиста всегда выше, чем у нанятого подрядчика, и его загрузка менее гармонична и сбалансирована по рабочему графику проекта, т.к. для него это часто единственный проект. Подобный проектный учет позволит решить окончательно вопрос о том, кто выгоднее – ВНЕШНЯЯ ИНЖИНИРИНГОВАЯ КОМПАНИЯ или внутреннее подразделение капитального строительства? Очевидно, что экономика инжиниринга от такого анализа только выиграет.
Кроме того, единый проектный учет позволяет решать задачи оптимизации управления проектом в целом и поиска узких мест по этапам, по мере прихода новых исполнителей, устранения неэффективных исполнителей и их кураторов у Заказчика. Ни для кого не секрет, что эффективная реализация инвестиционно-строительного проекта начинается со структуры проекта, с контрактной модели и гармонизации проектных структур Заказчика и исполнителя. Чем более они соответствуют одному уровню – тем эффективнее будет реализация проекта, а значит и точнее учетные данные при формировании контрольных бюджетов и отчетности в целом.
Более того, единый проектный учет формирует исходные данные для бухучета в каждой компании - участнике проекта, тем самым облегчая работу и налоговиков, и Заказчиков (см. Рис.5). Проводки (двойной учет) в проектном учете делаются по аналогии с бухгалтерским, но проектный учет может иметь и тройной и более глубокий слой субсчетов, которые позволяют вести детальную аналитику и сравнивать её с плановым бюджетом. По большому счету, именно проектный учет может стать реальным инструментом УПРАВЛЕНИЯ СТОИОМОСТЬЮ, когда аналитик видит одновременно и плановые показатели и фактические по каждому контракту.
Проектный учет также может стать основой для введения т.н. ПРОЕКТНОГО НАЛОГООБЛОЖЕНИЯ, которое уже много лет предлагают эксперты строительного рынка. Сегодня Заказчики и Инвесторы вынуждены платить колоссальные средства в бюджет в ходе реализации проекта, то есть те самые средства, которые еще не дали инвестиционного дохода, которые очень нужны инвестору для оплаты услуг и работ исполнителей, но он вынужден наполнять ими бюджеты. Может это и выгодная для государства политика, но именно она ведет к банкротству большинство строительных и инжиниринговых компаний, а ПРОЕКТНОЕ НАЛОГООБЛОЖЕНИЕ – это обложение налогами всех участников ПО РЕЗУЛЬТАТАМ ПРОЕКТА, позволило бы многим участникам проектов организовать эффективный финансовый менеджмент без ущерба для проекта, особенно для тех, кто имеет постпроектные обязательства и существенные межпроектные издержки.
Формирование специальных приложений по проектному учету позволит не только формировать комплексные ценовые параметры моделей будущих проектов, но и качественно оценивать реальные нефизические издержки проекта. Это своеобразная предварительная очистка CAPEX от нефизических издержек делает стоимостной инжиниринг и стоимостное моделирование проектов не только инвестиционно-обоснованным, но и технологически быстрым. В определённом смысле, стоимостной инжиниринг может отказаться от укрупнённого оценочного экспресс-анализа и перейти к экспресс-оценкам на основе реальных данных из учетной базы проектов.
Источник здесь.
