Чтение онлайн

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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