Вовремя и в рамках бюджета. Управление проектами по методу критической цепи
Шрифт:
На рис. 7.5 изображена классическая кривая, описывающая одну очередь, обслуживаемую одним обрабатывающим звеном. Она показывает зависимость длины очереди от загруженности, где загруженность — это отношение средней скорости пополнения очереди к ее пропускной способности. Кривая времени ожидания будет иметь ту же форму. При х = 1 средняя скорость пополнения очереди равна средней скорости обработки. Обратите внимание, что чем ближе к этой точке, тем резче увеличение длины, которая в конце концов начинает стремиться к бесконечности. Конечно, эта модель основана на определенных статистических допущениях, однако в целом она дает весьма универсальную картину. Как только загруженность становится больше 70%, или 0,7, что соответствует 30%-ному БДР,
Вероятно, следующие соображения помогут вам понять, откуда берется такой неожиданный результат. Допустим, вы работаете на 90% мощности и пропустили один день по болезни. Чтобы наверстать упущенное,
вам потребуется 9 дней, потому что на это каждый день у вас есть запас мощности лишь 10%. Теперь представим, что вы тратили 95% мощности. Чтобы нагнать, нужно будет уже времени вдвое больше, потому что свободного времени теперь вдвое меньше, а доделывать придется чуть больше. Если же работали на все 99%, то после пропуска догонять будете 99 дней. Когда речь идет о 100%, простой не компенсировать никогда.
Реальность такова, что в отсутствие специального буфера люди пытаются решить проблему, прикладывая дополнительные усилия. В ход идут переработки, которые могут и не оплачиваться. Приходится придумывать, как не дать основной работе остановиться. Иногда находят какие-то кратчайшие пути решения задач, чтобы их не скапливалось слишком много. Иногда решают передать на следующий этап сырой или низкокачественный результат. И хотя в ограниченных количествах (например, пара недель) переработки могут позволить вернуть проект в нормальное русло, если вы пользуетесь методом ССРМ, все же исследования показали, что продолжительные сверхурочные работы приводят к торможению или падению уровня производительности Т.
Если вы не хотите бесконечно дожидаться, пока ресурс-«барабан» освободится для участия в вашем проекте, используйте буфер на доступность ресурса величиной от 25 до 30%.
По замыслу Голдратта, задача буфера ограничивающего ресурса (буфера «барабана», Drum Buffer) заключается в обеспечении ресурса-«барабана» необходимым для работы материалом в тот момент, когда участие его требуется в проекте. В этом смысле БОР — «подающий» буфер, подобно буферу на слияние путей. Не путайте буфер ограничивающего ресурса с буфером на доступность ресурсов. Буфер ограничивающего ресурса нужно помещать в расписании проекта непосредственно перед той операцией, где он нужен. Буфер на доступность ресурса в планы отдельных проектов не включается, он появляется в ССРМ, лишь когда необходимо по времени «развести» между собой несколько проектов. Если БОР попадает в критическую цепь, он может повлиять на запланированную дату начала проекта и его общую продолжительность. Вовсе не обязательно, чтобы БОР был именно в критической цепи, хотя чаще всего там он и оказывается.
Обычно я говорю, что, если вы только начинаете использовать метод ССРМ, особенно над буфером ограничивающего ресурса не задумывайтесь. Он может вам вообще не потребоваться. Как правило, достаточно бывает обычных средств ведения проектов по ССРМ и ежедневного отслеживания статуса работ.
Если вы все же берете БОР, определяйте его размер по правилам для буфера на слияние путей, беря за исходные данные длительность предыдущей цепочки операций.
Кто-то предлагает брать за основу для определения БОР произвольно выбранные цифры, например две недели. Не вижу оснований для такого подхода. Единственное возможное объяснение — боязнь того, что руководство станет злоупотреблять ресурсом-«барабаном». Поскольку использование БОР (предыдущий абзац) обеспечивает наличие работы для исполнителя-ограничения еще до того, как тот сможет за нее взяться, с него могут начать требовать ускориться, быстрее
Получив график «барабана», можете приступать к созданию расписаний отдельных проектов. Дата начала проекта должна определяться с учетом доступности ресурса-«барабана». То есть, чтобы назначить дату начала работ, вы проходите цепочку операций от той, где потребуется ресурс-
«барабан», к началу проекта. Поскольку для составления графика «барабана» вам требовалось расписание критической цепи с некой точкой отсчета, даты начал некоторых проектов, возможно, изменятся. Срок, на который они сдвинутся, будет равен сумме величины отрезка, на который сдвинулась операция того или иного проекта при составлении графика «барабана», и величины БОР. Затем размечайте все оставшиеся операции, двигаясь от тех, где нужен ресурс-«барабан», к концу проекта.
Обратите внимание: вы не выравниваете ресурсы по всем проектам. Вместо этого вы составляете план каждого проекта, предполагая оптимальное наличие ресурсов, а после подбираете время начала проектов так, чтобы обеспечить доступность ресурса-«барабана» на всех проектах (то есть выравнивается по всем проектам только ресурс-«барабан»). Таким образом минимизируется общая длительность каждого проекта, при этом производительность Т всей организации получится максимальной. Если проводить выравнивание всех ресурсов по всем проектам, вы потеряете время. Это все равно что пытаться скосить всю траву разом.
Когда в организации выполняется несколько проектов сразу, могут возникать совершенно особые ситуации. Если у вас происходит нечто неординарное, вспоминайте основные постулаты теории ограничений и пять направляющих шагов. Этот подход заставил руководителей ряда крупных проектов, в которых я участвовал, по-новому взглянуть на ограничение системы. В двух случаях речь шла о масштабных программах, а это тоже своего рода системы одновременных проектов. Такая система характеризуется своим набором выделенных ресурсов, и проблема заключается в том, как завершить все ее проекты (программу) максимально быстро. В одном из случаев нужно было устранить многочисленные неполадки в существующей структуре, а в другом — произвести несколько видов сложного оборудования для некой огромной и еще более сложной системы.
Марк Веппель, консультант ТОС из Плано, штат Техас, приводит следующую аналогию. Представим, что продукт программы — это гоночная машина. Программа завершена, когда машина добралась до финиша. Дистанция длинная, водители несколько раз меняются. Водители гоночной машины — исполнители проектных работ в программе. Это те, кто непосредственно работает с оборудованием. Ряд технических ограничений не позволяет производить действия над оборудованием одновременно нескольким группам исполнителей. Например, когда идут покрасочные работы, нельзя работать сваркой. Или если рабочее пространство ограничено, находиться там может лишь определенное число людей.
Водителям помогает множество специалистов. Когда машина заезжает в бокс, у них должно быть все необходимое, чтобы быстро провести наладку механизмов, тем самым оптимизировав работу водителя и доведя скорость машины до максимальной.
При наличии уникального ограничения, такого как гоночная машина, планирование начинается с определения критической цепи каждого проекта. Затем вы выстраиваете «конвейер», то есть последовательность запуска проектов с учетом возможностей ресурса-ограничения («барабана»). Но и это еще не все. Следует снизить влияние ограничения. Для этого нужно действовать подобно команде техников на гонках и подготовить подробные планы того, как максимально настроить все мощности, пока машина находится в боксе.