Ограничение метода сетевого планирования



Коллеги, кто-нибудь задумывался на тему того, что метод сетевого планирования для строительных проектов не очень подходит? На днях у меня с Викторм Клепа получилось интересное осуждение на эту тему.

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




Изначально сетевой метод применяется с целью показать технологию. В строительстве технология как и ресурсы и производительность - это ключи графика. Тогда возникает вопрос: «В каких условиях он не подходит?»

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

Что тут имеется в виду:

Допустим, что уровень детализации выполнен до рабочего процесса, например, для монолитной конструкции: установка опалубки, армирование, бетонирование, уход за бетоном.
Структура декомпозиции работ (EPS+WBS) строительного проекта будет представлять из себя следующий вид (как пример):

Уровень 1 – Фаза жизненного цикла инвестиционно- строительного проекта (Прединвестиционная, Инвестиционная, Эксплуатационная);

Уровень 2 – Этап выполняемых работ (предпроектные работы, проектирование, строительство, обучение, ПНР и ввод в эксплуатацию, Эксплуатация);

Уровень 3 – Стадия выполняемых работ (Исследование возможностей инвестирования, Прединвестиционные исследования, Обоснование инвестиций; Эскизное проектирование, разработка проекта, Разработка рабочей документации; Подготовка строительного производства, Основные СМР и т.д.)

Далее рассмотрим только Основные СМР на примере проекта строительства крупного промышленного объекта с количеством объектов в 50 ед.

Только для монолитных работ, количество задач в графике для одного промышленного здания с детализацией до рабочего процесса будет около 500. Типовой пакет работ (самый нижний уровень WBS) для каждого конструктивного элемента (не забываем, что необходима разбивка конструктивного элемента на захватки, участки, ярусы…) будет представлять собой: установка опалубки, армирование, бетонирование, уход за бетоном (с устоявшимся набором ресурсов для каждой задачи). Для простоты ограничимся только: одним трудовым ресурсом (арматурщик, опалубщик, бетонщик…), одной строительной машиной или механизмом (ГПМ, бетононасос …), одним физическим объемом, одним показателем стоимости, назначаемым на задачу – итого ресурсов, назначенных на 1 работу - 4).

Подбиваем промежуточные итоги:
  1. Работ по устройству монолитных конструкция на проекте из 50 зданий будет: 50 зданий * 500 работ = 25 000;
  2. Технологических (жесткие) и организационных (мягкие связи) взаимосвязей между работами около 50 000;
  3. Количество всех ресурсов, назначенных на задачи по устройству монолитных конструкций: 25000 задач * 4= 100 000.
Для упрощения, не будем считать отделочные работы, посчитаем только тепломонтажные и электромонтажные. Примем для упрощения их количество равным монолитным работам, т.е. итоги можно утраивать.


Подбиваем окончательные итоги по СМР:
  1. Всего строительно-монтажных работ в графике при детализации до рабочего процесса на проекте из 50 зданий: 25 000*3=75 000;
  2. Технологических (жесткие) и организационных (мягкие связи) взаимосвязей между работами около 150 000;
  3. Количество всех ресурсов, назначенных на задачи: 300 000.
Продолжаем рассуждать дальше:

Для каждой работы в графике необходимо присвоить различные коды работ для формирования отчетности, например: код здания, код системы, код вид выполняемых работ и др. Пусть их будет 5, тогда 75000*5=375 000
Желательно также установить связь с документами для каждой работы, например РД, ППР, Смета: 75000*3=225 000
Итого, суммарное количество данных в графике(ах) будет: 75 000 + 150 000 + 300 000 + 375 000 + 225000 = 1,125 млн.

А теперь, представим самое ужасное! Внесли изменение в проект: Изменили тип насоса, а соответственно изменилась его обвязка, изменились фундаменты, изменилась электрика и т.д.

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

Возвращаясь к началу: «Первой проблемой является чистый размер сети. При повторяющихся проектах, состоящих из сетей с количеством n-операций, которые должны быть повторены n-раз в дальнейшем и связаны с другими сетями; при таком подходе формируется огромная сеть, которой трудно управлять. Это может вызвать трудности при коммуникации участников команды управления строительством» при применении СУЩЕСТВУЮЩИХ ИНФОРМАЦИОННЫХ СИСТЕМ календарно-сетевого планирования!

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

Комментариев нет

Искусственный интеллект для управления строительными проектами

Данное видео рассматривает использование Chat GPT на примере управления строительным проектом. Получение WBS по ТЗ. Оценка сроков, ресурсов ...

Технологии Blogger.