Вовремя и в рамках бюджета

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

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

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

Разработана масса критериев, позволяющих определить «барабан» системы. С одной стороны, планы проектов дают полную картину потребностей в ресурсах. С другой стороны, вам известно, какой объем ресурсов доступен. Можно назначить «барабаном» ресурс, на который наблюдается самый большой спрос. Однако есть смысл использовать данный способ, только если вы полностью уверены в достоверности исходных данных. Говоря о производстве, Голдратт не рекомендует этот метод, ссылаясь на то, что абсолютно точной информации на руках никогда не бывает. Это может оказаться справедливым и для проектов. Чтобы пойти этим путем, нужно быть уверенным в том, что ресурс, который вы прочите на роль «барабана», действительно нельзя просто так взять и сделать более доступным (например, наняв контрактников или временный персонал).

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

Назначая исполнителей, не указывайте конкретные имена. Во многих компаниях фиксируется имя человека, назначенного на решение задачи. Считается, что иначе и нельзя, ведь у каждого специалиста в компании имеется совершенно уникальный набор знаний и навыков. Если это так и есть, то по-другому действительно нельзя. Но должен предупредить, вы очень рискуете, ставя производительность Т системы ваших проектов в зависимость от конкретных людей. А что если они уйдут в отпуск или заболеют? Вся работа встанет. Эту ситуацию необходимо учесть, когда будете оценивать риски проектов.