Что такое критический путь в сетевом графике строительства

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

Работа (i,j)	Количество предшествующих работ	Продолжительность tij	Ранние сроки: начало tij Р.Н.	Ранние сроки: окончание tij Р.О.	Поздние сроки: начало tij П.Н.	Поздние сроки:окончание tij П.О.	Резервы времени: полный tij П	Резервы времени: свободный tij С.В.	Резервы времени: событий Rj
(1,2)	0	3	0	3	1	4	1	0	1
(1,3)	0	6	0	6	0	6	0	0	0
(1,4)	0	4	0	4	9	13	9	9	0
(2,3)	1	2	3	5	4	6	1	1	0
(2,5)	1	5	3	8	12	17	9	2	7
(3,4)	2	7	6	13	6	13	0	0	0
(3,5)	2	4	6	10	13	17	7	0	7
(3,6)	2	4	6	10	15	19	9	9	0
(4,6)	2	6	13	19	13	19	0	0	0
(5,6)	2	2	10	12	17	19	7	7	0

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

Методы сетевого планирования-2.

Скачать

Источник: math.semestr.ru

Правила построения сетевых графиков

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

Расчет (построение) сетевого графика

> ПРИМЕР 2.1. Для начала работы D достаточно окончания работы А. Для начала же работы С нужно окончание работ А и В (рис. 2.2).

Метод критического пути

Метод критического пути (Critical Path Method — СРМ) используется для управления проектами с фиксированным временем выполнения работ. Он позволяет ответить на следующие вопросы:

• 1. Сколько времени потребуется на выполнение всего проекта?
• 2. В какое время должны начинаться и заканчиваться отдельные работы?
• 3. Какие работы являются критическими и должны быть выполнены в точно определенное графиком время, чтобы не сорвать установленные сроки выполнения проекта в целом?
• 4. На какое время можно отложить выполнение некритических работ, чтобы они не повлияли на сроки выполнения проекта?

ОПРЕДЕЛЕНИЕ. Самый продолжительный путь сетевого графика от исходного события к завершающему называется критическим. Все события и работы критического пути также называются критическими.

Продолжительность критического пути и определяет срок выполнения проекта. Критических путей на сетевом графике может быть несколько.

Рассмотрим основные временные параметры сетевых графиков.

Обозначим t(i, j) — продолжительность работы с начальным событием / и конечным событием j.

Ранний срок tp(j) свершения события j — это самый ранний момент, к которому завершаются все работы, предшествующие этому событию. Правило вычисления:

где максимум берется по всем событиям i, непосредственно предшествующим событию j (соединены стрелками).

Поздний срок:

где минимум берется по всем событиям у, непосредственно следующим за событием /.

Резерв R(i) события i показывает, на какой предельно допустимый срок может задержаться свершение события i без нарушения срока наступления завершающего события:

Критические события резервов не имеют.

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

> ПРИМЕР 2.2. Рассмотрим сеть проекта, представленную следующими данными (табл. 2.1). Необходимо найти критический путь. Сколько времени потребуется для завершения проекта? Можно ли отложить выполнение работы D без отсрочки завершения проекта в целом?

На сколько недель можно отложить выполнение работы С без отсрочки завершения проекта в целом?

Источник: studref.com

Что такое критический путь проекта, и зачем он нужен

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

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

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

Как построить критический путь проекта

Определить критический путь проекта очень просто:

1. Составить список всех работ в проекте и их длительности (тут, как вы помните, пригодится WBS). В моем любимом примере с ремонтом в списке работ будет: снос межкомнатных старых стен, возведение новых, штукатурка, поклейка обоев, устройство электрики, разводка воды, укладка ламината и т.д. На этом этапе наша цель – получить исчерпывающий список работ и понимание того, сколько займет каждая из них – на штукатурку нам надо 3 дня, на электрику – 10, на ламинат – 4 и так далее.
2. Определить, как работы связаны друг с другом. Ну, например, какое условие начала работ по электрике? Наверное, как минимум, возведенные стены? Стены есть – можно начинать. А условий поклейки обоев уже больше – к этому можно будет приступить в самом конце, когда и ламинат уже уложен, и электрика смонтирована, и, конечно, стены оштукатурены и прошпаклеваны. К слову, есть разные типы связей (одна работа может начаться только после окончания другой, только одновременно с другой и т.д.), но на этом этапе не будем усложнять. Выписать это можно в Excel или в MS Project, пронумеровав работы и проставив рядом с каждой их них номера тех работ, завершение которых необходимо для ее старта.
3. Дальше методология говорит нам, что нужно разработать сетевой график – от руки на листочке в кружочках написать номера работ, соединить их стрелочками в зависимости от того, какая работа за какой идет, и на входящих в работу стрелочках написать длительность этой работы. Ну или не от руки, а в любом программном обеспечении (не закрывайте пост, это для понимания, в жизни никто в здравом уме это вручную не делает, конечно!). Выглядит готовый сетевой график примерно так (картинки, как всегда из яндекса):

Теперь мы можем подсчитать, какая цепочка самая длинная и выделить это цветом. На графике ниже это работы 1-4-5.

Ну все, поздравляю, вы определили критический путь проекта. Теперь вы знаете, что срок проекта зависит от задач 1, 4 и 5, “поедут” они – “поедет” весь проект. Значит, им все внимание.

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

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

Более того, в 90% случаев даже опытный руководитель проекта посмотрит на сетевой график, автоматически построенный в MS Project, и спросит “что это за хрень?”, так как отраслевым стандартом представления критического пути давно стала диаграмма Ганта.

Вот так выглядит сетевой график в MS Project. Не очень, правда?

Ниже будут примеры того, как построенный критический путь выглядит в MS Project в форме диаграммы Ганта. Если доступа к MS Project у вас нет – то же самое умеют многие бесплатные и платные планировщики проекта, подробнее можно посмотреть в посте про диаграмму Ганта.

Примеры критического пути

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

Красным цветом MS Project автоматически подсвечивает задачи на критическом пути, если открыть нужное представление, это очень удобно.

Пример 1:

Пример 2:

Пример 3:

Ну классно же, сразу понятно, на чем концентрировать усилия!

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

Использование критического пути на практике

Как обычно – несколько мыслей из практики о типовых ошибках при использовании критического пути в проектах:

1. Не стоит забывать про вторичный критический путь. Я выше написала, что руководитель проекта должен в первую очередь концентрироваться на задачах критического пути, так говорит нам любая методология управления проектами. Практика с этим не спорит, конечно, но дополнительно считает, что обязательно надо работать с задачами, которые при планировании проекта вроде бы лежат вне критического пути, но могут оказаться на нем при относительно небольшой задержке их выполнения. Возвращаемся к ремонту – например, на критическом пути у нас разводка труб в санузле -> укладка плитки -> установка ванны и унитаза. Вне критического пути лежит задача “закупка плитки” и вроде бы ремонт только начался, времени еще полно, плитку же можно купить впритык к моменту ее укладки (если строго следовать методологии). Но хороший прораб (и хороший руководитель проекта) при оценке рисков сразу видят, что если что-то пойдет не так и закупка или доставка задержится – все сроки ремонта санузла сдвинутся. Поэтому стоит начать закупку пораньше, чтобы эта задача не превратилась в задачу на критическом пути. Это пример именно про конкретную задачу, но при оценке может оказаться, что у вас формируется несколько практически независимых цепочек (например, на общий срок ремонта всей квартиры влияет как срок ремонта в санузле, так и срок разводки электрики). На форумах или в чатах можно встретить неофициальные термины “вторичный критический путь”, речь как раз об этом.
2. Не стоит высчитывать критический путь вплоть до дня. Этот пункт связан с пунктом выше, бывает, что при определении критического пути разница между несколькими его вариантами составляет буквально несколько дней, и за критический путь принимается цепочка, которая буквально на день-два (или неделю-две) больше альтернативной (опять же, в строгом соответствии с методологией). Но проект – живой организм, “точно как запланировано” все проходит очень-очень редко, поэтому при небольшой разнице лучше сразу честно признать, что обе цепочки – это и есть ваш критический путь, и уделять им обеим повышенное внимание. Иначе с вероятностью, близкой с 100%, эта бомба рванет в самый неподходящий момент.
3. Не стоит думать, что критический путь интересен только руководителю проекта. В любой более-менее опытной проектной команде все исполнители знают, что такое критический путь, и что когда руководитель проекта говорит “эта задача на критическом пути” – это значит, что у нее приоритет номер один. Если вы не уверены, что ваша команда это знает – потратьте 5 минут, расскажите о концепции критического пути, покажите, как выглядит критический путь именно в вашем проекте, какие задачи туда попали, и чего вы ждете от тех, кто будет их выполнять. Честное слово, оно того стоит, ну и людям будет приятно узнать что-то новое.
4. Не стоит считать, что критический путь “вырублен в камне”. В мире с правильной методологией вы, конечно, должны были максимально оптимизировать критический путь еще до старта проекта, но если с вас никто не требовал уменьшить спланированные сроки, то, скорее всего, вы же не напрягались, правда? Часто можно видеть, что и сам руководитель проекта стрессует и команду доводит, если на критическом пути что-то идет не так, но почему-то не делает никаких попыток этот самый критический путь как-то сократить, чтобы “вытащить” ранее согласованные сроки. Почти всегда при желании возможность для оптимизации найти можно, если глаз уже замылен – посоветуйтесь с соседом-РМом, руководителем, командой, решение точно найдется.
5. Не стоит оставлять в проекте “плавающие задачи”. В любом проекте есть задачи, вроде бы сильно не связанные с другими, и чаще всего они остаются просто в списке задач, жестко не привязанные к другим (это, кстати, тот случай, когда методология на 100% права, когда говорит, что ВСЕ задачи должны иметь вход и выход, просто ей в этом вопросе большинство не следует). В итоге про них забывают и в конце проекта они стреляют как то ружье, которое стояло в углу. Например, в ремонте такой задачей может быть “опломбировать счетчики”. Ну а что, сделать можно в любой момент проекта, точно не на критическом пути, до конца ремонта точно дойдем. Но при метаниях между выбором плитки и заливкой пола все как-то не до этого, и вроде бы ремонт уже закончен, а мы счетчики так и не опломбировали, кучу денег за это время потратили зря, оплачивая воду по нормативам, да еще и оказалось, что в управляющей компании очередь на опломбировку на 3 месяца. В итоге проект закрыть не можем, деньги в прямом смысле слова “капают”, в голове нужно все это продолжать держать и т.д. А всего лишь надо следовать простому правилу – любая задача должна быть связана с другими. Это прямо в камне проектного управления надо высечь.

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

Используете метод критического пути в своих проектах? Расскажите в комментариях здесь или в телеграме!

Источник: upravlenie-proektami.ru