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