Управление проектами в строительстве что это такое

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

Но что если я скажу Вам, что руководитель может всего лишь поставить перед своими сотрудниками большую задачу, а команда уже сама воплотит всё в жизнь без опозданий?

И даже самостоятельно устранит все “косяки”, выявленные в ходе действия. А что если такое будет постоянно? Классненько же? Тогда поговорим о Scrum.

Отвечая на Ваш немой вопрос о невозможности такого подхода, ведь мы же в России живем и люди тут так не работают, их только и нужно “пинать”. С уверенностью могу Вам сказать, что такое возможно (далее расскажу подробнее), но для этого в Вашей компании должно быть внедрено всего одно условие.

Та самая agile-методология (методология гибкого управления проектами), по которой должны работать сотрудники в Вашей организации.

Для примера, вспомните Сбербанк всего 5 лет назад. Хамство, ужас и постоянная ругань с бабушками. И всего 5 лет по прошествию и внедрению Германом Грефом идеологии аджайл. Сейчас Сбербанк не узнать. Конечно, осталось еще это “Где карту получали туда и идите”, но. все совершенно по-другому.

День 1. Модуль 1. Управление проектами строительства

Однако вернемся к методологии скрам.

Важно. Вначале статьи мы разберём в целом, что такое методика Scrum, преимущества и недостатки, а уже потом поговорим о том, как его внедрить в обычный бизнес. Наш блог всё показывает с практической стороны.

Что это такое

Методика Scrum — это технология гибкого управления проектами. Поскольку само понятие довольно сложное, я нашел несколько расшифровывающих его определений.

И эти определения наиболее подходящие для нашего блога (объясняющие сложное простым, человеческим языком). Они же несут в себе основные принципы scrum. Итак:

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

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

Scrum же это именно методология (тоже придуманная программистами, только 2-мя).

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

Почему везде одни программисты? Потому что изначально agile и scrum были придуманы при создании IT-решений (разработка программ). Ведь там процессы сложные и очень долгосрочные, просто так, через “устные приказы” всё не реализовать, и система не будет работать, как часы.

Именно поэтому и сама философия, и прочие методологии (помимо Scrum, есть еще XP или каскадно-водопадные) были заложены именно ими.

Управление проектами в строительстве

Само слово “scrum” было взято из регби. Это когда спортсмены разыгрывают мяч, уперевшись головами друг в друга, направив взгляд вниз. Командная игра, где важен каждый.

Регби

Составляющие скрам

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

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

1. Спринт

Спринт (у программистов это называется итерация) — это срок, в течении которого команда работает над проектом.

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

К примеру, в компании Nokia срок спринтов ставился 6 месяцев. У Apple срок спринта редко превышает 3 недели. Может именно в этом успех этой компании.

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

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

В течении каждого “забега” проводятся ежедневные совещания (дневные спринты), на которых каждый член команды должен ответить на следующие вопросы:

1. Что было сделано вчера?
2. Что я должен сделать сегодня?
3. Какие у меня были препятствия в работе надо проектом и как их устранить?

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

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

1. Что мы можем сделать лучше в следующий раз/в следующем “забеге”?
2. Какие были проблемы в этом спринте?

Именно ответы на эти вопросы сильно помогают улучшить эффективность работы над проектом в последующем.

Так как деятельность бизнеса не подразумевает выполнение одноразовых задач по Scrum. Обычно это повторяющиеся процессы, хотя бы близко. Но если Вы хотите делать всё по скраму, даже одноразовые задачи, то спринт-митинг Вам скорее всего уже не нужен.

2. Команда

Команда, работающая над частью проекта, состоит из семи участников (плюс-минус два человека) разноплановой направленности.

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

Количество связано прежде всего с тем, что для работы с большим числом участников требуются большие временные ресурсы. А меньшее количество несет опасность того, что команда (за счет меньшего количества умений) не сможет справится со своей частью проекта за спринт.

Кроме основного плюса, который можно назвать “коллективный разум”, подобная команда обладает дополнительными плюсами и их легко выделить:

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

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

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

Екатерина

Сергей

Иван

Елена

Екатерина

3. Роли

А теперь самое необычное, что есть в методологии скрам, что ее отличает от многих. Это роли.

Так как в scrum нет руководителей и явных лидеров (это собственно главный принцип agile-методологии), то кто-то должен модерировать работу команды и работу над проектом в целом. И для этого в методе скрам бывают следующие роли:

• Владелец продукта;
• Скрам-мастер;
• Команда-разработки.

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

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

3.1 Владелец продукта. Важно, это не заказчик. Это человек из команды, который берет на себя его роль. Его ключевые задачи в проекте:

1. Видение со стороны конечного пользователя итогового продукта;
2. Решения о любых изменениях в проекте;
3. Связь команды и заказчика.

3.2 Скрам-мастер. Как и в любом проекте, в скрам есть люди, которые руководят всем проектом. В нашем подходе это скрам-мастер. Его главные задачи в проекте:

1. Контролирование хода всего проекта;
2. Организация спринтов и совещаний;
3. Выявление затыков и их устранение;
4. Доработка продукта до идеального состояния.

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

Плюсы и минусы скрам

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

И скрам не исключение. Есть преимущества scrum перед, например, каскадно-водопадной методологией управления проектами, но есть и свои недостатки.

Разберем их, чтобы уже точно понимать, стоит ли Вам переходить на такой вид управления проектами (и не побоюсь этой фразы, Вашими сотрудниками). Или же оставить это большим компаниям, а Вам поискать что-то попроще, например, Канбан.

Преимущества

1. Отсутствие бюрократии и довольные сотрудники

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

Они ставят на вершину пирамиды бизнес-процессов бумажки и документацию. Но что, если поставить на вершину сотрудников?

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

2. Готовый идеальный продукт

Помните старый советский анекдот про “тебе шашечки или ехать?”. Если для Вас важнее получить идеальный продукт, чем документацию по его использованию, то это скрам.

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

Открою Вам секрет, но у первого iPhone, на момент его презентации Стивом Джобсом в 2007 году, не было полной инструкции и готовой технической документации. Зато был телефон, который перевернул мир. А технические инструкции доделывали уже потом в диком темпе. Но об этом никому, я обещал молчать 😉

3. Получение обратной связи и продукта, который купят (вытекает из преимущества “готовый идеальный продукт”).

Я даже не представляю, какое должно быть разочарование в душе у клиента, который через 3 года создания проекта не смог стать успешным (хотя бы окупиться). А все потому, что было слепое следование планам, без получения обратной связи в ходе действий.

То есть планы просто не меняли всё это время, потому что была цель создать продукт, который все видели в начале пути, без поправок в процессе.

4. Внутренняя обстановка

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

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

Естественно, их работоспособность и вовлеченность в общий процесс / создание продукта / развитие компании (то, о чем мечтают все собственники) будет в разы выше, чем при стандартном подходе с руководителями и классической организационной структурой.

5. Экономия

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

Ведь всё, что Вам нужно, это понимание, как всё устроено и как это реализовать именно у Вас. Дорогостоящее программное обеспечение для этого не обязательно, хотя и желательно.

Недостатки

Звучит это все, конечно, круто и наверное даже фантастически. Столько плюсов! Вы поставили проект и в дальнейшем команда сама работает при минимальном контроле. Но не все так хорошо. Методология скрам имеет и свои минусы.

1. Команда

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

Они должны не только сочетаться между собой как профессионалы, но и как обычные люди. Если нет руководителя, то это не говорит о том, что команда будет работать на 146% своего КПД.

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

2. Планирование

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

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

3. Время

Помните, что в спринтах постоянно проводятся спичи (мини-планерки)? А теперь посчитайте, сколько это времени занимает в целом проекте.

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

4. Жесткость

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

Всё это реализует команды, которыми руководит скрам-мастер. Иначе никак! Нет отдельных игроков, нет нарушения структуры, нет увеличения длительности спринтов в середине процесса. Всё жёстко и по плану.

Коротко о главном для малого бизнеса

Первое мнение, которое у меня сложилось: метод скрам — это только для IT-компаний. Частично это верно.

Но сколько таких компаний в числе наших читателей? Наверное 0,001%. Поэтому подведём итог, основываясь на малом бизнесе, а именно на рознице, услугах, опте и производстве.

В каких из вышеперечисленных бизнесов есть сложные и длительные проекты, для которых требуется команда из 7 человек? Скорее всего Вы скажите, что в НИ-КА-КИХ. В этом и весь смысл. Скрам подходит только в тех случаях, когда Вы создаёте что-то неопределённое, что сами до конца не понимаете. А значит и планировать дальше 2-3 месяцев не можете.

В малом бизнесе нужно использовать обычный каскадный подход (последовательный переход от одного этапа к другому).

Единственное, когда можно рассмотреть Scrum в классическом бизнесе, это когда требуется создать новый продукт, вот тогда в этом есть смысл. А во всём остальном оставьте эту идею для IT-сфер, старт-апов и очень-очень-очень сложных проектов.

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

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

Источник: in-scale.ru

1. Основы организации строительства и управления проектом

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

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

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

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

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

Согласно первому подходу: за основу планирования принимаются мощности строительных организаций, а под эти мощности планируется выпуск готовой строительной продукции. Этот подход в большей степени освещается в курсах «Организация строительства» и «Организация строительного производства». Для данного подхода основным субъектом управления является подрядчик.

Согласно второму подходу: за основу планирования принимаются объекты, под которые планируется привлечение необходимых мощностей строительных организаций. В дисциплине «Управление инвестиционным строительным проектом» за основу планирования принимается строительный объект, а основным субъектом управления проектом является заказчик-застройщик.

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

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

В состав проекта (англ. project) входят отдельные организационно-конструкторские разработки (англ. design), в частности технический проект, рабочая документация, проект организации строительства, проект производства работ и т.д. Началом проекта считается начало вложения денежных средств (капиталов, инвестиций), а окончанием  достижение поставленной перед проектом цели. Промежуток времени между началом и окончанием проекта называют жизненным циклом проекта.

Представление инвестиционного строительного проекта в виде денежного потока. Обычно жизненный цикл инвестиционного строительного проекта (см. рис.1) представляют в виде распределенной во времени суммы (сальдо или итог), которая состоит из притока денежных средств R и их оттока С. За начало инвестиционной деятельности принимают дату первого вложения средств в проект (нулевой момент времени), текущее время обычно определяют в годах (или в соответствующих долях года) и обозначают через t, а продолжительность всего жизненного цикла обозначают через Т.

Рис. 1 Динамика денежных средств инвестиционного строительного проекта

Инвестиционные затраты связаны с вложением денежных или иных ценностей в создание основных средств (машины, здания, сооружения, земля и т.п.). Для принятия проекта к реализации заказчику-инвестору, как основному субъекту управления, требуется обосновать инвестиционные затраты.

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

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

Этапы реализации жизненного цикла инвестиционного проекта. Обычно выделяют 5 этапов реализации жизненного цикла инвестиционного строительного проекта:

концептуальный (предпроектный) этап, в который входит разработка технико-экономического обоснования проекта (бизнес-плана проекта) и задания на проектирование;

проектный этап, в который входит комплекс проектно-изыскательских работ, которые материализуются в создании проектно-сметной документации проекта;

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

этап эксплуатации объекта;

этап ликвидации объекта.

Следует отметить некоторую условность моментов начала и окончания проекта. Так, например, до момента начала вложения в проект основных инвестиций производятся затраты, связанные с его технико-экономическим обоснованием. Окончание проекта не всегда зависит от его “физического” жизненного цикла, так как построенный или даже недостроенный объект может быть продан другому собственнику.

Проект, связанный с реализацией полного цикла капитальных вложений от начального вложения до завершения работ, называется инвестиционным проектом, а при вхождении в его состав строительной части соответственно  инвестиционным строительным проектом (ИСП).

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

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

Основными субъектами управления ИСП являются следующие:

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

Заказчик — его основной функцией является организация реализации проекта в целом в интересах застройщика;

Инвестор – его основной функцией является финансирование проекта с целью получения определенного процента на инвестируемый капитал;

Проектировщик — его основной функцией является выполнение проектно-изыскательских работ;

Подрядчик  его основная функция  это «физическое» осуществление строительства объектов;

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

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

Базовые принципы в организации строительства и управлении проектами. Управление в целом и управление проектом в частности базируется на учете основных (базовых) принципов.

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

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

Иерархичность субъектов и объектов управления ИСП подразумевает их соподчиненность. Для создания целостной системы между органами управления необходимо установить связи (административные, функциональные, информационные и др.).

Нормативность в управлении ИСП. При создании и реализации проекта требуется обязательное соблюдение технических и правовых норм (например ГОСТ, СНиП, кодексы и др.)

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

Виды сложности строительных объектов. Строительные объекты различаются по сложности в соответствии со следующими классификационными признаками:

сложностью архитектурно-планировочных решений;

сложностью промышленной технологии строящегося объекта;

сложностью применяемой строительной технологии;

Классификация проектов. По виду осваиваемых инвестиций различают следующие проекты:

фондообразующие проекты направлены на создание и реновацию основных фондов;

инновационные проекты направлены на создание новой техники, технологии и изделий;

Источник: studfile.net

Управление строительными проектами

В современном строительном бизнесе все более активно используются информационные технологии и специализированное программное обеспечение. Это САПР и ГИС, системы управления проектной документацией и сметное ПО. Сметные системы дают оценку проекта (под проектом мы будем понимать объект инвестиций) с точки зрения объемов работ, стоимости, общей потребности в ресурсах по проекту, но не предоставляют таких важных для успешного выполнения проекта сведений, как календарный план работ, график потребности в ресурсах, календарный профиль затрат.

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

Среди требований строительных компаний с подобного рода программным комплексам практически всегда фигурируют следующие пункты:

· Разработка календарных графиков производства работ с поддержкой различных уровней иерархий;

· Построение графика потребностей в ресурсах, графика расходования денежных средств на проект в целом и на отдельный вид работ, ресурсов – планирование ресурсного обеспечения;

· Возможность планирования широкого спектра ресурсов: как исполнителей и механизмов (возобновляемых ресурсов), так и материалов (расходуемых ресурсов);

· Проигрывание различных вариантов планирования – при жестких временных ограничениях и при ограниченных ресурсах. Варьирование этих способов поможет найти наиболее удачный компромисс: «быстрее – дешевле»;

· Нахождение наиболее «экономного» варианта реализации проекта за счет оптимизации стоимостных характеристик проекта при проведении проекта в различные сроки, привлечении других ресурсов;

· Анализ распределения затрат на элементы объекта, на строительные работы различных типов в соответствии со структурой статей затрат;

· Интеграция в корпоративные информационные системы (КИС), возможность импорта-экспорта данных в программы составления строительных смет, складские, бухгалтерские программы.

Для решения подобных задач используется специальный класс программного обеспечения – системы календарного планирования и контроля реализации проектов или по-другому системы управления проектами (СУП) — далее мы будем использовать этот термин.

Итак, эти системы обеспечивают поддержку основных процессов временного, ресурсного и стоимостного планирования и контроля на основе алгоритмов сетевого планирования, метода критического пути (некоторые даже ресурсно-критического), метода освоенного объема и т.п.

Строительные проекты лежали у истоков сетевого планирования. Собственно метод критического пути был разработан для координации работ по строительству заводов химического концерна «Дюпон». В настоящее время всё большее количество строительных компаний в России начинает применять системы календарного планирования для повышения эффективности своей работы.

Использование систем управления проектами в строительной отрасли на разных этапах инвестиционного процесса

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

· укрупненная оценка временных и стоимостных параметров проекта;

· оценка его реализуемости и эффективности;

· разработка ориентировочной концепции строительства объекта инвестирования;

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

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

Стадия тендерных торгов

На этой стадии использование систем управления проектами позволяет подрядным организациям решать следующие задачи:

· Разработка укрупненного пилотного графика производства работ;

· Разработка предварительного графика финансирования;

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

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

В случае, если заказчик (управляющая компания, etc) тоже использует СУП, получив расписание проекта в электронном виде, может достаточно быстро и корректно оценить реальность представленного графика производства работ.

Стадия реализации проекта

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

Стадия исполнения проекта делится на два этапа:

1. Этап разработки проекта управления строительством (ПУС)

2. Этап его утверждения и контроля исполнения

· Подход к составлению расписаний;

· Выбор уровня детализации;

· Выбор модели управления;

Эта стадия, как правило, разбивается на два зависимых друг от друга процесса:

Процесс разработки проекта управлением строительством (ПУС) (планирование)

Процесс контроля исполнения и управления проектом

Рассмотрим задачи, относящиеся к процессу разработки проекта управлением строительства:

· Определение состава работ проекта (по аналогам, сметам и пр.);

· Разработка структур кодов (WBS, ID, топологические схемы), типов и т.д.;

· Разработка структуры статей затрат, календарей работ и календарей ресурсов;

· Разработка расписаний, технологических последовательностей, учет внешних факторов. Влияющих на последовательность и сроки выполнения работ (пример: паводок, мороз);

· Назначение длительностей, ресурсов, их производительностей и стоимостей;

· Оптимизация расписаний (включая использование технологии «fast-track»);

· Расчет и оптимизация плановых сроков реализации проекта с учетом существующих ограничений на ресурсы. В СУП менеджер может легко проиграть различные варианты реализации проекта — при жестких временных или ресурсных ограничениях. Во все СУП заложены математические алгоритмы оптимизации использования различных типов ресурсов, с помощью которых значительно упрощается решение задач;

· Построение графиков потребности проекта в трудовых ресурсах, машинах и механизмах, оптимизации загрузки имеющихся производственных мощностей;

· Определение потребностей проекта в материалах, формирования графика поставок и закупок материалов;

· Определение необходимых затрат на реализацию проекта и его отдельных фаз, а также распределения финансовых потребностей проекта во времени, на элементы объекта, на строительные работы различных типов;

· Оценка рисков (сроки, возможности финансирования, политические риски и т.д.);

· Определение круга лиц, ответственных за внесение и обновление информации о выполнении проекта;

· Разработка инструкций для различных рабочих мест, интерфейсов и пр. к базе данных проекта (в худшем случае – к файлам проекта)

· Согласования и корректировка проектных данных.

· Согласование и Утверждение ПУС всеми участниками инвестиционного процесса — получение и «закрепление» так называемого целевого плана».

Исходные данные для решения поставленных задач: Проектно-сметная и проектно-конструкторская документация (ПСД И ПКД), технологические карты строительно-монтажных работ, готовые типовые фрагменты расписаний, документация по аналогичным реализованным проектам, Проекты производства работ (ППР), технические и технологические требования заказчика, директивные сроки, Условия заключенных контрактов, ограничения по имеющимся ресурсам и пр.

Проблемы адаптации западных пакетов

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

Строительная отрасль имеет свои давние традиции. Мерой работы (операции) традиционно является её физический объем, а не продолжительность. Поэтому можно утверждать, что без понятия «физобъем» серьезно говорить о создании модели строительного проекта в системах управления проектами — несерьезно.

Во всех, известных авторам западных пакетах для управления проектами, распространенных на российском рынке отсутствует понятие физобъем. Работа измеряется длительностью. Нет его в TimeLine, P3, OpenPlan, SureTrak, MS Project. Поэтому при внедрении и использовании СУПов приходится заниматься решением этой проблемы. Представляется, что существует как минимум два способа решения.

Первый способ — использовать программный комплекс, «знающий» что такое «физобъем» и умеющий с этим понятием работать. Примером такого пакета может служить Spider Project, российской компании «Технологии управления Spider».

Если же требуется адаптировать западную систему, то проблему можно решить с помощью добавления в стандартную модель проекта пользовательских полей для хранения данных об объемах работ или изменения структуры баз данных системы. Предпочтительно использовать второй способ. Затем, с помощью встроенных в СУПы макроязыков, пользовательские поля любыми необходимыми алгоритмами связываются со стандартными полями систем. В некоторых случаях это позволяет решить проблему.

Плюсы и минусы при использовании СУП на этапе планирования:

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

* Всё зависит от интерфейса системы, но, как правило, с помощью СУП очень удобно составлять расписания, кстати, именно для этого их и писали;

* Работа всех участников проекта с единой моделью проекта и с едиными данными;

* Возможность хранить сколь угодно много вариантов проекта;

* Оперативное обновление измененной информации у всех участников проекта;

* Немаловажным фактором является легкость и удобство получения различной отчетной и аналитической информации по проекту в графическом, табличном виде, диаграмм Ганта, сетевых графиков и т.д

* Необходимость обучения большого количества людей использованию СУП на достаточно высоком уровне;

* В связи с большим количеством лиц, имеющих доступ к данным – достаточно сложное и напряженное администрирование системы;

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

Хотелось бы так же затронуть методы разработки расписаний. На наш взгляд, их может быть как минимум два:

1. Метод «от смет» — при этом расписание формируется из сметы. Позиции сметы экспортируются в СУП (конечно же, включая кроме наименования и все другие данные – объемы, ресурсы, стоимостные характеристики и т.д.), затем в СУП накладываются технологические связи, ограничения по срокам, ресурсам; накладываются соответствующие кодировки (топология, WBS и т. п.). После расчета расписания получается проект. Такой проект может быть весьма подробным, но при этом не совсем удобным при отслеживании прогресса.

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

Достаточно сложно говорить о том, какой метод наиболее оптимальный. На рынке есть готовые решения для использования первого метода (примеры: «А-ноль» и «Примавера», «WinАВеРС» и MS Project/ Open Plan). В зависимости от традиций, каждая строительная организация может выбрать любой метод. Причем нет никаких особых проблем при комбинировании этих методов. Нам известны разные случаи.

Например, одно из подразделений МВКС («Луч») использует практически в чистом виде первый метод (информация компании «Технологии управления Спайдер»). Если речь идет о желании получать процентовки после внесении сведений о прогрессе, то речь наверняка пойдет о первом методе. Если же мы говорим о том, что важно отслеживать проект – вероятнее всего оптимальней использовать второй метод. Хочется отметить, что эта тема активно обсуждалась на семинаре «Управление проектами» московского отделения PMI (http://www.pmi.ru).

Рассмотрим основные задачи, относящиеся к процессу контроля исполнения и управления проектом

* Своевременный сбор фактических данных о ходе реализации проекта;

* Оперативная авторизованная корректировка проектных данных;

* Оценка способов и методов сбора фактических данных, при необходимости их корректировка;

* Анализ состояния проекта по срезам (сроки, освоенный объем, работа ресурсов, оценка рисков)

Достоинства использования СУП на этапе реализации проекта

СУП позволяют хранить в своей модели проекта плановые показатели по проекту (сроки, стоимости, объемы и т.д.) и вводить фактические данные по ходу реализации проекта. Конечно же, исходный календарный план «плывет».

Но система позволяет увидеть эти отклонения, оценить их последствия на проект в целом, проиграть и выбрать оптимальный вариант реакции на изменения, при необходимости перепланировать оставшуюся часть проекта с учетом новых реалий, оперативно внести изменения в документацию по проекту. Именно на этом этапе система проявляет свои лучшие качества — модель проекта «живет» вместе с реальным проектом. Менеджер проекта получает в свои руки инструмент не только контроля за свершившимися событиями, но и возможность прогнозирования предстоящих. В то же время, удобные, простые средства генерации отчетности по проекту позволяют легко довести необходимую информацию по проекту до всех заинтересованных лиц в требуемой форме. Кроме того, использование современных Internet-технологий позволяет получить доступ к проектным данным с любой точки земного шара.

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

Стадия завершения проекта

Стадия завершения проекта часто является наиболее напряженной, как с точки зрения сроков исполнения проекта, так и с финансовой стороны. И в этих случаях, позволим себе повториться, наибольшая польза от использования системы управления проектами – возможность проведения оперативного анализа «ЧТО… ЕСЛИ…».

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

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

Интеграция СУП с другими компонентами корпоративных информационных систем

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

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

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

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

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

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

Тем не менее, реализация интеграции сметных программ с СУП привлекает некоторые строительные компании, занимающиеся внедрением у себя систем календарного планирования. О чем уже упоминалось выше.

В настоящее время редкие программные продукты не интегрируются с веб-технологиями, разве что консервативные – бухгалтерские. Вот и СУП – тоже не отстают. На самом деле, весьма привлекательные возможности и перспективы при этом возникают.

Ну, во-первых, для просмотра отчетов о выполнении, финансах и прочих данных не обязательно инсталлировать на каждую машину дорогие клиентские места СУП. Вполне достаточно броузера (средство просмотра гипертекстовой страницы). Причем, мы знаем, что большинство из них вообще бесплатны. Во вторых, даже для изменения информации в базах данных СУП бывает достаточно «тонкого» клиента. Подобные решения уже входят в стандартные поставки наиболее мощных и современных систем.

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

Источник: www.md-management.ru