Глава 7. Создание сводного плана нескольких проектов методом критической цепи

Глава 7. Создание сводного плана нескольких проектов методом критической цепи

7.1. Как определить ограничение системы проектов

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

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

То же самое происходит, когда в компании запускается слишком много проектов без учета возможностей имеющегося ограничения. Если в систему «подать» чересчур большое количество проектов, они в ней застрянут, система заглохнет. Люди будут трудиться изо всех сил, однако проекты станут идти все медленней (ведь двигатель регулярно глохнет), а усилия руководства — уходить на то, чтобы перезапустить двигатель и прочистить заторы. Складывается впечатление, что ключевых ресурсов, необходимых для завершения проектов, всегда будет не хватать.

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

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

Если предположить, что проекты на рис. 7.1 одинаковые, ресурсы придется распределять между всеми тремя проектами, даже если у вас всего по одному ресурсу каждого типа. То есть либо при планировании сразу предусматривается необходимость единовременного выполнения одним ресурсом нескольких заданий по разным проектам (учитывается частичная, а не 100%-ная занятость исполнителей по каждому из проектов), либо же из-за многозадачности проекты никогда не завершатся вовремя. Если проекты равнозначные, то сразу видно, когда один из исполнителей более загружен, чем остальные. Этот ресурс — ограничение по мощности системы. Таким образом, скорость выполнения проектов в компании определяется скоростью работы самого загруженного исполнителя-ограничения.

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

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

ограничение компании действует как «барабан». Этот термин взят у Гол-дратта — из методики налаживания производственных систем. Барабан определяет ритм всего производственного процесса. В нашем случае — проектов компании. Вспомните барабанщиков, задающих ритм гребцам на старинных кораблях. Что будет, если хотя бы один из гребцов собьется с такта?

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

На рис. 7.2 показаны результаты работы метода ССРМ. В отличие от приведенного ранее плана критических путей, при использовании критической цепи длительность каждой операции сократилась до 15 дней. Снизилась степень «многозадачности» (необходимость распределять усилия исполнителей между тремя задачами трех проектов одновременно), при этом в план заложена оценка длительностей операций с вероятностью своевременного выполнения 50%. По результатам планирования методом ССРМ ресурсом, ограничивающим мощность системы, является исполнитель операций 2 и 3. Метод позволяет снизить влияние этого ограничения, синхронизировав проекты и используя ограничение как «барабан». Правило подчинения работ ритмам ограничения реализуется путем добавления между проектами буферов на доступность ресурса (БДР). Буферы на доступность обеспечивают своевременное наличие ресурса, ограничивающего мощность системы, на работах следующего проекта.

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

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

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

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

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

7.2. Как снизить влияние ограничения системы проектов

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

1. Найдите ресурс-ограничение компании.

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

2. Снизьте влияние ресурса-ограничения, максимально использовав его возможности.

2.1. Для каждого проекта в отдельности составьте график методом критической цепи.

2.2. Определите приоритетность проектов в борьбе за ресурс-ограничение.

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

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

3.1. Начало каждого проекта определите с учетом графика вовлеченности ресурса-ограничения.

3.2. Обозначьте критическую цепь — от первой операции, требующей участия ресурса-ограничения, и до конца проекта.

3.3. Добавьте буферы на доступность — между графиками проектов перед тем графиком, в котором задействован ресурс-ограничение. Этот механизм защитит график «барабана», обеспечив своевременное наличие всех исходных материалов.

3.4. Если при добавлении буферов на доступность возникают накладки в графике ресурса-ограничения, устраните их.

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

4. Устраните ограничение — увеличьте мощность ограничивающего ресурса.

5. Вернитесь к шагу 1, не позволяя инерционности мышления становиться ограничением.

Далее мы рассмотрим некоторые составляющие этого процесса.

7.3. Важные аспекты управления несколькими проектами методом критической цепи

7.3.1. РАССТАНОВКА ПРИОРИТЕТОВ

Прежде чем браться за создание графика «барабана», необходимо определить приоритетность всех одновременно идущих проектов. Это нужно для того, чтобы ресурс-ограничение использовался в соответствии с важностью проектных задач. Расстановка приоритетов может осуществляться по разным принципам, однако первый в этом ряду — взятый из ТОС принцип увеличения производительности Т компании посредством управления ограничением. Если вы способны напрямую измерять этот показатель, можно использовать его для выявления степени важности проектов. Для этого производительность Т проекта (как правило, в долларах) делим на время участия в проекте ресурса-ограничения (обычно в человеко-часах или человеко-днях).

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

7.3.2. ОПРЕДЕЛЕНИЕ РЕСУРСА-«БАРАБАНА»

Ресурс-«барабан» задействован во всех проектах, которые мы рассматриваем как части одной системы. В крупных компаниях может существовать несколько групп проектов, при этом одни и те же ресурсы задействованы внутри группы, но не между группами. В этом случае и ресурсов-«бараба-нов» будет несколько.

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

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

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

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

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

Назначая исполнителей, не указывайте конкретные имена. Во многих компаниях фиксируется имя человека, назначенного на решение задачи. Считается, что иначе и нельзя, ведь у каждого специалиста в компании имеется совершенно уникальный набор знаний и навыков. Если это так и есть, то по-другому действительно нельзя. Но должен предупредить, вы очень рискуете, ставя производительность Т системы ваших проектов в зависимость от конкретных людей. А что если они уйдут в отпуск или заболеют? Вся работа встанет. Эту ситуацию необходимо учесть, когда будете оценивать риски проектов.

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

7.3.3. ГРАФИК «БАРАБАНА»,

ИЛИ НАЛАДКА КОНВЕЙЕРА ПРОЕКТОВ

График «барабана» — это план привлечения ресурса-ограничения к работам по всем проектам, где он нужен. Ведет график обычно тот, кто отвечает за ресурс-ограничение. Ресурс-«барабан» — первоочередной фактор, который определяет возможность системы выполнять проекты.

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

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

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

Идея в том, чтобы менее важные проекты откладывать на поздние сроки, когда для них будет отведено свободное окно ресурса-«барабана». Из этого и складывается график «барабана». Обратите внимание, что при составлении этого графика вы взяли из планов отдельных проектов среднеоценочную длительность операций. Поскольку нам хотелось бы быть максимально уверенными в том, что «барабан» будет доступен в нужный момент, необходимо заложить в график запас на реальную длительность. Для этого добавляем буфер на доступность ресурса БДР. Результат — на рис. 7.4.

7.3.4. БУФЕР НА ДОСТУПНОСТЬ РЕСУРСА

БДР (The Capacity Constraint Buffer) обеспечивает доступность ресурса в тот момент, когда он требуется для проектных работ. Теоретически буфер помещается между операцией, где используется ресурс в предыдущем проекте, и первой операцией, для которой он понадобится в интересующем вас проекте. БДР влияет скорее не на общую продолжительность проекта, а на дату начала работы в нем данного ресурса.

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

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

При определении размера БДР нужно учитывать теорию очередей и методику выравнивания ресурсов. Теория очередей требует, чтобы буфер на доступность ресурса соответствовал как минимум 25% мощности ресурса, ограничивающего мощность системы. Иначе проекты начнут тормозить.

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

Своим слушателям я задаю вопрос: «Какова будет длина очереди, если ее пропускная способность, то есть скорость прохождения через нее людей, равняется скорости прибытия людей?» Большинство отвечает, что очереди вообще не будет или в ней окажется всего один человек. К сожалению, это яркий пример неспособности человеческого мышления оперировать категориями вариабельности. В данном случае постепенно величина очереди начнет стремиться к бесконечности. Конечно, только если мы располагаем бесконечным количеством времени. Так или иначе, длина может очень быстро вырасти и не будет сокращаться, если не увеличить пропускную способность обрабатывающего звена (не открыть «новое окошко») или не уменьшить пополняющий очередь поток. Может, поэтому многие магазины закрываются на ночь.

На рис. 7.5 изображена классическая кривая, описывающая одну очередь, обслуживаемую одним обрабатывающим звеном. Она показывает зависимость длины очереди от загруженности, где загруженность — это отношение средней скорости пополнения очереди к ее пропускной способности. Кривая времени ожидания будет иметь ту же форму. При х = 1 средняя скорость пополнения очереди равна средней скорости обработки. Обратите внимание, что чем ближе к этой точке, тем резче увеличение длины, которая в конце концов начинает стремиться к бесконечности. Конечно, эта модель основана на определенных статистических допущениях, однако в целом она дает весьма универсальную картину. Как только загруженность становится больше 70%, или 0,7, что соответствует 30%-ному БДР, очередь начинает стремительно расти.

Вероятно, следующие соображения помогут вам понять, откуда берется такой неожиданный результат. Допустим, вы работаете на 90% мощности и пропустили один день по болезни. Чтобы наверстать упущенное,

вам потребуется 9 дней, потому что на это каждый день у вас есть запас мощности лишь 10%. Теперь представим, что вы тратили 95% мощности. Чтобы нагнать, нужно будет уже времени вдвое больше, потому что свободного времени теперь вдвое меньше, а доделывать придется чуть больше. Если же работали на все 99%, то после пропуска догонять будете 99 дней. Когда речь идет о 100%, простой не компенсировать никогда.

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

Если вы не хотите бесконечно дожидаться, пока ресурс-«барабан» освободится для участия в вашем проекте, используйте буфер на доступность ресурса величиной от 25 до 30%.

7.3.5. БУФЕР ОГРАНИЧИВАЮЩЕГО РЕСУРСА

По замыслу Голдратта, задача буфера ограничивающего ресурса (буфера «барабана», Drum Buffer) заключается в обеспечении ресурса-«барабана» необходимым для работы материалом в тот момент, когда участие его требуется в проекте. В этом смысле БОР — «подающий» буфер, подобно буферу на слияние путей. Не путайте буфер ограничивающего ресурса с буфером на доступность ресурсов. Буфер ограничивающего ресурса нужно помещать в расписании проекта непосредственно перед той операцией, где он нужен. Буфер на доступность ресурса в планы отдельных проектов не включается, он появляется в ССРМ, лишь когда необходимо по времени «развести» между собой несколько проектов. Если БОР попадает в критическую цепь, он может повлиять на запланированную дату начала проекта и его общую продолжительность. Вовсе не обязательно, чтобы БОР был именно в критической цепи, хотя чаще всего там он и оказывается.

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

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

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

7.3.6. РАСПИСАНИЯ ПРОЕКТОВ

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

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

Обратите внимание: вы не выравниваете ресурсы по всем проектам. Вместо этого вы составляете план каждого проекта, предполагая оптимальное наличие ресурсов, а после подбираете время начала проектов так, чтобы обеспечить доступность ресурса-«барабана» на всех проектах (то есть выравнивается по всем проектам только ресурс-«барабан»). Таким образом минимизируется общая длительность каждого проекта, при этом производительность Т всей организации получится максимальной. Если проводить выравнивание всех ресурсов по всем проектам, вы потеряете время. Это все равно что пытаться скосить всю траву разом.

7.4. Еще один взгляд

на ограничение одновременных проектов

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

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

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

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

7.5. Запуск новых проектов

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

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

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

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

На рис. 7.6 показан процесс ввода нового проекта в график «барабана». Сначала предполагаем, что работы должны начаться немедленно. Помещаем новый проект пока над следующим за ним по приоритету, как сделано на рис. 7.6. Проекты, которые обладают меньшим приоритетом, размещаем над новым проектом. Затем располагаем операции в соответствии с доступностью ресурса, как показано на рис. 7.7. Это может вызвать приостановку ряда уже идущих проектов. Рассуждайте здраво. Не прерывайте почти завершенные работы, пока не получите их результатов.

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

7.6. Вопросы, часто задаваемые по системному планированию нескольких одновременных проектов

1. В нашей организации со временем произошли изменения. Как найти, что сейчас является «барабаном» системы?

Очень полезно время от времени проверять, не сменился ли ресурс-«барабан». Если сменился, пора пересмотреть проекты. Зачастую даже при смене «барабана» величина отсрочек, необходимых для оптимального выполнения проектов, сильно не меняется.

2. Все наши проекты чаще всего одновременно проходят одни и те же фазы. Так что в течение года ограничение меняется. Как его найти?

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

3. Может ли одновременно существовать несколько ресурсов-«бара-банов»?

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

4. Как убедить руководство соблюдать назначенные нами приоритеты?

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

7.7. Итоги

Критическая цепь отдельного проекта обычно не является ограничением по отношению к целой организации, занимающейся выполнением множества проектов одновременно. В компаниях, ведущих несколько проектов, необходимо определить ограничение системы, общее для множества проектов, и пройти через пять направляющих шагов ТОС, чтобы найти способ применения метода ССРМ. Найдя ограничение и спланировав проекты с учетом его возможностей, вы определили «барабан», задающий ритм работы всей организации. Вот основные принципы ССРМ для системного управления несколькими проектами:

• ограничение системы нескольких одновременных проектов — это ресурс-«барабан»;

• руководство должно выявить ресурс-«барабан» и расставить приоритеты всех проектов, чтобы определить правило очередности использования этого ресурса;

• буфер на доступность ресурса обеспечивает наличие ресурса именно в тот момент, когда он необходим; размер БДР должен составлять от 25 до 30% мощности ресурса-ограничения;

• буфер ограничивающего ресурса БОР защищает ресурс-«барабан» от нехватки материалов для работы;

• даты начал отдельных проектов определяются при помощи графика «барабана», куда входят также БДР и БОР;

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

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

Данный текст является ознакомительным фрагментом.