Традиционная методика планирования строительства "ПОС + сметы" против мобильных "итеративных" методик

Я опубликовал видео с видеоуроком показывающим как работала традиционная методика планирования стройки в СССР, которая де-факто продолжает работать в России и СНГ. Это сразу вызвало жаркие дискуссии, т.к. на самом деле таких методика не одна, а две и они конкурировали между собой еще в Советском Союзе и сторонники их конкурируют между собой до сих пор. "Традиционалистом" является к пример руководитель ПМСОФТ г-н Цветков реализующий такую же методологию на 30% средствами Primavera и на 70% средствами 1С и сметных комплексов. "Нетрадиционное" нормирование и планирование развивает г-н Либерзон на Spider Project. Как мне кажется основной резонанс видео получило за счет того, что впервые показало как на базе Turbo Planner состыковать в непрерывный бизнес-процесс традиционного "водопадный" метод последовательного планирования от смет к графикам с итеративным планированием быстро реагирующим на риски и главное дающие возможности оптимизаций.

Модель последовательного планирования в СССР от проектной к строительной организации

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

Традиционная Waterfall-модель планирования в СССР от проектной к строительной организации

Традиционный бизнес-разбит на две части и идет методом последовательного планирования, т.е. является по-сути разновидностью планирования класса "Водопад" (Waterfall), т.е. без частых возвратов на предыдущие стадии планирования от последующих. Итеративные методы планирования строительства мы рассмотрим в следующем разделе.

И так, традиционный метод традиционно поддерживается СНиПами "Организация строительства" и закреплен Постановлением правительства РФ №87 от 2008 года:

23.Раздел 6 "Проект организации строительства" должен содержать:
[Требование к детализации ИСР (WBS)]
и) перечень видов строительных и монтажных работ, ответственных конструкций, участков сетей инженерно-технического обеспечения, подлежащих освидетельствованию с составлением соответствующих актов приемки перед производством последующих работ и устройством последующих конструкций;
[Требование к связям работ (Task Links)]
к) технологическую последовательность работ при возведении объектов капитального строительства или их отдельных элементов;
[Требование к плану ресурсов в периодах (Resource Plan)]
л) обоснование потребности строительства в кадрах, основных строительных машинах, механизмах,транспортных средствах, в топливе и горюче-смазочных материалах, а также в электрической энергии, паре, воде, временных зданиях и сооружениях;
[Требование обосновать длительность работ (Task Durations)]
у) обоснование принятой продолжительности строительства объекта капитального строительства и его отдельных этапов;
[Требование составить общий график производства работ (Schedule)]
х) календарный план строительства, включая подготовительный период (сроки и последовательность строительства основных и вспомогательных зданий и сооружений, выделение этапов строительства);

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

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

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

Проектная организация объявляет верхнюю часть иерархической структуры строительно-монтажных работ (Иерархическая структура работ, ИСР, Work Breakdown Structure, WBS) как реестр локальных смет. Планировщик ПОС дублирует его в ИСР (WBS) в проектной системе.
Сметчики разрабатывают отдельные блоки СМР включая:
- детализацию ИСР (WBS)
- ресурсы
- стоимости
Сметчики передают сметы планировщику ПОС и он их импортирует в ветки общей ИСР (WBS)
Планировщик ПОС рассчитывает длительность операций полученых из смет такими методами:
- задает календарь смен и численность ресурсов, программа считает ему длительность автоматически
- задает производительность подрядчика или собственных сил, а программа рассчитывает длительность исходя из этого.
В итоге планировщик ПОС получает календарно-сетевую модель где сметы с объемами, ресурсами и деньгами распределились по времени, поэтому он может сделать ведомости потребности в ресурсах и финансировании как тот требует СНиП и передать ее в строительную организацию.
В строительной организации сотрудники МТО на базе ведомости с потребностями в материалах, машинах и специальностях разрабатывают детальные планы снабжения.
Финансовая служба инвестора ориентируясь на потребность в финансировании разрабатывает детальный план финансирования.
Планировщик ПТО увязывает план снабжения и финансирования в одну Единую Календарно-Сетевую Модель Строительства.

Собственно такими же шагами как показано на Turbo Planner в учебном видео пытается внедрять решения и г-н Цветков. Для этого:

Для интеграции со сметами используется модуль PM Agent интегрированный с Primavera
Для детального планирования поставок используется модуль PM Procurement написанный на 1С и интегрированный с Primavera
Для детального планирования финансирования используется модуль PM Cost Engeenering написанный на 1С и интегрированный с Primavera

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

Примерно 70% строительных смет крайне низкого качества и непригодны для планирования строительных работ.
Сметы очень часто опаздывают к реальному началу работ, поэтому метод вообще непригоден для планирования в таком случае
Дополнительной проблемой является реализация методики на функционально недостаточно комплексе Primavera, т.к. в отличии от Turbo Planner она не имеет средств моделирования физических объемов и связанного с ним понятия производительности. Поэтому ПМСОФТ вынужден использовать исключительно директивные сроки, что не устраивает часть клиентов, т.к. они их просто не знают по операциям.
Традиционная методология как разновидность последовательного планирования "Водопада" (Waterfall) имеет свои традиционный минусы как низкая скорость реакции на изменения в проекте и часто практическая невозможность быстро перепланировать проект после изменений в ПСД или после получения фактических данных не совпадающих с планом. В случае решений ПМСОФТ, где каждый шаг планирования это перелив данных между россыпью отдельных программ частый обмен данным для перепланирования обычно имеет запредельную трудоемкость для плановиков, но тут сказывается IT-ограничения платформы Primavera и 1С.

Но основная проблема в том, что сотрудники ПОС утратили практику контроля за сметчиками и сообщения им, что выпускаемые сметы не соотвествуют технологии строительства. Поэтому чтобы внедрять решения ПМСОФТ или Turbo Planner по такому же сценарию обязательным условием является восстановление интеграции совместной работы планировщиков ПОС и сметчиков под общим начальством. Это возможно либо если проектная организация готова к этому, либо путем создания аналогичных структур как у проектной организации в строительной. По моей практике очень известный специалист в строительном планировании Сергей Луговцов так и организует планирование "от смет". А именно редактирование смет проектировщиков до получения соответствия с реальной строительной технологией, а только потом импорт в проектную систему.

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

Бизнес-процесс планирования имеет масштабирование на сколь угодно крупные строительные проекты за счет того что 90% трудоемкости разработки отдельных блоков работ по составу и ресурсам ложится на коллектив сметчиков, который можно расширять при необходимости и их работа методически уже организована в параллель
Возможно очень детальное и точное планирование "до гвоздя" за счет использования высокой сметной детализации
Справочники норм и ресурсов строятся не на пустом месте, а на базе стандартных справочников Минстроя и Минрегиона, что позволяет использовать их нормы там где они правильные, но главное легко добиваться консолидации данных для отчетности за счет стандартизованных кодировок ресурсов и норм

Методика как видим очень хороша и по масштабируемости и стандартизации на голову превосходит методику заложенную в Spider Project, однако из-за хаоса в осмечивании в 70% случае сработает именно альтернативный вариант "итеративного планирования", который как раз и спроектирован чтобы работать среди хаоса и постоянных изменений от рисков. Итеративные методики планирования стройки ПМСОФТ реализовать не может, т.к. из-за функциональной бедности Oracle Primavera не может собрать всю модель в проектной системе, чтобы от любой корректировки она сразу пересчитывалась без необходимости перелива данных. Интегрированное итеративное управление стройкой возможно в Spider Project и в Turbo Planner, т.к. модули нормирования, финансирования и снабжения у них интегрированы в одно целое. Рассмотрим итеративные подходы.

Методики оптимизации графика СМР с финансированием и поставках на укрупненных нормах от практик строительных трестов СССР

Можно сказать, что Spider Project и Turbo Planner в итеративной методике строительства - это строительный Agile/Scrum. В итеративном подходе самое главное не шаги планирования, а возможность делать следующее:

Модель строительства должна моментально пересчитываться на новый вариант после ввода нового показателя. В Turbo Planner реализован даже LIVE-расчет "на лету", в смысле, что после ввода нового объема пересчитаются мгновенно сроки, закупки и финансы. В Spider Project это требует запуска пересчета проекта, но не перелива данных между россыпью программ в зоопарке разных архитектур как в ПМСОФТ.
Из предедыдущего следует, что модель должна планировать все показатели как связанные, а не отдельно смета, отдельно сроки, отдельно закупки и отдельно платежи как в традиционном варианте.

Схема итеративного строительного планирования очевидно имеет проблемы масштабирования, т.к. работает только через модель единого планировщика как на схеме. Отсюда к слову и названия продуктов. Turbo Planner - "Турбо планировщик", а Spider Project изображает на эмблеме планировщика как Паука, который держит все нити проекта в своих руках.

Итерационная модель строительства на укрупненных нормах известная и строительным трестам СССР

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

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

Следует отметить, что методика планирования на укрупненных нормах широко использовалась в строительных трестах СССР. В частности в РЖД Строе осталась до сих традиция "трех десяти", т.е. тщательное планирование 10 крупнейших материалов, 10 крупнейших машин, 10 крупнейших специальностей. По правилу Парето это дает ресурсный контроль на 80% ресурсных факторов влияющих на стоимость и сроки.

Тут отчасти открывается секрет, почему Spider Project и Turbo Planner могут работать сценариях итеративного планирования даже когда сметчики не могут разобраться в своих нормах. Просто ввести укрупненные нормы на 2-3 порядка проще чем детальные. Например, чтобы тому же РЖД Строю иметь хорошие планы нужно ввести нормы всего для 30 видов ресурсов. Опытный планировщик строительства может решить эту проблему за 1 месяц включая актуализацию этих норм по фактическим данным.

И так, итеративное строительное планирование имеет такие плюсы:

Каковы бы не были риски вашего строительного проекта в том числе в хаосе организации его управлением, итеративные методики созданные для работы в условиях сверхрисков будут работать. Даже если если ваш проектный институт это наркоманы, а их проектная документация ничего не вызывает кроме ужаса
Хотя итеративный метод управления стройкой имеет некоторые проблемы с масштабированием планирования на N специалистов, но за счет его реализуемости силами даже 1го планировщика даже на крупном проекте итеративное строительное планирование имеет просто выдающиеся показатели по стоимости владения системой планирования (Total Ownership Cost, TOC). По TOC внедренные в итеративном сценарии Spider Project или Turbo Planner обойдутся вам в 5-8 раз дешевле, чем заведомо забюрократизированное "традиционное" решение как у ПМСОФТ
Традиционное планирование через ПОС не содержит в себе оптимизаций с целью сокращения сроков работ и подбора более оптимальных вариантов. Итеративные методики всегда оптимизационные и позволяют легко работать со множество вариантов планирования и мгновенно реагировать на изменения, т.к. итерационные модели построены на действительно Единой Календарно Сетевой Модели Строительства

Но как я уже отмечал итеративные методики имеют и минусы и то, что тот же Spider Project не может работать в традиционном сценарии как Turbo Planner это проявляется вот так:

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

Как видим, итеративные методики страдают от точности оценок ресурсов в сравнении с традиционными. Это к слову одна из причин почему в Spider Project практически нет внедрений на широко рекламируемом Resource Leveling (оптимизация загрузки людей и машин). Дело в том, что алгоритму нужны качественные данные по машино- и человекочасам. Укрупненные нормы в традиционном сценарии слишком грубые, чтобы выдать правдоподобную оптимизацию, а детальные нормы "по-сметному" Spider Project не умете загружать не портив их из-за другой математики норм (эта проблема стандартизации нормирования описана в данной статье).

Соединяем традиционный и итеративный подход в Turbo Planner

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

Если вы еще не догадались, то Turbo Planner впервые предложил решение, где традиционная сметная методика не конкурирует с итеративной, а оба решения бесшовно интегрированны в одно решение.

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