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