Критическая цепь - Элияху Голдратт

— Это логично, — заключает Тед. — Это окажет свое действие, — и признается: — Должен сказать, что я только сейчас начинаю понимать важность поведенческого аспекта. Я понимал, почему мы должны урезать время оценки с девяносто процентов вероятности завершения в срок всего до пятидесяти. Но только сейчас я понял всю значимость этого. Глядя ретроспективно, приходится признать: это очевидно.

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

Марк пока не готов присоединиться к философским рассуждениям.

— Есть еще одна вещь, о которой нужно сказать, — замечает он. — Перепрыгивание от задания к заданию. Устранение ложных тревог и реальное сокращение времени на выполнение каждого элемента очень помогло уменьшить перепрыгивание от задания к заданию. Значительно уменьшилась нервозность. Насколько это влияет на сокращение времени исполнения? Я не знаю, но полагаю, что существенно.

Рут поворачивается ко мне:

— Профессор Силвер, вы бываете у нас каждую неделю. Каково ваше впечатление?

Я могу говорить только о том, что я видел. Многого за час визита не увидишь.

— Я не думаю, что могу сделать оценку того, насколько сократилось перепрыгивание от задания к заданию. Но одно очевидно: люди значительно более сфокусированы.

— Да, проект намного более сфокусирован, это несомненно, — подтверждает Марк.

— Я могу кое-что сказать? — задает Марку риторический вопрос Фред. — Я думаю, что то, что мы ввели ресурсный буфер, было одним из самых важных шагов.

— Да, — соглашается Марк. — Раньше часто случалось, что для следующего элемента было готово все, кроме людей. Они работали с чем-нибудь другим. Мы решили, что для элементов на критическом пути этого не должно случаться. Теперь мы обеспечиваем заранее, чтобы тогда, когда все остальное на критическом пути готово, ресурсы были готовы.

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

— Нет, мы так не делаем. За неделю до ожидаемого времени мы просто напоминаем людям, что их задание, находящееся на критическом пути, на подходе. За три дня до его начала мы снова посылаем им напоминание, и потом опять за день, когда мы знаем наверняка, что все остальное будет готово, чтобы передать работу. Самое главное — это то, что люди знают: когда время подошло, они должны оставить все остальное, с чем они работали, и работать на критическом пути.

— И я не слышала, чтобы кто-нибудь жаловался, — замечает Рут. — Наоборот, они довольны, что их предупреждают заранее.

— Это очень важно, — подчеркивает Фред. — Без этого, я уверен, что мы бы теряли весь выигрыш от раннего завершения. Чтобы показать вам, насколько хорошо мы движемся, я приведу только одну цифру. Три недели назад, когда мы начали, буфер проекта был девять недель. Сегодня он все так же девять недель.

— И это несмотря на то, — добавляет Марк, — что все думали, что время, которое мы оставили для каждого элемента, было слишком коротким.

— Спасибо, — говорю я.

Класс хлопает. Они идут на свои места. Тут Фред поворачивается и говорит:

— Я хотел спросить одну вещь.

— Да?

— Меня не устраивает то, как мы измеряем прогресс.

Марк останавливается на полпути:

— В чем проблема?

— Я слежу только за критическим путем, и пока все в порядке. Но я боюсь, что где-нибудь на некритическом пути может зреть проблема, и к тому времени, когда она разовьется до такой стадии, что начнет задерживать критический путь, будет слишком поздно.

— Это действительно проблема, — говорит Марк, застыв в проходе.

— Садитесь, — говорю я. — Проблемы нет. Вы следите правильно.

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

— Фред, — начинаю я. — Вы следите за состоянием буфера проекта, правильно?

— Да, — подтверждает он.

— Как вы это делаете?

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

— Оценки того, сколько процентов работы они завершили?

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

— Если вы боитесь того, что на каком-нибудь некритическом пути может зреть проблема, почему вы там не делаете то же самое?

Он смотрит на меня с недоумением.

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

— Если подумать, то, по сути дела, мы делаем этот расчет. Но не формально. Фред, ты можешь следить за всеми буферами, а не только за буфером проекта?

— Без проблем. Я буду посылать тебе ежедневный отчет, — с готовностью отвечает Фред.

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

— В соответствии с важностью, — отвечает кто-то.

— Определите что такое «важность».

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

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

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