Акупунктура, Аюрведа Ароматерапия и эфирные масла, Консультации специалистов: Рэйки; Гомеопатия; Народная медицина; Йога; Лекарственные травы; Нетрадиционная медицина; Дыхательные практики; Гороскоп; Правильное питание Эзотерика

Предисловие

Когда концепция критической цепи увидела свет, мне посчастливилось тут же разглядеть, насколько удачно она дополняет свод знаний по управлению проектами PMBOK^™. Я принялся работать над синтезом этих двух областей — над управлением проектами методом критической цепи (Critical Chain Project Management, CCPM). Тогда специалисты, знакомые с теорией ограничений систем (ТОС), и те, кто являлся частью профессионального сообщества менеджеров проектов, не очень-то пересекались между собой, отчасти потому, что теория ограничений зародилась в производственной сфере.

Когда менеджеры проектов впервые услышали о ССРМ (некоторые — во время моего выступления на ежегодном съезде PMI (Project Management Institute), проходившем в Лонг-Бич, штат Калифорния, в 1998 году), мнения их о теории разделились. Большинство вдохновилось новым подходом, желая освоить его как можно быстрее и применять на практике. Небольшая, но заметная группа, оказавшаяся в меньшинстве, составила движение протеста, лозунги которого сводились по большому счету к тому, что «ничего нового в этом нет». В издания PMI (PM Network, PM Journal) полетели письма, разгорелись дебаты, и ряд авторов, в том числе и я, в своих статьях сформулировали некоторые ключевые аспекты проблемы. Я был открыт для конструктивной критики, однако меня совершенно не вдохновляли аргументы типа «это уже было». К счастью, в PMI преобладали люди рассудительные. Мою книгу взяли к распространению и помогли организовать двухдневный семинар. Недостатка в желающих посетить его не наблюдалось, и отзывы участников были самые лестные.

Сейчас уже несколько крупнейших компаний мира, а также ряд серьезных правительственных организаций на собственном примере показали, каких небывалых результатов можно достичь, применяя ССРМ. Письма с критикой перестали поступать в адрес редактора PM Network, и метод критической цепи как один из способов составления графика проекта должен быть официально включен в руководство PMBOK™ издания 2004 года, выход которого ожидается через месяц¹. В большинстве книг по управлению проектами, издаваемых сейчас, используется концепция критической цепи, и в ряде случаев я был приглашен поучаствовать в написании соответствующих глав. Обсуждение в PM Journal продолжается, но теперь это деловая, конструктивная критика, которая помогает совершенствовать концепцию. И хотя некоторые приверженцы старой школы управления проектами до сих пор путают понятия «буфер» (buffer) и «временной резерв» (float) и, по-видимому, никак не могут освоить принципы статистического мышления, лежащего в основе ССРМ, концепция пережила период разногласий и перешла в разряд базовых методик управления проектами.

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

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

Благодарности

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

Хочу выказать свое уважение и благодарность доктору Элияху Голдрат-ту — за создание теории ограничений и концепции критической цепи в отдельно взятом проекте. Спасибо Ди Джейкобу из Института Авраама Голдратта AGI за то, что ввел меня в его стены в середине 1990-х. Также благодарю Тони Риццо за признание подхода «системного управления проектами организации» и за приглашение участвовать в самых первых опытах использования ССРМ.

Глава 1. Начнем с начала

Проекты заканчиваются крахом с пугающей частотой. По статистике, в 30% случаев работы останавливаются на полпути, и в итоге оказывается, что время, деньги и силы были потрачены впустую. Зачастую проекты завершаются с нарушением сроков, с превышением бюджета при невыполнении первоначальных целей. Причем нередко расхождения с плановыми значениями сроков и затрат могут доходить до 100%. Из-за этого ежегодно теряются миллиарды долларов. Данная проблема не связана с конкретным типом проекта или страной реализации. Она универсальна. Попытки как-то улучшить итоговые показатели по проектам создают в основном дополнительные проблемы и для людей, и для организации: исписываются горы бумаги, однако результат наблюдается минимальный, а иногда и вообще обратный. Специальность «управление проектами» отстала в своем развитии от других сфер человеческой деятельности, таких как технологии или производство. Цель данной книги — помочь вам и вашей компании радикально улучшить управление проектами.

В первых трех главах содержится общая информация об управлении проектами по методу критической цепи (CCPM). Поэтому если вам хочется получить представление о методе ССРМ в управлении отдельным проектом, можете сразу переходить к главе 4. Если же вам не терпится узнать, как правильно запустить отдельный проект, начните с главы 6, где говорится о разработке плана успешного проекта. Глава 7 расскажет о том, как планировать несколько проектов, в которых задействованы одни и те же ресурсы.

Настоящая же глава является вводной в CCPM, в ней определяется суть вопроса и на некоторых примерах показывается, что ССРМ зарекомендовала себя в качестве эффективной методики для самого широкого спектра проектов в самых различных сферах. Задача данной главы — убедить вас в том, что при использовании традиционных подходов к управлению проектами, даже работая изо всех сил, максимальных результатов не добиться. Кроме того, эта глава готовит вас к прочтению главы 2, в которой закладывается фундамент для восприятия нового подхода, коим является управление проектом по методу критической цепи.

В разработанном PMI «Руководстве к своду знаний по управлению проектами» [1]² проект определяется как «временное предприятие, имеющее целью создание уникального товара или услуги». Характеристика «временный» призвана отличить проект от повседневных производственных процессов. Прилагательное «уникальный» показывает, что проекты отличаются друг от друга. Проект является успешным, если заказчики получают то, чего хотели, тогда, когда хотели, за заранее оговоренную цену и при этом команда проекта довольна результатом.

Главы с первой по третью написаны с учетом существующей традиционной методологии управления проектами. Хотя в проджект-менеджменте уже наметились некоторые перемены, все же в имеющейся специализированной литературе чаще всего при обсуждении вопроса разработки графика в первую очередь описывается метод критического пути (critical path method — CPM). В PMBOK упоминаются и другие методы, а в издание 2004 года должен попасть также метод критической цепи³, однако «критический путь» сейчас используется значительно шире. Большинство программных продуктов основаны именно на СРМ.

В PMBOK также рассматривается управление рисками (как способ реагирования на неопределенность) и метод освоенного объема (как способ оценки и контроля). Управление рисками и метод освоенного объема применяются при реализации многих крупных проектов, особенно тех, что делаются по заказу правительства США.

Большинство программных продуктов и абсолютно все приложения, которые мне встречались, в рамках СРМ настроены на создание графика типа «ранний старт». Это означает, что программа составит расписание работ таким образом, чтобы они начинались как можно раньше и помещались на графике как можно левее. На рис. 1.1 дан типичный план проекта, построенный таким образом.

Иногда, чтобы отличить проекты от обычного производства, смотрят на количество получаемой продукции и на относительную длительность операций. При реализации проектов обычно возникает результат в своем роде уникальный. В ходе производства же появляется значительное количество более-менее похожих единиц продукции. Некоторое пересечение есть между проектом и изготовлением под конкретные пожелания заказчика (например, сборка автомобиля на заказ). Как я обнаружил, многие считают, что стандартное производство и проекты — совершенно разные вещи. В середине 1990-х я первый раз услышал о теории ограничений систем — ТОС, впервые описанной доктором Элияху Голдраттом в книге «Цель» (The Goal) [2]. Порекомендовав роман нескольким менеджерам проектов и программ, выяснил, что никто не видел никакой связи между ТОС и управлением проектами. Впоследствии я нашел способ преодолеть власть традиционной парадигмы мышления. Показывая людям рис. 1.2, я спрашиваю: «Что это — проект или процесс производства?» Реакция аудитории очень интересная. В большинстве случаев вид у всех озадаченный. Быстрого ответа не дает никто. Затем один предполагает: «Может быть, и то, и то». Остальные сразу соглашаются. На самом деле может быть и так, и так. На этом уровне сходства очевиднее различий. Поэтому в первую очередь мы с вами проанализируем такую общую черту проектов и производства, как вариабельность длительности отдельных операций. Речь идет об операциях, преобразующих некие входные параметры в результаты на выходе; из таких операций состоят как взаимозависимые этапы производственного процесса, так и этапы реализации любого проекта.

Реальная длительность производственной операции обычно является лишь малой составляющей общего времени выполнения заказа. Многие считают, что длительность проекта зависит от фактического времени выполнения задач и, следовательно, что оно на 100% определяет срок завершения проекта. Концепция критической цепи ставит данный подход под сомнение.

1.1. Успешный проект

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

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

1.2. Определение проблемы

Большинство ученых сходятся во мнении, что правильная постановка проблемы — самый важный шаг к выработке подходящего решения. Мой любимый философ Карл Поппер [3] отмечает: «Наука начинается с проблем, затем переходит к противоречащим друг другу теориям, чтобы осмыслить их критически». То же самое относится и к общей проблеме улучшения результативности проектов. Вслед за Поппером призываю вас критически рассмотреть то, что я называю «существующей системой» управления проектами, — систему, которой вы пользуетесь сейчас, и рассмотреть ее в свете предлагаемого метода критической цепи. Как вы увидите, формулировка проблемы «повышение результативности реализации проектов», пожалуй, слишком обща для того, чтобы по ней можно было выработать какое-либо последовательное эффективное решение.

1.2.1. НАСКОЛЬКО СОСТОЯТЕЛЬНА СУЩЕСТВУЮЩАЯ ПРОЕКТНАЯ СИСТЕМА

Задайте себе следующие вопросы:

1. Часто ли вы слышали о том, что проект занял больше времени, чем планировалось?

2. Как часто вам приходится слышать, что проект завершился намного раньше, чем планировалось, без особых усилий со стороны команды проекта?

3. Часто ли вы слышали, что проект превысил запланированный бюджет?

4. Много ли вы знаете случаев, когда на проект было затрачено значительно меньше того, что закладывалось в бюджет?

5. Приходилось ли вам слышать о том, что в ходе реализации объем работ или спецификации пересматривались, потому что невозможно было следовать первоначальным?

6. Довольны ли заказчики тем, что по ходу проекта приходится изменять его содержание?

1.2.1.1. Типы проектов

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

Проекты типа I имеют заданный срок реализации и выполняются для внешнего заказчика. Примером служат подготовка коммерческих предложений и проведение крупных мероприятий. Заказчик попросту не примет к рассмотрению предложение, поданное позже установленной даты. Поэтому команды, разрабатывающие соответствующую документацию, редко срывают сроки. Если менеджер по подготовке предложения, затратив время и средства, опоздал с ответом заказчику, руководство отреагирует незамедлительно и совершенно определенным образом. Иногда доходит до рекомендации подыскать себе другое место работы. Как правило,

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

Для проектов типа II никто извне не навязывает конкретных сроков сдачи работ (хотя руководство внутри компании может устанавливать свои даты). К ним относятся многие инициативы, запускаемые с целью заработать денег. Например, внедрение нового продукта, строительство отеля. К этой же категории относится большинство правительственных проектов. Если реализация будет запаздывать, вы все равно не лишитесь всех выгод. Вернее, лишитесь, но только на время, однако обычно никто об этом не задумывается и в явном виде это не просчитывается. В таких проектах, где нет строгого ограничения по времени, могут меняться значения всех трех переменных: и содержание, и бюджет, и сроки.

Проекты типов III и IV, как правило, в рамках одной компании соперничают в битве за финансирование. При этом проекты третьего типа занимают более высокое место в списке приоритетов, поскольку, чем бы ни были продиктованы сроки, нарушение их часто влечет за собой штрафные санкции. И наконец, проекты типа IV зачастую определяют будущее компании. Организации запускают такие проекты, чтобы совершенствоваться. Следовательно, чем быстрее реализовать подобный проект, тем лучше. Однако, к сожалению, в списке приоритетов эти начинания чаще оказываются на последних позициях, что для них выливается в нехватку ресурсов и постоянные отсрочки.

Вне зависимости от того, на какое место в рейтинге вы поместите тот или иной проект, я полагаю, что «любой стоящий проект стоит делать быстро». Потому что вы не начнете получать отдачу, пока проект не будет выполнен. При этом деньги в работу уже вкладываются — с самого начала. Таким образом, если проект начат, то, закончив его как можно скорее, вы обязательно увеличите показатель рентабельности инвестиций.

1.2.1.2. Некоторые факты

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

Почти все знают о грандиозных проектах, реализация которых сопровождалась серьезными проблемами. Аэропорт в Денвере (штат Колорадо), или тоннель под Ла-Маншем, соединивший Францию и Великобританию (так называемый «Чаннел»), или Международная космическая станция [6], или Большой бостонский тоннель «Биг-Диг». Помимо запаздывания по срокам и перерасхода бюджета большие трудности возникли и с содержанием проектов. Еще долгое время после открытия аэропорта Денвера система регистрации и выдачи багажа в нем не работала. Пассажирские перевозки по «Чаннелу» были невозможны даже после того, как отгремели звуки торжественной церемонии открытия. По состоянию на 2004 год один из новых американских модулей МКС продолжал простаивать на Земле. Многие также знакомы с проблемой «фантомного ПО»: практически все выпуски программного обеспечения происходят позже плановой даты, и при этом в них полно ошибок, недоделок и не хватает многих заявленных функций. Особых успехов в данном искусстве добились в Microsoft.

В одной статье я нашел описание эпопеи с Денверским аэропортом. Он был построен с опозданием практически на два года. Затраты выросли с $3 млрд до $4,2 млрд. Не все первоначальные задачи были решены. Газета также сообщала хорошую новость: прибыль аэропорта в 1996 году составила 28 млн. Давайте-ка посчитаем 28 млн от 4,2 млрд дает 0,6% ROI в год. Много ли нашлось бы желающих вложить деньги в такой проект? Инвесторы, выделившие средства в обмен на облигации, даже обратились в суд.

Мысли, изложенные в табл. 1.2, зародились в среде руководителей проектов и теперь благодаря Интернету гуляют по всему миру. Это лишь один пример из массы подобных, свидетельствующих лишний раз о том, сколь часто проекты завершаются неудачей. Полезно отметить, что для этих неудач не существует культурных и национальных границ. Во многих книгах по управлению проектами есть разделы о причинах провалов и способах их устранения.

1.2.1.3. Некоторые цифры

Правительство любит собирать и публиковать данные о результатах анализа реализации проектов. Обычно не принято включать туда позитивную информацию о подрядчиках, так что картина может показаться весьма предвзятой. Вот некоторые количественные данные.

Главное бюджетно-контрольное управление США (GAO) опубликовало отчет о результатах анализа крупнейших проектов по внедрению систем (с бюджетом более чем $75 млн) министерством энергетики США [4]:

1) в период с 1980 по 1996 год министерство энергетики запустило 80 крупных проектов по внедрению систем энергопитания;

2) в 31 случае реализация была остановлена до завершения проекта, причем к моменту прекращения работ уже было потрачено свыше $10 млрд;

3) завершены были лишь 15 проектов и по большей части с нарушением сроков и превышением бюджета;

4) вдобавок результаты 3 из этих 15 проектов до сих пор не применялись по назначению;

5) реализация остальных 34 проектов продолжается и в большинстве случаев с существенным превышением бюджета и переносом сроков.

А вот более свежая информация — неутешительная, несмотря на все старания исправить ситуацию с качеством выполнения проектов [5]. Проведенное в сентябре 2002 года сравнение 25 крупных проектов министерства энергетики 1996 года и 16 проектов 2001 года показало, что уровень работы подрядных организаций за это время не слишком вырос. И в 1996-м, и в 2001-м наблюдались сдвиги по времени и увеличение затрат. Причем доля таких проектов в 2001 году была больше, чем в 1996-м. Так, бюджет проектов 2001 года вдвое превысил плановые показатели в 38% случаев по сравнению с 28% 1996 года.

А теперь данные из другого отчета GAO — оценка проводимых NASA работ над последней моделью космической станции [5]:

1) при проверке в июне 1997 года было отмечено продолжающееся уже на протяжении некоторого времени ухудшение показателей по соблюдению сроков и бюджета головным подрядчиком;

2) указывается, что за время с января 1995 года по апрель 1997 года затраты, связанные с переносом сроков, выросли с $43 млн до $129 млн;

3) за тот же период разница между фактической стоимостью отдельно взятой операции и выделенными на нее средствами из имевшегося первоначально запаса в 27 млн превратилась в перерасход размером $291 млн;

4) по состоянию на июль 1997 года расходы, вызванные увеличением сроков, выросли до $135 млн, и превышение бюджета возросло до $355 млн;

5) особенные опасения внушают отклонения по затратам, поскольку никакой тенденции к уменьшению расхождений между плановыми и фактическими значениями не выявлено.

Вот куда уходят деньги налогоплательщиков! Обратите внимание, что это две разные правительственные организации с абсолютно разными проектами и условиями их реализации. Однако результаты в обоих случаях одинаково плачевные.

Та же горестная картина наблюдается и в министерстве обороны. Джеймс Льюис [7] рассказывает о прекращении в 1991 году программы А-12 «Мститель». Это решение привело к сокращению 9000 рабочих мест, а правительство затеяло судебное разбирательство по факту переплаты подрядчикам в размере $135 млн. Как пишет Льюис, «надежный источник в министерстве обороны сообщил, что по отношению к обоим генподрядчикам по всем правилам использовалась система контроля затрат и управления графиком C/SCSC (cost/schedule control system criteria)». (Кто-то может, правда, сказать, что это самая мудреная из всех имеющихся на сегодня методик).

Одно достаточно давнее исследование в Австралии [8] показало, что из всех строительных проектов в оговоренные контрактом сроки завершается лишь одна восьмая и превышение плановых показателей в среднем составляет более 40%. Об этом было упомянуто в недавнем отчете Дэниела Чана и Мохана Куммарасвами [9] о причинах превышения сроков при реализации строительных проектов в Гонконге. В нем также говорится: «Задержки при выполнении строительных работ до сих пор остаются очень распространенным явлением практически по всему миру, несмотря на появление новых технологий строительства и более эффективных технологий управления».

Более всего, похоже, обречены на неудачи проекты по разработке программных продуктов. Самые свежие статистические данные [10] говорят о «значительном» прогрессе, наблюдающемся с 1994 года: «Доля успешных проектов возросла до одной трети, или 34% от всех реализуемых проектов. По сравнению с показателем в 16% за 1994 год рост составил 100%. Количество неудавшихся проектов снизилось до 15% от общего числа, что составляет менее половины от 31%, наблюдавшегося в 1994 году. Остальные 51% проектов попадают в разряд “под риском”».

По моему мнению, одна треть — показатель, далекий от того, чтобы считаться признаком успешности. А как на ваш взгляд?

Что объединяет все эти случаи? Подход к управлению проектом. Везде использовался метод критического пути. Может быть, использовался он не всеми одинаково и не всеми правильно, но в любом случае заявлялось, что применяется именно этот способ планирования.

Есть несколько условий, которые нужно выполнить перед тем, как начинать какой-либо проект. Даже если целью является совершенствование управления самими проектами. Вот что необходимо сделать:

• удостовериться, что задача, которую вы собираетесь решать, — правильная (правильная задача);

• проверить, что выбранный подход к решению задачи позволяет ее реально осуществить (правильный подход к решению задачи);

• составить такое проектное задание, которое обеспечит реализацию выработанного решения (правильное решение);

• выполнить проект, реализовав поставленную задачу в рамках проектного задания, не нарушая сроков и не выходя за рамки бюджета (правильная реализация).

В последнем пункте вновь упоминаются три необходимых условия реализации любого проекта.

1.2.2. ПРИБЫЛЬ ОТ РЕАЛИЗАЦИИ ПРОЕКТОВ

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

В компаниях, успешно реализующих проекты, создана такая система работы, которая позволяет достичь победы при существующих условиях. Условия, как правило, предполагают наличие конкурентов, также пользующихся подобной системой управления. Иметь конкурентоспособную систему не значит быть безупречным или даже просто очень хорошим, это даже не значит, что ваша теория является правильной. Чтобы добиться успеха, нужно всего лишь быть хотя бы чуточку лучше конкурентов. Зачастую достичь этого можно, совершенствуя методы оперативной работы, даже если при этом система имеет серьезные изъяны. Однако, поработав именно над данными изъянами, вы сможете завоевать рынок — при условии, что конкуренты не сумеют с точностью или хотя бы просто быстро повторить ваш ход.

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

Похоже, есть одна общая черта у всех компаний, успешно занимающихся проектными работами. О ней говорится и в PMBOK: время от времени, хотя, вероятно, недостаточно часто, авторы упоминают, что пренебрежение именно данным моментом является одной из причин неудач. Дело в том, что во всех компаниях, преуспевающих в области проектного менеджмента, существует эффективный процесс управления изменениями. Он позволяет выявлять все изменения и оценивать соответствующие финансовые последствия. Многие слушатели моих курсов по управлению проектами жалуются на нескончаемые неконтролируемые изменения содержания проекта по ходу реализации, или «сдвиг содержания» (scope creep). И я говорю им, что в моих проектах никогда такого не происходит и что, по моему мнению, неконтролируемые изменения в содержании проекта — проблема, вызванная самим менеджером проекта. Опытные менеджеры держат содержание проекта под контролем. Управление и контроль содержания — первоочередная обязанность менеджера проекта. Я приветствую изменения, сообщаю я своим слушателям (часть которых воспринимает это, раскрыв рты от удивления). Но я держу изменения под контролем и уверяю того, кто выступил с инициативой, что обязательно реализую его предложение, как только оно будет одобрено заказчиком проекта (даже если направление изменений задается самим заказчиком). Затем после тщательного анализа того, как отразятся все, даже относительно небольшие перемены на содержании, бюджете, графике проекта и какие с этим связаны риски, я организую процесс утверждения. Удивительно, как снижается количество подобных запросов, когда подходишь к ним серьезно.

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

1.2.3. ПРАВИЛЬНАЯ ПОСТАНОВКА ПРОБЛЕМЫ

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

Слушатели курса управления проектами в Институте Авраама Голдрат-та (Avraham Goldratt Institute — AGI) в ответ на вопрос о том, почему так сложно выполнить три необходимых для успеха проекта условия, перечисляют следующие факторы:

• непредсказуемые погодные условия;

• непредсказуемые трудности с поставщиками оборудования;

• превышение сроков в связи с необходимостью достижения соответствия требованиям законодательства;

• нереалистичный график;

• ненадежные (но предлагающие низкие цены) поставщики или подрядчики;

• сложности в подборе свободных исполнителей для задач проекта;

• непредсказуемые чрезвычайные ситуации и так далее.

Все перечисленное объединяет два момента: причина проблем находится вне зоны контроля менеджера проекта и является неким неожиданным событием.

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

1. Проектные работы можно строго определить. Анализ явлений действительности производится так, словно возможно дать единственную, однозначную и точную оценку параметрам работ. Получается, что проявления вариабельности являются следствием неправильной постановки и выполнения задач.

2. Существующий подход к управлению проектами (проектная система) является эффективным. Отсюда в качестве решения предлагается определить ту часть системы, которая не работает должным образом и вызывает появление проблемы. Ни в одном исследовании не была поставлена под сомнение эффективность самих используемых систем (зачастую бывает даже не вполне ясно, о каком именно подходе идет речь). И ни в одном исследовании не оспариваются установки, легшие в основу появления данных систем.

Один из путей к пониманию причин успехов и провалов проектов — изучение организационной системы и тех исходных установок, на которых она базируется. По словам Альдо Леопольда [11], который в своей профессиональной деятельности занимался вопросами, не связанными с проектами, мы, несомненно, могли бы выявить факторы, которые влияют на успешность реализации проектов. Факторы — это то, что более-менее прямо сказывается на успехе, то есть на степени соответствия трем необходимым условиям успеха проекта. Итак, факторы успеха — это:

1) правильный выбор задачи;

2) правильный подход к решению задачи;

3) разработка соответствующего проектного задания;

4) использование эффективной системы контроля выполнения проекта;

5) эффективная реализация проекта;

6) использование эффективного метода управления неопределенностью.

Эффективная система контроля выполнения проекта определяет:

• количество задействованных людских ресурсов;

• квалификацию людей, занятых на проекте;

• принципы работы;

• сам процесс управления проектом;

• используемые методы и инструменты;

• управление изменениями при реализации проекта.

Данный список не является полным, однако в него попали многие пункты, освещенные в различных исследованиях причин проектных неудач.

В дополнение к факторам, влияющим на успех проекта, можно также выявить факторы второго ряда, воздействия — то, что сказывается на уже перечисленных нами явлениях. Такими внутренними (по отношению к проектной команде) воздействиями оказываются:

1) управление;

2) система оценок;

3) поощрения;

4) политики;

5) социальные нормы;

6) вариабельность в процессах, обеспечивающих результаты проекта.

Воздействиями, внешними по отношению к проектной команде, будут в том числе:

1) конкуренты;

2) поставщики;

3) заказчик;

4) законодательные органы;

5) пространство, на котором реализуется проект;

6) другие заинтересованные в реализации проекта стороны (например, общество).

Эти воздействия второго ряда могут сказываться на одном или нескольких факторах, которые, в свою очередь, непосредственно влияют на степень успешности проекта. Табл. 1.3 демонстрирует отношения между факторами и воздействиями, а также авторскую оценку степени влияния вторых на первые.

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

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

Приступая к разработке метода критической цепи, Голдратт назвал причиной неудачных проектов саму систему. Он сформулировал вопрос так: «Что в существующей системе обрекает на неудачу такое большое количество проектов?» Опираясь на предшествующий опыт работы с производственными системами, он выдвигает гипотезу, согласно которой существующая система неэффективна для управления в условиях неопределенности.

1.2.4. ПРАВИЛЬНОЕ РЕШЕНИЕ

За последние сорок лет была предложена масса вариантов улучшения методов управления проектами. Специалисты пытались добиться более успешного выполнения пожеланий заказчика в срок и в рамках бюджета. Как правило, упор делался на подробнейшем рассмотрении вопросов планирования, измерения и контроля. Усовершенствованные компьютерные программы для управления проектами приводят к выделению все большего количества операций. Программа помогает автоматически создать график, выделить критический путь, назначить ресурсы и измерить «процент выполнения» на любом уровне детализации.

Свою работу по критическим цепям [12] Голдратт начинает с рассказа о компании, которая хотела сократить время реализации проектов по разработке новой продукции. Консультантами была проведена огромная работа по анализу системы управления проектами, результатом которой стала масса рекомендаций по внесению изменений в существующие подходы. Но на вопрос, сколько же времени сэкономит компания, последовав всем этим рекомендациям, был получен ответ: «Может, процентов пять. А может, и меньше».

1.2.4.1. Сделать еще лучше...

Использование концепции освоенного объема (earned value) и производной от нее системы контроля затрат и управления графиком (CSCS) приводит к увеличению детализации при разработке плана проекта и системы измерений. Процедуры, необходимые для использования компанией данной системы, зачастую достигают в объеме нескольких сотен страниц. Количество названий задач в графике проекта доходит до десятков тысяч. И иногда появляется требование минимизировать длительность выполнения задач, например до срока в «не более чем две недели».

Автору довелось работать с одним правительственным учреждением, где на протяжении двадцати лет использовался подход, требующий очень детального составления планов. И каждый раз при возникновении проблемы находили виноватого, выискивали причину и создавали все новые процедуры. На подготовку проекта уходило минимум лет семь, и это без учета времени на саму реализацию проекта! То есть только на составление плана закладывалось семь лет. Проводились технические исследования, составлялись отчеты о концепциях продукта — результата проекта, устраивались независимые оценки затрат, внедрялись системы CSCS. Но по мере реализации затраты росли, график сдвигался, и все чаще и чаще не выполнялись техзадания. Однажды проект был остановлен, когда не него уже ушло больше миллиарда долларов. А некоторые проекты идут с запозданием на десятки лет.

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

Давайте повнимательнее взглянем на подход «сделать еще лучше». Если вы ставите перед собой цель непременно завершать проекты с определенным составом работ за определенное время и определенные деньги, все эти три условия должны быть описаны четко и однозначно. А чтобы четко описать условия, необходимо детальнее спланировать проект, потому что ранее при имевшемся уровне детализации плана проект успехом не увенчался. Звучит логично и согласуется с тем, что пишут в литературе: неудачи на проектах связаны с неправильным определением условий и созданием недостаточно подробного плана.

Такой подход часто ведет к появлению планов из десятков тысяч операций. Недавно мы работали с клиентом, который весьма гордился тем, что у них план проекта состоит из 30 000 операций.

Позже мы поговорим о том, какие факторы помогут вам определить степень детализации при создании плана. Иногда в случае с крупными проектами речь действительно может идти о тысячах операций. Забегая вперед, скажу: как правило, план должен быть более скромным по размерам — операций на 100. Простейшие подсчеты показывают, что одна операция в среднем составляет при этом 1% от всего проекта (в долл., или в человеко-днях, или даже в днях). Большинство менеджеров проектов были бы счастливы, если бы реализация их проекта расходилась с планом всего на 1%. Однако в основе проблем лежит нечто, вызывающее отклонения более чем на 1%. Поэтому, на мой взгляд, увеличение детализации плана и количества составляющих его операций (чтобы их было более 100) никак не поможет добиться успеха. Дело должно быть в чем-то другом.

Иногда в поддержку детализации слышатся следующие аргументы: проблема, хотя она и значительно больше 1%, связана с тем, что при планировании мы что-то пропустили. Но недостающие 20% не могут скрываться внутри имеющегося 1%. Поиски крупных пропущенных составляющих среди деталей задачи, являющейся 1% от проекта, напоминают анекдот о подвыпившем прохожем, который обронил ключи на углу улицы, но ищет их под фонарем, потому что там светлее, а на углу темно и ничего не видно. Если боитесь упустить что-то важное, лучше смотрите, чего не хватает между выделенными 100 операциями, а не пытайтесь разбить эти уже выявленные задачи на все более мелкие элементы.

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

1) согласно теории познания, один или несколько примеров еще не доказывают состоятельности всей теории (см. также далее в главе 2);

2) это могла быть особая ситуация: возможно, решение применялось в такой запущенной ситуации, что любое малейшее упорядочивание работы приводило к значительным улучшениям;

3) работает житейский «закон зебры»: за чрезвычайно черной полосой, скорее всего, последует белая;

4) возможно, наблюдается Хоторнский эффект: психологическое явление, при котором лица, приглашенные участвовать в испытаниях нового метода, положительно высказываются о результатах любых изменений, даже если они не отличаются от тех, что наблюдались до проведения эксперимента.

Иными словами, предложенные теории не были критически осмыслены и экспериментально проверены авторами.

1.2.4.2. Вариабельность и неопределенность

Всем известно, что операциям проекта свойственна изменчивость, или вариабельность, причем зачастую степень вариабельности характеризуется неопределенностью граничных условий. По определению проект — это то, чего раньше никто не делал, некая уникальная задача. В любом случае никто никогда не выполнял все те же задачи и тем же образом, как это требуется в рамках данного конкретного проекта. Чтобы успешно выполнить проект, необходимо принимать во внимание явления вариабельности и неопределенности. Способность человека точно оценить ситуацию зависит от нескольких факторов. Существует масса примеров, показывающих, что люди склонны переоценивать точность собственных прогнозов [14]. Как правило, длительность большинства проектных операций нельзя назвать с точностью выше, чем ±20%.

На тренингах мы просим слушателей прикинуть длительность одной очень простой операции. Практически все соглашаются, что операция эта намного проще, чем большинство выполняемых по их проектам. Также все присутствующие на тренинге сходятся во мнении, что должны суметь оценить длительность данной операции не хуже, а может, и лучше, чем оценивают длительности реальных операций участники их проектов. Разброс оценок составляет до нескольких сотен процентов от средней вели чины, а стандартное отклонение — 30%. На рис. 1.4 представлены суммарные результаты нескольких подобных экспериментов.

На рис. 1.5 степень точности оценки параметров отдельной операции дана как функция от количества усилий, затраченных на выработку этой оценки. Точность оценивается в процентах от средней величины оценочного значения, где абсолютно точная оценка будет иметь степень неопределенности равную нулю. Если для оценки не было приложено никаких усилий, то неопределенность составит как минимум 100%, а может быть, и на порядки (на сотни процентов) выше. Как показывает кривая, обычно чем больше сил потрачено на выработку оценки, тем большей становится ее точность (и меньше неопределенность). Возможности улучшения ограничены нижним пределом, определяемым вариабельностью, присущей самому процессу, в рамках которого необходимо будет выполнять поставленную на проекте задачу. Это вариабельность, вызываемая так называемыми общими причинами, мы поговорим о ней далее в главе 2. Сколько бы сил вы ни прикладывали, вам никогда не сделать оценку точнее, чем позволяет характерная для данного процесса вариабельность. Снизить степень ее проявлений можно, лишь изменив что-то в соответствующем процессе.

Рассмотрим две части, на которые график на рис. 1.5 делится вертикальной пунктирной линией. Посмотрим на правую часть. Увеличение затрат на оценку не вызывает практически никакого увеличения ее точности. И чем правее находится отрезок шкалы, тем меньшая наблюдается зависимость между снижением затрат и ростом неопределенности. Слева же картина обратная — видна четкая связь между степенью неопределенности и количеством усилий, затраченных на оценку. Даже небольшое сокращение затрат повлечет за собой значительный рост неопределенности. А небольшое увеличение их вызовет радикальное улучшение качества оценки.

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

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

Добавление задач в план проекта увеличивает количество потенциальных связей между ними на порядки, превышающие число этих новых записей. Так, если вы прибавили всего одну строку в проект, в котором их уже 100, вы потенциально внесли и 200 новых связей между задачами, поскольку каждая операция, уже имеющаяся в плане, будет потенциально предшествовать новой или следовать за ней. А дополнительные взаимосвязи, возникающие при появлении новых задач, значительно увеличивают риск ошибок в сетевой диаграмме.

Из обсуждавшихся до сих пор возможных причин неудачных проектов вы могли сделать вывод, что это неопределенность вызывает проблемы при реализации. Если бы было именно так, то можно было бы предположить, что любой проект, существующий в ситуации неопределенности, обречен на провал. Основываясь же на определении проекта и нашем с вами знании жизни, можно утверждать, что неопределенность свойственна всем проектам. Следовательно, все проекты неминуемо должна постигнуть неудача. Во многих случаях это утверждение справедливо, но не во всех. Более того, есть примеры успешной реализации проектов в условиях максимальной неопределенности. В своей работе под названием «Критическая цепь» (Critical Chain) Голдратт описывает проект по созданию аэроплана, опровергающий высказанный нами ранее вывод. Разработчики сделали новую модель с непревзойденными характеристиками за 8 месяцев — вместо 10 лет, которые обычно уходят на подобные проекты. Есть и другие случаи. Соединенным Штатам удалось достичь поставленной президентом Кеннеди цели по отправке человека на Луну до конца десятилетия. Данный проект был самым неопределенным из всех, что выпадали на долю человечества. Подобным же проектом было создание атомной бомбы, завершившееся в рекордно короткие сроки.

Немалые силы брошены на то, чтобы снизить степень неопределенности при оценке параметров проекта и вариабельности при выполнении задач по проекту. Существуют прекрасные инструменты для оценки длительности проектов и составляющих задач. Они, без сомнений, помогают повысить точность оценки и, что еще важнее, собрать данные для оценки вариабельности проектных задач. Наблюдаются улучшения в сфере выполнения проектов — путем применения таких методологий, как шесть сигм. К сожалению, среди примеров неудач встречаются данные и о таких компаниях, в которых применяются подобные технологии снижения вариабельности. Говоря в общем и целом, к значительным улучшениям они не привели.

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

Если фактор неопределенности сам по себе не объясняет, почему срываются проекты, можно ли как-нибудь подогнать существующую теорию под имеющиеся примеры? Мы знаем, что иногда при реализации проектов используются разные средства управления неопределенностью. Например,

на проект «Аполлон» были приглашены три разных компании, которые предложили три разных решения по очень сложным разработкам. Выбран был один основной поставщик, а два других остались в качестве запасных — на случай, если решение первого не сработает. Была запланирована масса тестов и повторных проверок (и в ходе их проведения случился ряд весьма зрелищных срывов). Да, это затратный метод управления неопределенностью, но он работает. Руководствуясь теми же рассуждениями, Голдратт предположил, что причиной большинства неудач на проектах является отсутствие эффективного управления неопределенностью. В главе 3 мы рассмотрим эту гипотезу более тщательно. Если он прав, то решением может стать создание такой проектной системы, которая способна справиться с неопределенностью.

1.2.5. ПРАВИЛЬНОЕ ВЫПОЛНЕНИЕ

Здесь мы имеем в виду реализацию плана решения проблемы. Проектом является совершенствование самой проектной системы.

В очерке «Сага об улучшении производства» (My Saga to Improve Production) [15] Голдратт пишет:

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

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

1.3. Добиваемся успеха при помощи ССРМ

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

что эта новая теория также будет критически осмыслена и при применении обеспечит стабильно более высокий уровень качества реализации проектов. Хотелось бы видеть улучшение не на 5, а на 50%. Опираясь на данную теорию, мы также должны суметь объяснять причины уже имевших место успехов и неудач и делать оправдывающиеся прогнозы по готовящимся проектам. Опыт применения данного подхода демонстрирует гораздо больше преимуществ, чем обычно ожидается при внедрении новых методов. И все они тоже объясняются новой теорией. Вот перечень этих преимуществ (по сравнению с методом критического пути).

Увеличение количества успешно завершенных проектов:

• проекты всегда завершаются вовремя;

• проекты решают все поставленные задачи;

• проекты завершаются в рамках бюджета;

• проекты приводят к усилению положения компании на рынке и росту бизнеса.

Сокращение времени реализации проектов:

• работы завершаются вдвое (а иногда и более) быстрее, чем ранее при реализации подобных проектов;

• объем плана проекта сокращается как минимум на 25%;

• значительно уменьшается длительность сложных проектов;

• снижается количество изменений на проектах;

• коммерческие проекты раньше начинают приносить прибыль;

• инвестиционные проекты окупаются быстрее.

Повышение степени удовлетворенности проектной команды:

• уменьшается путаница от возникновения множества пересекающихся задач;

• появляется возможность заниматься одновременно лишь одной задачей;

• снижается количество изменений;

• снижается количество переделок;

• снижается давление на проектную команду со стороны менеджеров отдельных проектов;

• снижается количество ситуаций типа «если не сделаешь, нам конец» (то есть задач, жестко привязанных к конкретным датам);

• исполнители пользуются информацией о буфере, чтобы определить приоритетность своих задач;

• снижается количество случаев внезапного появления новых приоритетных задач;

• упрощается система измерений;

• статус выполнения плана определяется легко и быстро;

• имеется информация о фактическом статусе проекта, то есть нет необходимости дожидаться появления финансовых отчетов;

• можно мгновенно получить статусный отчет по буферу, по цепи и по задаче;

• отчет по буферу определяет дальнейшие решения;

• отчетность по буферу вынуждает при принятии решений фокусироваться на приоритетах руководства (они видны по датам начал работ в графике).

Упрощение управления проектом:

• менеджеру проекта предельно ясно, на чем необходимо сосредоточить усилия (критическая цепь, сокращение случаев раннего старта);

• упрощение планов проектов уменьшает количество бумажной работы;

• упрощается процесс отчетности по статусу проекта;

• дальнейшее планирование или действия зависят от результатов измерений;

• приоритетность ресурсов зависит от результатов измерений.

Увеличение производительности проекта при неизменности ресурсов:

• снижается количество споров за ресурсы;

• больше проектов завершается за меньшее время при тех же ресурсах;

• сокращается необходимость привлекать новые незаменимые ресурсы;

• уменьшается количество задержек из-за проблем с ресурсами;

• улучшается картина движения денежных средств по проекту;

• увеличивается показатель рентабельности инвестиций ROI.

Рассказы очевидцев часто вдохновляют людей испробовать новые идеи. Парадигма критического пути СРМ царствовала более сорока лет, поэтому многим сложно согласиться на перемены. Однако все больше и больше самых различных компаний добиваются успеха, используя метод критической цепи. Приведем ряд примеров. Как уже говорилось, пример еще не подтверждает состоятельности теории. Он лишь показывает, что она не является совершенно безнадежной.

1.4. Honeywell Defense Avionics Systems [16]

«Команде, работающей на Королевские ВВС Нидерландов, поступило задание, на выполнение которого обычно закладывалось 13 месяцев, однако результат был получен уже спустя полгода... в экспериментальном режиме используется новый метод составления графиков программ с использованием концепции критической цепи. С этой концепцией также знаком и поддерживает ее Boeing».

1.5. Lucent Technologies [17]

Lucent Technologies использует ССРМ в качестве основной технологии управления своими проектами. (Автор данной книги проводил для компании соответствующий тренинг и оказывал помощь при внедрении).

«В 1996 году специалисты одной родственной компании заявили Lucent Technologies Advances Technology Systems (теперь в составе General Dynamics), что реализовать планировавшийся тогда проект длительностью один год — совершенно нереально. тогда тот проект выбрали в качестве пилотного, чтобы испытать методы управления проектами по ТОС. В июне 1997 года проект был завершен раньше срока».

1.6. Авиационная промышленность Израиля

В авиапромышленности Израиля трудится около 15 000 человек. Основная их деятельность — техническое обслуживание самолетов, осуществляющих пассажирские перевозки. Один из видов техобслуживания, так называемый «тип D», занимает в среднем по отрасли 46 дней. Штраф за превышение срока очень высок — $60 000 в день, поскольку авиакомпании должны вовремя получить свои самолеты, чтобы не срывать запланированные рейсы. Ежегодно обслуживающая компания выплачивала до $25 млн штрафов. В письме управляющего к Голдратту [18] говорится: «Нам удалось снизить среднее время проведения осмотров с трех месяцев до двух недель и увеличить число заказов — теперь они расписаны не на два месяца, а на год вперед».

1.7. Американское судостроение

Военно-морское ведомство США внедрило ССРМ на нескольких судостроительных предприятиях. Один из самых ярких примеров успеха — проводившееся в 2001 году техобслуживание военного корабля «Гарри Трумэн» — одного из крупнейших в мире. Применение некоторых приемов

ТОС и ССРМ даже на базе традиционного программного обеспечения позволило команде реализовать этот грандиозный проект раньше срока и сэкономить свыше $20 млн. Последующее внедрение нового подхода на верфи Перл-Харбор вызвало повышение показателя соблюдения сроков с 40 до 90% и рост производительности более чем на 100% по другим, менее масштабным проектам по обслуживанию атомных подводных лодок США. Сейчас ВМС США внедряют ССРМ в рамках еще более крупных проектов на четырех государственных верфях и планируют то же самое для нескольких частных, с ними сотрудничающих.

1.8. Итоги

В данной главе мы сформулировали проблему, решение которой является целью этой книги. Мы определили ССРМ как новую теорию, которая призвана решить эту проблему. Ключевые мысли главы:

• при использовании метода критического пути процент успешно завершившихся проектов растет, но все же остается недостаточно высоким, и это справедливо для любых проектов в любых культурах;

• среди гипотетических причин неудачных проектов нет таких, что являются внешними по отношению к системе проекта, поэтому зачастую решение проблемы с трудом реализуется в старой системе: подход «планировать все в деталях»; похоже, что это не решит настоящей проблемы;

• использование подхода «планировать все в деталях» и стремление сократить степень вариабельности при оценке и выполнении задач по проекту дает низкий показатель ROI (порядка 5%) при больших вложениях;

• все больше примеров свидетельствуют о том, что настоящая проблема находится в самой системе управления проектом, тем более что данная система не способна обеспечить эффективное управление неопределенностью;

• правильное решение заключается в разработке подхода, который дает больший процент успешных проектов и является простым в применении;

• имеющееся немалое количество примеров не опровергает предположения, что выработанный Голдраттом метод критической цепи обеспечивает соответствие всем трем необходимым условиям успешной реализации проекта, приводя к улучшениям на 50% и более при относительно небольших вложениях.

Сравнение результатов использования теории критической цепи и существующей теории (то есть концепции критического пути, описанной в PMBOK) свидетельствуют в пользу необходимости применения ССРМ с последующим регулярным переосмыслением и совершенствованием этой теории.

ЛИТЕРАТУРА

1. PMI, A Guide to the Project Management Body of Knowledge, Upper Darby, PA: PMI,

2000.

2. Goldratt, Eliyahu M., The Goal, Great Barrington, MA: North River Press, 1984 (в русском переводе: Голдратт Элияху М., Кокс Д. Цель. Процесс непрерывного совершенствования. — М.: Попурри, 2007).

3. Popper, Karl R., Objective Knowledge, An Evolutionary Approach, Oxford: Clarendon

Press, 1997, p. 144 (в русском переводе: Поппер К.Р. Объективное знание. Эволюционный подход. — М.: Эдиториал УРСС, 2002).

4. GAO/T-RCED-97-92, “Department of Energy: Improving Management of Major System

Acquisitions,” Testimony, March 6, 1997.

5. GAO-03-570T. Status of Contract and Project Management Reforms. Statement of

Robin M. Nazzaro, Director Natural Resources and Environment. March 20, 2003.

6. GAO/T-NSIAD-97-262, “Space Station: Deteriorating Cost and Scheduler Performance under the Prime Contract,” Testimony, September 18, 1997.

7. Lewis, James P., The Project Manager’s Desk Reference, Chicago: Irwin, 1995, с. 245.

8. Bromilow, F.J., “Measurement of Scheduling of Construction Time and Cost Performance in the Building Industry,” The Chartered Builder, Vol. 10, 1974.

9. Chun, Daniel W. M., and Mohan M. Kummaraswamy, “A Comparative Study of Causes of Time Overruns in Hong Kong Construction Projects,” S)263-7863(96)0039-7, International Journal of Project Management, Vol. 15, No. 1, February 1997.

10. Standish Group, “Latest Standish Group CHAOS Report Shows Project Success Rates

Have Improved by 50%,” по адресу в Интернете http://www.standishgroup.com/ press/article.php?id=2 (информация для книги взята с сайта 29 апреля 2004 года).

11. Leopold, Aldo, Game Management, Madison: University of Wisconsin Press, 1933.

12. Goldratt, Eliyahu M., Critical Chain, Great Barrington, MA: North River Press,

1997.

13. Lambert, L. R. “Cost/Schedule Control Criteria (C/SCSC): An Integrated Project

Management Approach Using Earned Value Techniques,” The AMA Handbook of Project Management, New York: AMACOM, 1993.

14. Kahneman, Daniel, Paul Dlovic, and Amos Tvershky, Judgment under Uncertainty:

Heuristics and Biases, Cambridge: Cambridge University Press, 1982.

15. Goldratt, Elyiahu, “My Saga to Improve Production,” New Haven, CT: Avraham Y.

Goldratt Institute, 1994.

16. Honeywell Defense Avionics Systems, Albuquerque, New Mexico, Horizons, Vol. 5,

No. 2, February 20, 1998.

17. Rizzo, Anthony, “The TOC Solution of R&D and Multi-Projects Organizations,” Lucent

Technologies, Whippany, New Jersey, January 5, 1998.

18. См. http://www.Goldratt.com (веб-страница Института Голдратта AGI).

Глава 2. ТОС, РМВОК, бережливое производство и шесть сигм

Метод критической цепи в управлении проектами, которому посвящена эта книга, базируется на синтезе классического подхода к управлению (РМВОК [1]) и теории ограничений (ТОС). В свою очередь этот синтез осуществляется при помощи еще двух теорий: «бережливое производство» и «шесть сигм». В настоящей главе мы рассмотрим все эти дисциплины по порядку и увидим, какое отношение в целом они имеют к управлению проектами по методу критической цепи.

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

На рис. 2.1 видно, как по-разному подходят к описанию системы управления проектами представители разных теорий. Так, в случае с РМВОК характеристики реальных проектов сравниваются с идеальной моделью, изложенной в этом стандарте и, следовательно, являющейся, с точки зрения РМВОК, правильной. При таком подходе вряд ли причиной неудач может быть признан какой-либо из элементов самой модели. Скорее,

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

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

Концепция шести сигм и ее предшественник — всеобщее управление качеством, или TQM (total quality management), нацелены на непрерывное совершенствование процессов путем реализации соответствующих проектов с высоким показателем рентабельности инвестиций (ROI). Подразумевается, что наилучший способ усовершенствовать систему — это улучшить в ней каждый процесс. TQM базируется на четырех составляющих (имеется в виду система глубинных знаний доктора Деминга), которые позволяют лучше понять причины, возникающие при реализации проектов. TQM располагает набором инструментов для проведения анализа и выявления истинных причин неудач.

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

2.1. Свод знаний по управлению проектами (РМВОК )⁴

С появлением в 1950-х и 1960-х гг. методов критического пути и диаграммы PERT управление проектами сделало громадный шаг вперед. PERT возникла в 1958 г. в ходе совместной работы ВМС США и консалтинговой фирмы Booz, Allen, Hamilton над проектом подлодки «Полярис». С распространением компьютеров эти методы укрепили свои позиции и успешно применялись в управлении проектом «Аполлон» по высадке человека на Луне (определенно, то был один из звездных часов человечества), а также во многих других крупных проектах оборонных ведомств.

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

На рис. 2.2 приведены области знаний, выделенные в РМВОК. Мы сосредоточимся на тех элементах, которые влияют на общие условия успешности проектов, и предложим внести в них некоторые изменения. К этим элементам относятся управление содержанием, сроками, рисками проекта, а также общая координация всех действий по управлению проектом, то есть управление интеграцией проекта⁵. Что касается остальных областей, выделяемых РМВОК, здесь все зависит от конкретных проектов и конкретных условий, в рамках которых вы работаете.

В каждой из этих областей существует набор процессов, которые в РМВОК распределены по пяти группам:

1. Инициация.

2. Планирование.

3. Контроль.

4. Исполнение.

5. Завершение.

Эти фазы приблизительно соответствуют основным этапам большинства проектов, но в реальной работе они не идут в строгой последовательности, а накладываются друг на друга. В РМВОК подчеркивается, что большинство процессов в системе проекта взаимосвязаны и взаимозависимы.

2.1.1. ОБЩАЯ КООРДИНАЦИЯ (ИНТЕГРАЦИЯ) ПРОЕКТА

К общей координации действий по управлению проектом относятся разработка и выполнение проектного плана, а также общее управление изменениями на протяжении всего проекта.

2.1.2. УПРАВЛЕНИЕ СОДЕРЖАНИЕМ ПРОЕКТА

К управлению содержанием проекта (project scope) относятся: инициация проекта, планирование, определение и подтверждение (scope planning, definition, verification), а также контроль изменения содержания (change control). Содержание проекта можно считать определенным, если разработаны устав проекта (project charter), иерархическая структура работ (work breakdown structure, WBS), подробное описание результатов проекта, или содержание работы (statements of work, SOW), особые функциональные и эксплуатационные требования (functional and operational requirements, F&OR) по исполнению проекта, зафиксированы исходные установки, допущения (assumptions), на основании которых формулировалось содержание, а также установлен процесс контроля за изменением самого содержания.

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

2.1.3. УПРАВЛЕНИЕ СРОКАМИ ПРОЕКТА

Управление сроками (project time management) предусматривает определение задач, или операций (activity), необходимых для выполнения заявленного содержания, их последовательности, оценку длительности операций, разработку расписания (schedule), то есть графика выполнения проекта и отслеживание выполнения графика. Для подготовки графика — на входе — нужны иерархическая структура работ, WBS и описание содержания проекта. В процессе разработки графика определяются требования к ресурсам по каждой операции и другие потенциальные ограничения. В РМВОК отмечается, что при оценке длительности работ должна указываться степень неопределенности, и делается отсылка на раздел по управлению рисками проекта, где говорится, как работать с неопределенностью. Также обсуждается необходимость выравнивания ресурсов (resource leveling) в плане проекта. Разграничение вариабельности, вызванной общими или специальными причинами, не производится (см. 2.5.2).

Управление стоимостью в РМВОК рассматривается отдельно от управления графиком выполнения проекта, однако процессы, определяющие их, одинаковы. Процесс управления затратами и графиком включает обновление графика проекта и оценок бюджета, планирование и выполнение корректирующих воздействий, систематизацию накопленных знаний (lessons learned) по завершении проекта.

2.1.4. УПРАВЛЕНИЕ РИСКАМИ ПРОЕКТА

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

2.1.5. ДРУГИЕ ОБЛАСТИ ЗНАНИЙ РМВОК

Остальные области знаний, выделенные в РМВОК, такие как качество, человеческие ресурсы, коммуникации, поставки, также в разной степени важны для реализации проектов. Они существенны для любого типа бизнеса. Однако, поскольку мы сосредоточены на иных вопросах, в данной книге рассматривать эти аспекты не будем.

2.1.6. ОРМ3

Методика оценки степени зрелости проектного управления в организации, или ОРМ3 (Organizational Project Maturity Model) [2], была опубликована PMI в 2003 году. Ее цель — «описать стандарт управления проектами и зрелости управления проектами». На мой взгляд, она разработана в соответствии с положениями модели CMM Института инжиниринга программного обеспечения SEI (Software Engineering Institute’s Capability Maturity

Model) [3]. До того, как приступить к созданию ОРМ3, команда PMI рассмотрела 27 различных моделей и назначила специальные группы по 3 человека в каждой, чтобы детальнее изучить 17 из них. ОРМ3 содержит исчерпывающие вопросники для оценки организаций на соответствие характеристикам, присущим высокоэффективным проекто-ориентирован-ным компаниям.

ОРМ3 — это значительный шаг вперед по сравнению с РМВОК, поскольку она охватывает организационную систему целиком, а не только некоторые элементы, необходимые для управления отдельным проектом. Сфера использования пяти групп процессов, выделенных в РМВОК, расширена здесь до управления программами и портфелями проектов. В каждой группе выделяются основные и вспомогательные процессы. Выделенные в методике ОРМ3 процессы в явном виде не структурированы по ТОС или ССРМ. Пока еще слишком рано делать выводы о полезности ОРМ3. Личный опыт использования модели SEI CMMTM при организации офиса управления проектами (project management office) в ИТ-компании заставляет меня думать, что модели приносят практическую пользу, только если применяются по отношению к факторам, способным повлиять на действующее в данный момент ограничение системы. Нужно быть очень осторожным, чтобы не потеряться в обилии деталей, появление которых может быть обусловлено подобным подходом. Скорее всего, ОРМ3 следует использовать именно таким образом (то есть в совокупности с направляющими шагами ТОС).

В процессе создания ОРМ3 проявился интересный аспект, имеющий отношение даже не столько к самой модели ОРМ3, сколько к теме нашей книги — совершенствованию управлением проектами. В предисловии к изданию ОРМ3 сказано:

«До первого квартала 2000 года наша стратегия заключалась главным образом в классическом линейном принципе водопада: первоначальное исследование перешло в стадию разработки, разработка — в выполнение и тестирование и так далее. Однако мы никак не могли приступить к анализу результатов исследования, и PMI обратился к нашей команде с просьбой ускорить, насколько это возможно, выполнение проекта. Руководители проекта ОРМ3 модифицировали стратегию, перейдя со схемы “водопад” на модель, близкую к “быстрой разработке прототипа” (с. 55)».

Хотя в РМВОК говорится о циклах альтернативной разработки, включая цикл спиральной разработки, о котором только что шла речь, многие компании сталкиваются с проблемой отсутствия полного понимания требований при запуске проекта. Я уже давно научился в подобных случаях при планировании использовать подход «набегающей волны». При этом подходе план составляется на тот объем, который в данный момент можно реально оценить, и включает в себя задачу по пересмотру плана при появлении новой информации. В разделе 2.3 об этом говорится подробней.

2.2. Бережливое производство

В книге «Машина, которая изменила мир» (The Machine That Changed the World) [4] Д. Вумек, Д. Джонс и Д. Рус познакомили с понятием «бережливое производство». К принципам бережливого производства они отнесли:

• командную работу;

• процессы коммуникации;

• эффективное использование ресурсов и устранение потерь;

• непрерывное совершенствование.

Развивая эту тему, Вумек и Джонс фокусируются на проблеме потерь и указывают на необходимость:

• определить, что является ценностью для конечного пользователя;

• выявить поток создания ценности;

• сфокусироваться на движении материалов в процессе производства;

• внедрить «вытягивающую» систему производства;

• стремиться к совершенствованию.

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

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

У. Детмер приводит превосходное выражение, описывающее синергию при взаимодействии двух теорий [6]: «На уровне организации ТОС представляет собой своего рода систему наведения, позволяющую направить усилия организации по применению бережливого производства туда, где это будет полезней всего, и предотвратить использование его там, где это только навредит».

Детмер также указывает на преимущества совместного использования ТОС и бережливого производства, включая такие методы последнего, как:

• пока-ёкэ (метод предупреждения ошибок);

• статистическое управление процессами;

• непрерывное совершенствование;

• анализ характера и последствий отказов (FMEA);

• принудительная остановка конвейера;

• организация рабочих ячеек (в данном случае создание рабочих центров там, где естественным образом сложились рабочие группы);

• роли, ответственность и правила работы в команде;

• графическое представление рабочих инструкций;

• визуальный контроль;

• 5s (От японских слов seiri, seiton, seiso, seiketsu, shitsuke, что в переводе означает «сортировать, соблюдать порядок, содержать в чистоте, стандартизировать процедуры, совершенствовать». Первые три понятия относятся к общему поддержанию порядка на рабочем месте. Оставшиеся два — к самоорганизации работника, которая позволит ему придерживаться первых трех, а также к руководству, которое обязано следить за соблюдением перечисленных правил.)

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

2.3. Agile, или Облегченные методы управления проектами

Значительной доли внимания удостоились легкие, или гибкие (agile), методы, предлагаемые для решения проблем, характерных для проектов, связанных с информационными технологиями. В Википедии говорится [7]: «Методы Agile возникли в середине 1990-х годов отчасти в противовес чрезвычайно формализованным методам, таким как Rational Unified Process (рациональный унифицированный процесс, RUP), Prince⁶, ISO 9000. Процессы, порождаемые данными методами, считались бюрократизированными, медленными, противоречащими стилю командной работы, принятой у инженеров, создающих ПО». Сторонники иногда называют этот подход «бережливое управление проектами» по аналогии с «бережливым производством». Причины, по которым в мире появились гибкие методы, описаны в главе 1: значительное превышение сроков и бюджета, неспособность добиться заявленных характеристик продукта в большинстве ИТ-проектов. Облегченные методы по ИТ-проектам включают:

1) быструю разработку приложений;

2) параллельную разработку приложений;

3) экстремальное программирование;

4) SCRUM⁷.

Подробное рассмотрение этих методов не является нашей целью.

Я все же с изрядной долей скептицизма воспринимаю объяснения типа «традиционное управление проектами не подходит для ИТ-проектов» как причину появления облегченных, или гибких, методов. От людей, по-настоящему, профессионально разбирающихся в управлении проектами (имеющих сертификат РМР), я подобных заявлений не слышал. Так, Дэвид Андерсон [8, с. 55] пишет:

«В традиционном подходе при запуске проекта главная задача — четко определиться с содержанием, зафиксировать бюджет (включая людей и ресурсы) и дату окончания работ. На этом основании стоит классическая модель управления проектами PMI, поддерживаемая тяжеловесными методами контроля качества ISO 9000... что создает для менеджеров ИТ-проектов наихудшие условия при разработке софта. Существующая модель управления проектами по PMI/ ISO 9000 устарела» (с. 60).

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

Приведу несколько соображений насчет «гибкого» управления в ситуации, когда требования определены не четко. Во-первых, такие стандарты,

как РМВОК и ОРМ3, не требуют досконального соблюдения всех своих предписаний абсолютно во всех проектах в каждой организации. Это некое меню, из которого можно выбирать и которое можно адаптировать к нуждам конкретной компании. Да, люди склонны применять подобные стандарты буквально и целиком, увязая в деталях, но проблема-то при этом не в стандарте, а в его использовании. К счастью, уже в самом начале карьеры я научился легко адаптировать такие стандарты к конкретным проектам, указывая в каждом плане проекта те процедуры, которые применимы в данном случае. Я понял, как использовать проверочные списки, чтобы быстро отбирать самое необходимое для конкретного проекта. В небольших, краткосрочных и малобюджетных проектах особые формальности не нужны и требуются очень простые приемы планирования и коммуникации. Проекты крупные, длительные, дорогие, с вовлечением большого количества подразделений и организаций должны быть более формализованы, тщательнее спланированы и строже контролируемы.

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

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

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

2.4. Шесть сигм

Существует несколько подходов к управлению качеством.

Концепция шести сигм была разработана в компании Motorola, но приобрела известность благодаря General Electric. Она дополняет принципы всеобщего управления на основе качества TQM.

Премия Малкольма Болдриджа в США⁸ — признание высочайших достижений в бизнесе. Изначально она базировалась на TQM, но сейчас границы ее расширяются.

ISO 9000 — международный стандарт качества, внедренный многими компаниями. На сайте премии Малкольма Болдриджа [9] приводится сравнение данных подходов:

«Хотя и критерии премии Болдриджа, и сертификация по ISO9001:2000, и шесть сигм являются системами измерения качества, нацеленными на совершенствование работы и увеличение степени удовлетворенности клиентов, но акценты в них расставлены по-разному.

Шесть сигм:

• концентрируются на измерении качества продукции и совершенствовании проектирования самих процессов;

• призывают к улучшению всех процессов и сокращению расходов.

Сертификация по ISO 9001:2000:

• представляет собой модель для объективной оценки соответствия продукции и услуг требованиям рынка;

• концентрируется на исправлении недостатков системы обеспечения качества продукции и услуг.

Критерии премии Болдриджа:

• фокусируются на достижении совершенства в работе всей организации через общие процессы управления;

• устанавливают и отслеживают общезначимые организационные результаты: клиенты, продукция и услуги, финансы, человеческие ресурсы, эффективность организации».

Из литературы может сложиться впечатление, будто TQM — это управленческая причуда, не оправдавшая возлагаемых на нее надежд и к концу столетия не нашедшая широкого применения. В опубликованной недавно книге о шести сигмах [10, с. 43-49] утверждается, будто шесть сигм решают все проблемы, с которыми не справилась концепция TQM. Я тем не менее полагаю, что TQM весьма эффективна, если применять ее правильно, а шесть сигм — часть продолжающегося процесса по совершенствованию TQM.

Критерии премии Болдриджа, как говорилось ранее, по нескольким сферам выходят за рамки, очерченные в литературе по шести сигмам. На церемонии награждения лауреатов премии в феврале 1999 года в Вашингтоне, округ Колумбия, президент США отметил, что победители, удостоившиеся премии за 1988-1997 годы, продемонстрировали удивительную окупаемость инвестиций на уровне 460%, по сравнению с 175%-ным показателем компаний списка S&P500 за тот же период. Кевин Хендрикс и Винод Сингаль [11] в апреле 1999 года опубликовали результаты исследования, по данным которого показатели компаний — обладательниц премий за внедрение TQM вдвое превосходят показатели компаний, не использующих TQM. Например, рост прибыли TQM-компаний составил 91% против 43% не-TQM-компании, рост продаж — 69% и 32% соответственно, рост стоимости активов — 79% и 37%. И хотя результаты сократились в 2002 году, когда вперед вырвались высокотехнологичные компании, в 2004-м вновь наблюдался рост.

Название «шесть сигм»⁹ связано с долгосрочной целью компаний радикально сократить количество брака. При подходе «шесть сигм» измеряемая характеристика готовой продукции — среднее значение показателя ± 6 сигм от среднего показателя — должна, по замыслу, полностью укладываться в допуски, определенные требованиями клиента. При соблюдении границ «шести сигм» на миллион единиц готовой продукции будет лишь 3,4 единицы с дефектом (при данном подходе допускается отклонение среднего значения от целевого на ± 1,5 сигмы). Сигма — это статистическая единица стандартного отклонения по процессу. В концепции шести сигм вариабельность — это зло, с которым следует бороться.

Разработчики метода «шести сигм», базируясь на Деминговском цикле PDCA (Plan — планируй, Do — делай, Check — проверяй, Act — внедряй), модернизировали его, получив в итоге цикл DMAIC (Define — определяй, Measure — измеряй, Analyze — проанализируй, Improve — совершенствуй, Control — контролируй). В данном подходе широко применяется теория вариабельности и статистические методы — основное, на чем мы сосредоточимся, говоря о ССРМ. Однако ТОС, также используя статистические приемы, предлагает упрощенные варианты решения для бизнеса, в то время как шесть сигм склонны к полноценному использованию статистических методов. Шесть сигм могут стать хорошим дополнением к ССРМ, если вы будете избегать субоптимизации отдельно взятых процессов и сфокусируетесь на максимальном использовании возможностей ограничения системы.

2.5. Система глубинных знаний

Деминг, которого многие считают отцом TQM, сам не дал никакого определения этой концепции. Он изложил свой подход на семинарах и в книгах [12, 13], и, будучи ярым приверженцем операциональных определений, не стал, однако, никак характеризовать TQM. Вместо этого он предпочитал говорить о 14 пунктах, или «принципах трансформации западного стиля менеджмента». Данные пункты Деминг сопроводил перечнем «болезней» и препятствий, способных встать на пути преобразований, к которым он призывает.

Впоследствии все методы, в действенность которых он верил, Деминг собрал воедино и назвал «системой глубинных знаний» [13]. Он определил эту систему как своего рода увеличительное стекло и карту, которые помогут понять и оптимизировать работу организации. Деминг подчеркивал, что глубинные знания представляют собой систему, у которой есть цель и составные части которой взаимосвязаны. Он выделил четыре компонента, отметив, что их нельзя рассматривать изолированно:

1) понимание системы;

2) знания по теории вариабельности;

3) теория познания;

4) психология.

На рис. 2.3 показаны взаимосвязи четырех элементов. В следующих разделах мы посмотрим, как все это соотносится с системой управления проектом.

2.5.1. ПОНИМАНИЕ СИСТЕМЫ

У каждой системы должна быть цель или задача. Это предназначение системы, определяющее ее границы. Сама по себе система — это сеть взаимозависимых компонентов, которые взаимодействуют, чтобы достичь цели системы. Цель коммерческих бизнес-систем — делать деньги сейчас и в будущем, вот почему люди инвестируют в такие предприятия. У организаций некоммерческих (или по крайней мере задумывавшихся как некоммерческие) другие цели: например, у учреждений здравоохранения — улучшение здоровья, у некоторых социальных институтов — обеспечение благосостояния семьи. Цель проектов уже была описана ранее: произвести уникальный продукт или услугу, соответствующие пожеланиям клиента, вовремя и в рамках запланированного бюджета. Заказчик при этом может соотносить результаты реализации проекта с более широкими целями организации, которую он представляет.

Система проекта включает в себя материальные объекты, людей, а также нематериальные сущности, такие как политики, знания, взаимоотношения. Все эти составляющие в разной степени взаимосвязаны и могут влиять на работу системы в целом. Процессы планирования и контроля также являются частью системы проекта. И выполнение работ командой проекта — тоже часть этой системы.

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

В 1950 году в Японии Деминг начертил схемку, подобную приведенной на рис. 2.4. Он в значительной степени связывал последовавший затем успех послевоенной Японии с мыслью, выраженной на данном рисунке. Описание бизнес-системы Деминг начинает с представления возможных товаров или услуг для потребителей. Это помогает спрогнозировать возможный спрос, пожелания и потребности заказчика. Подобные прогнозы обуславливают дизайн товара/услуги и позволяют продумать методы проверки соответствия продукции требованиям заказчиков перед запуском в массовое производство. Реальные отзывы клиентов — ключевой фактор, движущий развитием организации.

Так же работает система проекта. Заказчики сообщают, чего они ждут от проекта. Команда готовит план достижения заданных результатов. По плану различные подразделения компании, закупленное сырье и услуги объединяются, интегрируются в различных комбинациях для производства желаемого продукта. Налаженная система управления проектами может обеспечить выполнение большого числа разнообразных проектов, так же как налаженная производственная система может обеспечить выпуск большого количества разнообразных товаров или услуг. И хотя результат каждого проекта является уникальным, все же запланированное появление этих результатов обусловлено работой одной и той же системы.

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

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

2.5.1.1. Системная динамика

Питер Сенге [14] характеризует сущность дисциплины системного мышления через:

• видение сложных взаимосвязей, а не просто линейной причинноследственной цепочки;

• видение процесса изменений, а не только среза действительности в конкретный момент.

Его «законы пятой дисциплины» суммируют и демонстрируют принципы существования динамических систем (включая проекты).

1. Сегодняшние проблемы рождаются из вчерашних «решений». Руководство было недовольно графиком последнего проекта и сократило длительность отдельных работ. В следующий раз им захочется сократить людей.

2. Чем больше давление на систему, тем больше ее сопротивление. Руководство стремится увеличить производительность тем, что раздает исполнителям сразу множество проектных задач. Наличие нескольких заданий означает увеличение длительности выполнения большинства из них, так как одновременно человек может заниматься лишь чем-то одним (человек не многозадачная машина). Во время решения одной задачи остальные остаются нетронутыми. Время реализации каждого проекта в системе становится все больше, производительность всей системы — все меньше.

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

4. Простой выход на деле обычно оказывается бегом по кругу. Подробно данное положение объясняется в работе «Мифический человеко-месяц» (The Mythical Man Month) [15]. Чтобы не отстать от графика по проекту, где наметились задержки, руководство привлекает дополнительные ресурсы. Людей нужно найти, нанять, создать им рабочие места, обеспечить оборудованием, ввести в команду. Этот последний этап занимает особенно много времени у остальных членов команды. Отставание от графика лишь увеличивается.

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

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

7. Причина и следствие не обязательно близки во времени и пространстве. На космическом шаттле при запуске из Центра Кеннеди во Флориде происходит авария, в результате которой впоследствии шаттл взрывается. Причина — конструкция изоляционного покрытия, разработанная и протестированная в Юте несколькими годами ранее, но никогда не испытывавшаяся в реальных условиях. Космический телескоп «Хаббл» страдает «близорукостью» из-за ошибки, обошедшейся в миллиард долларов, и все потому, что за пару лет до запуска, еще на Земле, чтобы уложиться в срок, не провели один важный тест. Этот закон — основная причина, по которой многие расследования факторов, приводящих к неудачам в реализации проектов, дают неверные выводы. В таких сложных динамических системах, как проект, все завязано по времени. Невозможно соотнести причины и следствия, не представляя себе модели системы. Дерево текущей реальности ТОС — инструмент, позволяющий разобраться в причинно-следственных связях.

8. К большим результатам могут привести и совсем небольшие изменения, вот только очень сложно правильно определить точку приложения сил. Главным рычагом в системах, где действуют люди, является система оценок и поощрений. Однако последствия ее применения не всегда хорошо продуманы. Например, как отмечает Деминг, месячные нормативы вызывают «синдром конца месяца», когда в больших количествах производится некачественная продукция. При реализации проектов требование со стороны руководства о «соблюдении людьми своих обязательств» приводит к тому, что исполнители с большим запасом дают оценку длительности работ, а затем не сообщают о заданиях, выполненных досрочно, пока не наступит плановая дата сдачи.

9. За все нужно платить. Комплексное управление проектами организации по методу критической цепи позволяет завершать большее количество проектов за меньшие сроки. Длительность отдельных проектов сокращается, и количество завершенных проектов в каждый момент времени увеличивается. Однако для этого необходимо отодвигать начало некоторых проектов на более поздние сроки.

10. Разделив слона пополам, вы не получите двух маленьких слоников. Сенге приводит притчу о слепых, описывающих слона на основании собственных тактильных ощущений от какой-то отдельной части его тела: один говорит про хобот, другой — про массивное туловище, кто-то про ногу, а кто-то про хвост. Естественно, получаются совершенно разные описания одного и того же слона. В рамках анализа причин неудачной реализации проекта зачастую рассматриваются отдельные подпроцессы, такие как планирование или управление изменениями, — чтобы понять, какую часть системы необходимо совершенствовать. При подобном подходе не изучаются исходные установки, например убеждение, будто бы график исполнения проекта можно заранее строго и однозначно определить. А между прочим, это убеждение лежит в основе создания планов, где тысячам задач назначены четкие даты начала и окончания.

2.5.1.2. Рычаги воздействия

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

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

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

2.5.1.3. Непреднамеренные последствия

Связи и отношения между частями системы обуславливают тот факт, что изменения в одной из частей могут повлиять на другие. Как говорят законы «пятой дисциплины», изменения бывают желаемыми или нет, большими и не очень и, скорее всего, проявятся они вовсе не в том месте и не в то же время, что и причины, их порождающие. Многие люди, особенно те, кто склонен проворачивать аферы с социальными системами, используют термин «непреднамеренные последствия». Гарретт Хардин [16] говорит, что, с экологической точки зрения на системы, непреднамеренных последствий не бывает. Меняя одну часть системы, вы меняете и остальные. Вот и все! И можно предположить заранее, что некоторые изменения окажутся нежелательными в том или ином смысле. Следовательно, вы обязаны быть очень осторожными, производя перемены в системе управления проектами. Некоторые изменения, целью которых было избавление от определенных нежелательных явлений или даже истинных причин проблем, могут в свою очередь негативно сказаться на тех или иных элементах системы.

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

2.5.1.4. Разрушение системы

Разрушение системы под влиянием внутренних сил — одна из ключевых проблем, на которую Деминг стремился обратить внимание менеджмента. Он говорил о том, сколь пагубной, по сравнению с сотрудничеством, бывает вызванная частными интересами конкуренция между подразделениями. И Сенге [14], и Деминг [13, 14] приводят множество примеров того, как благие намерения правительства влекут за собой уничтожение системы, на которую они направлены. Так, организация жилья для малообеспеченных слоев населения вытесняет из района предприятия, обеспечивающие рабочие места, при этом привлекая все больше малоимущих в данный район, в итоге создав гораздо более серьезную проблему, чем наблюдалась до начала проекта.

В проектных системах подобные конфликты могут возникать между заказчиком и командой проекта. Они могут вспыхивать и между командой проекта и руководством компании. Конфликты разгораются и внутри самой команды проекта. Бывают противостояния между командой и другими подразделениями компании, оказывающими поддержку при реализации проекта. Наиболее часто встречающаяся ситуация, попадающая в последнюю категорию, — война между закупщиками и проджект-менеджерами, практически не прекращающаяся в больших организациях, особенно работающих на правительство. Зачастую отдел закупок в первую очередь нацелен на то, чтобы действовать по соответствующим процедурам и политикам, в то время как проектной команде важно, чтобы поставки шли быстро и качественно. Бывает, что задача закупщика — найти продукт подешевле, а задача проектного офиса — получить материал качественный. Управление проектами должно быть устроено таким образом, чтобы система оценок и поощрения различных подразделений организации способствовала их слаженной работе как единого целого. Как пишет Деминг: «Обязанность каждого элемента (системы) — максимально способствовать успеху системы, а не повышать собственную производительность, прибыль, продажи или какой-либо другой конкурентный показатель».

2.5.2. ПОНИМАНИЕ ВАРИАБЕЛЬНОСТИ И НЕОПРЕДЕЛЕННОСТИ

И обратился я, и видел под солнцем, что не проворным достается успешный бег, не храбрым — победа, не мудрым — хлеб, и не у разумных — богатство, и не искусным — благорасположение, но время и случай для всех их.

Екклесиаст, 9:11

Проектная система пытается предсказать и произвести определенный результат за определенные деньги и определенное время. Как следует из приведенного выше высказывания, всем прекрасно известно, что мир наш весьма переменчив. Вариабельность присутствует повсюду. Прогнозы никогда не бывают точными на 100%. И на мой взгляд, значение слова «точный» на самом деле не до конца правильно понимается, когда речь идет о реализации проектов вовремя и в заданных бюджетных рамках (см. последний абзац данной главы).

Понимание вариабельности жизненно необходимо для управления любой реальной системой. В эссе «Об облаках и часах» (Of Clouds and Clocks)

[17] Карл Поппер описывает основные для понимания вариабельности явления реальности. Он предлагает нам представить себе горизонтальную линию, на которой справа находятся часы, олицетворяющие точность и детерминированность. В таком мире все всегда можно четко предсказать, надо только хорошо представлять себе причинно-следственные связи, на которых основан механизм работы данной модели. Самое яркое проявление этой модели — движение планет Солнечной системы, которое можно рассчитать, используя уравнение, выведенное Исааком Ньютоном.

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

Неопределенность — это нечто, не поддающееся строгому описанию, недетерминированное, проблематичное, что может произойти, а может и нет, небесспорное и/или непостоянное. Все прогнозы неопределенны. Фундаментальная физика учит, что любое знание о реальности является неточным; чем больше мы знаем о положении объекта, тем меньше нам известно, как быстро он движется. Неопределенность — вот настоящее состояние нашего мира.

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

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

Начиная с XVII века математики и представители других наук стремились поместить предсказание событий все ближе и ближе к облачной части континуума Поппера. В то же время благодаря заслугам науки охват этой части все растет. С одной стороны, на чаше весов появилась точная квантовая механика, однако с расширением представлений о Вселенной перевешивает облако. После появления теории хаоса и с началом изучения комплексных адаптивных систем облако практически накрыло все промежуточные точки шкалы.

Общие и особые причины вариабельности

При необходимости сделать выбор в работе с «облачными» системами ученые опираются на принципы вероятности и статистику. Уолтер Шухарт

[18], наставник Деминга, описал необходимость поддерживать систему в состоянии статистического контроля, чтобы обеспечить определенную степень предсказуемости ее поведения. Он писал: «Любую математическую теорию, где используется это математически неопределяемое понятие (статистический контроль), можно выразить следующими словами: если делать это и это, в результате получите то и то».

Вслед за Шухартом Деминг подчеркивает важность различения вариабельности, вызванной общими причинами, и вариабельности, вызванной причинами особыми. Неспособность проводить это разграничение он называл «фатальной ошибкой». Различать их необходимо, чтобы поддерживать систему в статистически управляемом состоянии. А это нужно, чтобы прогнозировать ее работу. Общие причины вариабельности (изменчивости) присущи самой системе и позволяют ей воспроизводить повторяющийся результат в определенных рамках. Особые причины вариабельности выводят результат работы системы за эти определенные рамки; кроме того, они всегда обусловлены факторами, внешними по отношению к системе. Задача менеджмента — совершенствовать систему, не допуская двух ошибок:

1) интерпретация вариабельности, вызванной общими причинами, как проявление особых причин;

2) интерпретация вариабельности, вызванной особыми причинами, как проявление общих причин.

Управленческую ошибку первого рода Деминг называл дергание или излишнее вмешательство. Излишнее вмешательство вызывает ненужные изменения в системе, которая работает в статистически управляемых пределах. Подобное вмешательство всегда снижает качество работы системы. Деминг описывает ситуацию, когда на станок был прикреплен прибор, измеряющий каждую деталь и подгоняющий настройки на величину расхождения с плановой величиной, чтобы улучшить воспроизводимость и уменьшить изменчивость в параметрах деталей. Однако разброс в размерах деталей лишь увеличился, поскольку в снимаемые показатели уже входила естественная вариабельность, свойственная данной системе при производстве деталей. Прибор только усугубил присущую системе вариабельность.

О вмешательстве также можно говорить применительно к системам измерения и контроля при реализации проектов и к решениям об управленческих воздействиях, основанным на данных измерениях. Феномен в том, что, реагируя на общие причины вариаций так, словно это особые причины, мы вызовем ухудшение работы системы. Иными словами, внесение изменений в проект в ответ на незначительные расхождения с заданными параметрами снижает качество выполнения проекта.

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

2.5.3. ПСИХОЛОГИЯ

Ряд особенностей человеческого мышления заставляет людей сопротивляться переменам. Б.Ф. Скиннер [19] описывает один из наиболее мощных механизмов. Опираясь на большое количество научных данных, Скиннер утверждает, что поведение человека задается «оперантным обусловливанием». Проще говоря, вы продолжаете делать то, что когда-то было закреплено положительными эмоциями, и приучаетесь не повторять того, что не получает положительного подкрепления или же ведет к отрицательным переживаниям. Позитивное подкрепление — это нечто, вам приятное.

Негативное — неприятное. Для разных людей разные явления играют роль положительных и отрицательных закрепителей. Как отмечает Скиннер, «устанавливающаяся закрепительная связь необязательно будет очевидной для самого человека».

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

Условная связь, возникшая при оперантном обусловливании, должна в каком-то виде храниться в человеческом мозге. Поскольку она определяет модель мира (вероятно, рудиментарную; то есть — если сделать это, получишь то), можно считать ее убеждением о принципах, управляющих событиями в мире. Подобные убеждения, верования могут быть как сознательными, так и неосознанными. Исследования показали, что убеждения по-своему воздействуют на приведенную модель. На рис. 2.5 видно, что убеждения определяют, на что мы обращаем внимание, как мы интерпретируем свои ощущения (восприятие), какова наша мотивация (потребности), какие решения мы принимаем о своих действиях, нацеленных на получение вознаграждения и избавление от негативных подкреплений. Данное влияние по большей части человеком не осознается. Иными словами, мы видим то, во что верим.

Вознаграждение

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

Более того, как однозначно продемонстрировали многочисленные исследования человеческого поведения, поощрение вызывает у людей лишь стремление получить награду. Как правило, использование систем поощрений дает гораздо больше непреднамеренных нежелательных последствий, чем положительных результатов. Элфи Кон [20] объясняет причину этого, отмечая, что поощрение и наказание — две стороны одной медали, а именно — попытки внешнего контроля. Он приводит пять причин неэффективности прямых материальных поощрений:

1) вознаграждение наказывает;

2) вознаграждение портит отношения;

3) вознаграждение не учитывает причин (появления проблемы, за решение которой назначается поощрение);

4) вознаграждение отбивает желание рисковать;

5) вознаграждение убивает у человека интерес к заданию как таковому, и, следовательно, теряется внутренняя мотивация.

Все это давно известно ученым, но остается тайной для большинства современных руководителей. Фредерик Херцберг пишет [21]:

«Повышая зарплату, предоставляя дополнительные привилегии и знаки отличия, руководство тем самым не мотивирует персонал. Людьми скорее движет внутренняя потребность выполнить сложное задание. В таком случае задача менеджера — не пытаться мотивировать людей, чтобы заставить их что-то сделать, а вместо этого предоставить им возможность чего-то достигнуть самим — такая возможность сама по себе достаточно мотивирует».

Условием для использования ССРМ является создание системы, в которой предоставлялись бы подобные возможности. Серьезной помехой успеху при использовании основанного на установках жесткой предопределенности метода критического пути является то, что исполнители выигрывают или проигрывают в зависимости от своевременности выполнения своих заданий. При этом, однако, всем прекрасно известно, что оценки длительности операций в графике характеризуются значительной неопределенностью. Как показал Деминг в эксперименте с бусинами [7], успех или неудача работника определяются случайными флуктуациями. Такая система, определенно, не позволяет точно планировать сроки выполнения задания.

Дополнительные соображения по психологии

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

Убеждения управляют нашим вниманием и подстраивают восприятие действительности, выступая в роли информационного фильтра. У двух человек, наблюдающих за одним и тем же событием, могут сформироваться совершенно противоположные взгляды на то, что же на самом деле произошло. Я был поражен выступлениями конгрессменов от разных партий по поводу импичмента президента Клинтона. Представители обеих сторон очень эмоционально и логично излагали свои аргументы. Никто не утверждал, что придерживается той или иной точки зрения, поскольку это позиция его партии. Однако, когда настало время голосовать, из 417 человек лишь 5 изменили точку зрения. Хотя наверняка незначительное меньшинство участников решило голосовать просто как вся партия, все же выступающим удалось уверить меня, что они убеждены в справедливости приводимых ими доводов. Поскольку имелось всего две точки зрения и третьего было не дано, можно бы предположить, что аргументы, основанные на анализе фактов, должны были объединить людей в их мнении вне зависимости от политической принадлежности. Фильтр моего восприятия преподнес мне эту ситуацию как яркий пример того, что факты интерпретируются (представляются) так, чтобы складывалась картина реальности, соответствующая убеждениям человека. Участники дебатов были заложниками своих парадигм.

Люди, действующие в определенном окружении, подстраивают под него свое поведение. Иными словами, получаемая через оперантное обусловливание информация вызывает поведение, при котором в данном окружении будет больше позитивных и меньше негативных закреплений. Перемены в системе — угроза данному равновесию. Более того, как показывает Скиннер, на изменение поведения, сложившегося под влиянием оперантного обусловливания, может уйти очень много времени. Организм будет и дальше — иногда до тысячи раз — производить привычные действия, которые уже больше ничем не подкрепляются!

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

В РМВОК психология как область знаний отдельно не рассматривается. Однако тема поведения человека при реализации проектов там затрагивается неоднократно. Проектная система должна быть интегрирована с подсистемой, сформированной людьми. Интеграция происходит по законам поведения личности и групп. Поскольку при построении классической системы управления проектами это соображение не ставилось во главу угла, вполне естественно ожидать, что с интеграцией могут наблюдаться проблемы. В главе 3 показано, что основополагающий конфликт, ведущий к появлению всех нежелательных явлений (НЯ), наблюдающихся в имеющейся проектной системе, происходит из-за несоответствия между психологией личности и целью проектной системы.

2.5.4. ТЕОРИЯ ПОЗНАНИЯ

В своем эссе «Гипотетическое знание» (Conjectural Knowledge) Поппер [17] пишет:

«С рациональной точки зрения, нельзя полагаться ни на одну теорию, поскольку справедливость ни одной из них не была доказана и не может быть доказана».

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

«Иными словами, нет абсолютной истины, однако раз уж нужно выбирать, то лучше выбрать наиболее проверенную теорию. Это будет “разумным” в самом прямом из известных мне смыслов данного слова: наиболее проверенная теория — это такая, которая при критическом обсуждении представляется лучшей на данный момент, и я не знаю ничего более «разумного», чем правильно проведенное критическое обсуждение».

Он также дает объективное объяснение, почему новая теория будет предпочтительней имеющихся: «Хотя новая теория и объясняет все то же, что уже существующая, однако она корректирует старую, по сути, может, даже противоречит ей, но новая теория обычно в самом общем виде включает в себя старую».

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

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

Законы Ньютона работали лучше, чем все предшествующие теории, поскольку они пошли дальше простых наблюдений. Они дали возможность делать прогнозы за пределами видимого, что позволило отправить человека на Луну и послать корабль к Юпитеру. Это было бы невозможно, если использовать «доньютоновы» законы движения небесных тел.

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

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

2.6. Теория ограничений

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

Цель применения ТОС — совершенствование бизнес-систем. В работе «Что же это такое — теория ограничений» (What is This Thing Called Theory of Constraints) [22] Голдратт пишет: «Прежде чем приниматься за совершенствование какого бы то ни было элемента, необходимо определить общую цель системы, а также систему измерений, которые позволят оценить воздействие каждой подсистемы и каждого отдельного решения на эту цель».

В книге «Новая экономика» (New Economics) Деминг [13] отмечает: «Мы узнали, что оптимизация — это процесс настройки работы всех компонентов системы на достижение общей поставленной цели».

Наиболее часто в качестве наглядного примера при объяснении ТОС используется обычная цепь (рис. 2.8). Задача цепи — оставаться крепкой в состоянии напряжения. Всем понятно, что сила цепи определяется прочностью самого слабого звена. И ясно, что укрепление каких-либо иных звеньев никак не скажется на прочности цепи в целом.

Следующее положение ТОС не столь очевидно. Теория переходит к рассмотрению производственных цепей. Утверждается, что производительность любой цепи в каждый момент времени определяется лишь одним ограничением. Вероятно, это проще понять на примере проектов: так, в любом плане проекта есть лишь одна самая длинная цепочка работ (если не имеется других цепочек, абсолютно равных ей по протяженности). Как только вы приступаете к реализации проекта, эта одна цепочка будет настоящим ограничением. Ограничением (самой длинной цепочкой) может стать и любая другая последовательность работ — под действием изменений, происходящих при выполнении проекта. Однако в каждый момент только одна цепочка определяет длительность всего проекта.

Используя научный метод применительно к основам ТОС, можно получить множество производных принципов. В книге «Теория ограничений Голдратта: Системный подход к непрерывному совершенствованию» (Goldratt’s Theory of Constraints: Systems Approach to Continuous Improvement) Детмер [23] приводит следующий список:

1. При внедрении преобразований и разрешении конфликтов лучше полагаться на системное мышление, а не на аналитическое.

2. Эффективность оптимальных системных решений снижается со временем при изменении окружающих условий. Необходим процесс непрерывных улучшений для отслеживания актуальности и эффективности решения.

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

4. Системы подобны цепям. В каждой системе есть самое слабое звено (ограничение), которое в конечном счете снижает результативность всей системы.

5. Укрепление любого неограничивающего элемента не делает цепь более прочной.

6. Для проведения обдуманных, разумных преобразований необходимо понимать текущее состояние системы, ее цели и характер существующих проблем.

7. Большинство нежелательных явлений в системе вызваны несколькими ключевыми проблемами.

8. Ключевые проблемы почти всегда неявные. Они заявляют о себе рядом нежелательных явлений, связанных причинно-следственными отношениями.

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

10. Ключевые проблемы обычно усугубляются лежащим в их основе скрытым конфликтом. Для решения проблемы нужно выявить основные исходные установки конфликта и избавиться хотя бы от одной из них.

11. Ограничения системы могут быть как физическими, так и организационными. Физические ограничения сравнительно просто выявлять и ликвидировать. Организационные ограничения обычно сложнее обнаружить и снять, но их нейтрализация, как правило, влечет за собой более существенные и важные изменения, чем удаление физических ограничений системы.

12. Инерционность — худший враг процесса непрерывных улучшений. Былые решения постепенно приобретают вес и значимость, обрастают массой вспомогательных деталей, что препятствует дальнейшим преобразованиям.

13. Идеи — это не решения.

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

Понятие ключевого конфликта, лежащего в основе многих нежелательных явлений системы, вероятно, связано с мыслью о том, что ради избавления от НЯ люди изменили бы систему, если бы знали, как именно, и были бы в состоянии проводить преобразования. Если нежелательное явление не исчезает, значит, что-то мешает создателям или руководителям системы ее изменить. Идея ключевого конфликта помогает понять, что именно им мешает.

Для установления логической связи между нежелательными явлениями и ключевым конфликтом ТОС предлагает такой инструмент, как дерево текущей реальности (ДТР).

По причинам, которые будут изложены позже, я рекомендую при создании и анализе ДТР рассматривать его под максимально широким углом зрения. Представление организации как системы, регулярный пересмотр работы основных компонентов системы позволит уменьшить расхождения между реальной ситуацией и представлениями о ней. При наличии процесса организационного развития управленческая команда предприятия может использовать выявленные несоответствия для оптимизации системы.

2.6.1. УПРАВЛЕНЧЕСКИЙ УЧЕТ ПО ТОС

Голдратт установил, что в большинстве случаев системное ограничение имеет организационную, а не физическую природу. В романе «Цель» (The Goal) [24] он показывает, что организационные ограничения связаны с некорректной системой бухгалтерского учета. Используемые ныне системы бухучета сложились еще на заре прошлого века и с тех пор очень мало менялись (дважды за время существования управления проектами). Основывались они тогда на определенных — не актуальных более — предположениях о построении коммерческих предприятий.

Старый способ ведения бухгалтерии Голдратт назвал «учет по затратам», поскольку его исходные установки гласят, что определение затрат на продукт — это первоочередной способ прикинуть его ценность и принять бизнес-решение. Поэтому необходимо распределять затраты между различными видами продукции, для чего следует разрабатывать схемы себестоимости по продуктам, например, методом «учета затрат по видам деятельности» (activity based costing). Все подобные схемы основаны на не вполне верных установках и зачастую ведут к ошибочным представлениям и решениям.

Голдратт предложил новый метод — управленческий учет по ТОС. Он базируется на трех понятиях:

1. Производительность по денежному потоку (Throughput, T) — деньги, которые вы получаете от продажи своей продукции (доход за минусом затрат на сырье).

2. Вложения (Inventory, I) — деньги, которые вы вложили в систему в виде фиксированных активов, чтобы обеспечить получение Т (главное отличие от классического учета в том, что здесь приравниваются основные средства и продукция, находящаяся в процессе обработки).

3. Операционные расходы (Operating Expense, OE) — деньги, которые вы тратите, чтобы получить Т.

Крупнейшие авторитеты в сфере бухучета признали этот метод, однако он очень медленно набирает популярность.

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

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

Учет по ТОС эти ошибки исправляет и учит принимать решения, ориентируясь на цель компании (делать деньги сейчас и в будущем). Все решения и измерения должны соотноситься с общей целью. При этом часто принимаются совсем иные решения, чем при использовании классического учета затрат.

Например, при классическом учете руководство измеряет производительность отдельных производственных участков. Финансисты считают товарно-материальные запасы активами компании. И если не нужно изготавливать продукцию для клиента, она будет делаться на склад, чтобы увеличивалась производительность и у руководства складывалось благоприятное впечатление от конкретного участка. Но, к сожалению, лежа на складе, продукция не приносит заводу прибыль. При этом деньги на нее затрачены (сырье, хранение), поэтому портится картина движения денежных средств и снижается объем средств, доступных к использованию. При такой системе учета товарно-материальные запасы рассматриваются как явление положительное (активы), однако для бизнеса ничего положительного в них нет. Смотрим дальше. Когда вам наконец удастся реализовать запасы продукции (это хорошо), объем активов снизится (а это уже выглядит плохо). И если вы в состоянии объяснить, какой глубокий смысл стоит за всем этим, будьте добры, напишите мне!

С другой стороны, что считается главным конкурентным преимуществом в сферах, связанных с мыслительным трудом? Люди. А что представляют собой люди с точки зрения бухучета? Затраты, а затраты — это плохо. Это первое, от чего хочется избавиться, когда дела идут неважно: сохранить активы, снизить расходы. Отказаться от возможности делать деньги сейчас и в будущем и оставить себе железки, стоящие денег.

Голдратт предлагает эффективный способ разобраться с дилеммой, встающей перед управленцами, а именно — один из методов логического рассуждения по ТОС, диаграмму разрешения конфликтов «грозовая туча». На рис. 2.9 представлена диаграмма конфликта между классическим учетом и учетом по ТОС. Блок А представляет цель, общую для всех управленцев. Блоки В и С — условия, необходимые для достижения данной цели. Читаем диаграмму так: «Чтобы управлять эффективно, менеджеры должны контролировать расходы». Нижняя ветвь звучит следующим образом: «Чтобы управлять эффективно, нужно обеспечивать должный уровень производительности по денежному потоку Т». Пока все выглядит логично.

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

Важнейшим следствием мышления в терминах учета по ТОС является то, что главное внимание сосредотачивается на производительности по денежному потоку, а это самый предпочтительный путь к совершенствованию системы. Если посмотреть, как Т, I и ОЕ влияют на чистую прибыль и окупаемость инвестиций, сразу становится очевидно, что Т — самый важный показатель. Совершенствовать его можно бесконечно, в то время как возможности улучшения в I и ОЕ являются ограниченными.

Мышление же в рамках учета затрат дает фрагментарное видение производственной системы. Затраты высчитываются путем алгебраического сложения. Классический учет фокусируется на ОЕ. Операционные расходы по каждой части системы можно снизить и суммировать сэкономленные средства. Отсюда в нашей диаграмме появляется блок D: «Чтобы контролировать затраты, менеджеры вынуждены придерживаться правил классического учета затрат». Почему же все дружно не перейдут на учет по ТОС? Все дело в инерции. В главе 3 объясняется важность мышления по ТОС и использования управленческого учета по ТОС в отношении к управлению проектами.

2.6.2. ПРОИЗВОДСТВЕННОЕ РЕШЕНИЕ

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

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

Барабан — способность ограничивающего элемента системы задавать производственный ритм. Эта способность напрямую влияет на общий показатель Т процесса производства. Как мы помним, Т — это разница между доходом с продаж и затратами на сырье. Для максимального использования ограничения с точки зрения его влияния на Т нужно подавать в систему определенную нагрузку в определенное время, чтобы и не перегружать ограничивающий элемент, и не давать ему простаивать. При перегрузке ограничения (то есть подаче на него больше материала, чем оно может обработать) образуются излишки запасов (скопление заготовок перед ограничением).

Веревка передает информацию от барабана к подающему звену, чтобы ограничение не простаивало и чтобы перед ним не скапливались залежи материала.

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

Рис. 2.10 показывает производственную систему. Сравните его с изображением 2.4, обратите внимание, что здесь показаны внутренние процессы бизнес-системы, как она была представлена Демингом. Производство — это подсистема общей бизнес-системы, так же как сердечнососудистая система является подсистемой человеческого организма.

Хотя местом действия в «Цели» Голдратт сделал завод по производству оборудования, суть, изложенная на рисунках 2.4 и 2.10, справедлива для любой системы. Выходом системы является все, что она производит и отправляет вовне. Это могут быть результаты научных исследований, различные виды услуг, совещания, организация поездок, отчеты, юридические консультации, программное обеспечение и иная продукция коммерческих и некоммерческих организаций. К упомянутым системам относится и правительство. У правительственных и некоммерческих учреждений цель, конечно же, не та, что у коммерческих.

Рис. 2.4 и 2.10 дают статичное изображение производственной системы. Система не меняется. Исходные компоненты (входы) движутся по системе и преобразуются в результат (выход). Однако поток компонентов через систему не является неизменным. Каждый этап может быть в той или иной степени подвержен изменчивости, о которой часто говорят как о статистических колебаниях. Поскольку последующим этапам требуется подача материалов с предыдущих этапов, эти последующие оказываются зависимыми от предыдущих. Комбинация зависимых событий и статистических колебаний — важный момент, который нужно учитывать при управлении системой в целом и особенно в той точке, где находится ограничение.

Если система построена так, что этапы, идущие перед ограничением, равны ему по мощности, то на самом деле они не будут подавать на ограничение необходимое количество материалов. Дело в том, что на этапах, предшествующих ограничению, в игру вступят статистические колебания, и поэтому ограничению регулярно будет не хватать сырья. И на участке, являющемся ограничением, эту нехватку восполнить будет никак нельзя, на то оно и ограничение. Следовательно, чтобы система в целом работала оптимальным образом, предшествующие ограничению этапы должны иметь мощность с запасом.

То же самое относится ко всем последующим этапам — и они должны превосходить ограничение по мощности. Иначе невозможно будет компенсировать колебания, связанные с вариабельностью в работе ограничения. Большую часть времени участки, следующие за ограничением («барабаном» системы), будут работать в ритме ограничения, однако наличие запаса по мощности позволит в случае необходимости наверстать упущенное. А это означает, что на производстве все участки, не являющиеся «узкими местами», какой-то период времени будут простаивать.

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

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

Программные продукты, которые Голдратт продавал до изобретения ТОС, как и все другие системы управления производством, не учитывали влияния на систему совокупности таких факторов, как ограничение, статистические колебания и зависимость производственных участков друг от друга. Каждый конкретный случай проявления статистического колебания невозможно просчитать заранее, слишком много факторов придется учесть. На практике можно только спрогнозировать общую картину на некоторый период времени для большого количества сырья и материалов, проходящих через систему. Следовательно, графики, предлагаемые компьютерными программами, на момент появления были уже неточны и неактуальны. Неудивительно, что они не способствовали увеличению прибыли. Как неудивительно и то, что излишняя детализация проектного плана вовсе делает проект более успешным.

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

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

• запуск новых проектов в организации на основании способности главного ограниченного ресурса справиться с возлагаемой нагрузкой;

• запуск отдельных задач по проекту на основании информации из отчетов по основному буферу проекта;

• принятые в рамках управления буфером решения о времени внесения изменений в процесс (пополнение буфера).

Многие с трудом могут представить себе, как применять ТОС в своей работе. Роман «Цель» демонстрирует, как использовать ТОС в производственных системах, но некоторые люди не видят, как же приложить теорию к их бизнесу, например, в сфере услуг, в компании, занимающейся научно-исследовательскими разработками, в некоммерческих и правительственных организациях. Недавно менеджер среднего звена компании, которую я консультирую, заявил: «У нас все намного сложнее. ССРМ обречена тут на провал, ведь работа у нас необычайно сложная». При этом у меня есть другие клиенты, успешно использующие ССРМ в организациях, которые в 40 раз крупнее, и на проектах, которые в сотни раз сложнее. Нет смысла проводить какие-либо различия по типу бизнеса. Теория применима к любой бизнес-системе и до сих пор срабатывала на любом проекте, где ее использовали, а использовали ее уже на очень широком спектре проектов. Наиболее заметные улучшения бывают на проектах, где царит большая неопределенность, но ведь в любой организации есть проекты, характеризующиеся неопределенностью в той или иной степени. В романе «Дело не в везенье» (It’s Not Luck) показано, как ТОС работает применительно к маркетингу, построению карьеры, решению личных проблем в семье.

Как показывает опыт, даже в производственных системах ограничение носит не столько физический, сколько организационный характер. В «Цели» оно крылось в финансовых процедурах и политике продаж.

Представим себе фирму, оказывающую услуги колл-центра. Самый распространенный показатель, которым измеряется эффективность подобных услуг, — это количество звонков, которое оператор обрабатывает за час. Но цель системы связана не с объемом принятых звонков, а с каким-то результатом от разговора (например, удовлетворенность клиентов или принятые заказы). Длительность звонков может колебаться, и частота их — тоже величина случайная. Допустим, вы — клиент и хотите сделать по телефону большой заказ из множества позиций. Как быть оператору? Выслушать вас полностью и ухудшить тем самым себе показатель по количеству принятых за час звонков? И как долго вы согласны ждать на линии, пока не решите обратиться в другую фирму?

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

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

2.6.3. ПЯТЬ НАПРАВЛЯЮЩИХ ШАГОВ ТОС

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

2.6.3.1. Найти ограничение системы

Чтобы улучшить работу системы по достижению цели, необходимо определить, что же системе мешает. Следует понять, «что изменять». Ограничение системы подобно самому слабому звену цепи: что бы мы ни предпринимали для укрепления остальных звеньев, цепь не станет крепче,

пока не усилить ее слабое звено. Разумеется, чтобы укрепить, надо его сначала найти.

В случае с системой управления проектом слабое звено может оказаться где угодно: в процессе управления, в процедурах компании, в цепочках поставок, в рабочих инструкциях, в системе оценок или в схеме коммуникации. Поскольку проект не является чем-то осязаемым, пока не будет уже в значительной степени реализован, ограничение зачастую в глаза не бросается. Теория систем показывает, как и почему явления могут наблюдаться намного позже вызвавших их событий. (Вспомните законы пятой дисциплины.) Вы наверняка помните, что следствие в цепочке «следствие — причина — следствие» в пространстве может наблюдаться совсем не рядом с причиной. Следовательно, изучение причин неудачной реализации проекта не всегда позволяет установить источник проблем.

ТОС определяет ограничение непроизводственных систем как ключевой конфликт. Как и любое ограничение, ключевой конфликт в системе — первопричина, мешающая организации работать лучше. Это истинная причина одного или более нежелательных явлений (НЯ), наблюдаемых в системе. Чтобы избавиться от НЯ, нужно сначала диагностировать ключевой конфликт.

2.6.3.2. Найти способ ослабить влияние ограничения

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

В непроизводственных системах необходимо определить, как сгладить ключевой конфликт, и удостовериться, что объект для изменений выбран правильно и причинно-следственные связи, вызванные преобразованиями, приведут к желаемым результатам (ЖР).

На этом этапе вы определяете, «на что изменять».

2.6.3.3. Подчинить всю работу нуждам ограничения

Это ключ к верному направлению усилий. Выполняя эту рекомендацию, вы можете обнаружить множество организационных установок, препятствующих правильному ходу вещей. Так, герой романа «Цель» Алекс Рого видит, что ограничение — в системе измерений (показатель «производительность») и, если продолжать ее придерживаться, это не позволит ему действовать должным образом. Бухгалтерия расценивала запасы готовой продукции в качестве актива, поэтому наличие таких запасов обеспечивало хорошие цифры в отчетах. На самом же деле на изготовление и хранение продукции тратятся деньги, при этом ограничение оказывается загружено, и производство заказов для клиента, которые приносят деньги, происходит с задержкой. Аналогично оценка по показателю «производительность» вынуждает рабочих изготавливать детали вовсе не для той продукции, которая идет на продажу, при этом компания несет расходы на эти детали, а ограничение, вероятнее всего, опять-таки оказывается занятым и не может участвовать в производстве изделий, нужных клиентам и способных принести быструю прибыль.

Раз управление проектами за 40 лет существования практически не претерпело изменений, не кажется ли вам, что, скорее всего, в основе его лежат некие установки, политики и искусственные ограничения, которые давно уже утратили актуальность? Возможно ли, что некоторые показатели, используемые при управлении проектом, на самом деле не способствуют достижению его целей?

Этот шаг — первый этап в поиске ответа на вопрос «Как осуществить изменения?».

2.6.3.4. Снять ограничение системы

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

Иногда естественная защитная реакция не дает нам даже помыслить о каких бы то ни было переменах. Поэтому внедрять что-либо новое всегда очень сложно.

2.6.3.5. Если на предыдущих этапах ограничение было снято, возвращайтесь к шагу 1

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

Далее следует предостережение: не позволяйте инерционности управленческого мышления становиться ограничением системы.

2.6.4. ПРОЦЕСС ЛОГИЧЕСКИХ РАССУЖДЕНИЙ ПО ТОС

На рис. 2.12 представлена общая схема процесса и основных методов логических рассуждений по ТОС. Голдратт выстроил процесс таким образом, чтобы он давал ответы на три вопроса:

1. Что менять?

2. На что менять?

3. Как осуществить изменения?

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

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

Многих сперва пугает инструментарий логических рассуждений ТОС и соответствующие сокращения. Большинству требуется две-три недели усиленного обучения и тренировок, чтобы начать использовать инструменты ТОС самостоятельно, и годы практического опыта, чтобы достичь настоящего мастерства в этом деле. Как отмечают Эрик Норин, Дебра Смит и Джеймс Макей [26], даже после подобного обучения лишь ограниченное число людей способно вырабатывать серьезные решения. (Исследование было опубликовано довольно давно, процесс обучения и сами инструменты с тех пор претерпели некоторые изменения. Более свежих данных у меня нет, однако по личным наблюдениям могу сказать, что сделанные выводы до сих пор актуальны.)

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

Дерево текущей реальности

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

Диаграмма разрешения конфликтов «грозовая туча»

Диаграмма «грозовая туча» в совокупности с правилами ее преподнесения и использования помогает найти и реализовать решение конфликта или дилеммы. Это построение жестко заданной горизонтальной формы показывает необходимые условия перехода от одного логического утверждения к другому. Диаграмма читается слева направо с использованием формулировок, передающих эту логику: «Чтобы наступило событие х, нужно, чтобы соблюдалось условие у».

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

На рис. 2.13 представлен общий вид диаграммы «грозовая туча», состоящей из убеждений и действий. (Я пришел к выводу, что это основной вид представления данной логической схемы.) Диаграмма отображает две точки зрения на реальность, или два аргумента (в смысле — логических). Представим себе блоки D и D' как два противоположных представления о способе достижения цели. Аргумент первый гласит: «Чтобы получить А, надо иметь В. Чтобы получить В, надо иметь D». Второй аргумент выглядит так: «Чтобы получить А, надо иметь С. Чтобы получить С, надо иметь D'». Таким образом, мы видим два логических способа достижения одной и той же цели. Убеждения могут и не противоречить друг другу, но действия являются совершенно противоположными. Иначе и конфликта бы не возникло.

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

Дерево будущей реальности

Дерево будущей реальности (ДБР) показывает желаемое состояние вашей системы, то есть отвечает на вопрос «на что менять». В этой системе все НЯ превращаются в свою противоположность — желаемые результаты (ЖР).

ДБР определяет те изменения, которые необходимо произвести в текущей реальности, чтобы появились ЖР, и показывает причинно-следственные связи, соединяющие эти изменения и желаемые результаты. Также выявляется информация, необходимая для поддержания ДБР в актуальном состоянии после «прорыва» — внедрения запланированных изменений. Следует проанализировать ДБР вместе с заказчиками системы. Диаграмма читается снизу вверх при помощи утверждений вида «если... то».

Ветвь негативного развития событий

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

Дерево перехода

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

План преобразований

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

2.7. Управление изменениями

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

Л. Браксик [27] предлагает научно обоснованный подход, действенный в бизнес-среде. Ее идея основана на простейшей модели оперантного обусловливания «опыт — поведение — последствия» (antecedent-behavior-consequence, ABC) и имеет нечто общее с методом анализа и совершенствования процессов в шести сигмах.

Д. Коттер [28] описывает организационный подход к управлению изменениями, успешно используемый многими специалистами по ТОС. В модели Коттера имеется восемь шагов:

1. Создайте ощущение необходимости перемен.

2. Сформируйте мощную руководящую коалицию.

3. Сформулируйте видение будущих перспектив.

4. Расскажите о своем видении.

5. Дайте возможность другим действовать в соответствии с видением.

6. Спланируйте и реализуйте то, чего можно добиться быстро.

7. Углубляя преобразования, концентрируйте улучшения.

8. Закрепите новые подходы.

Я установил, что метод этот весьма удобен при планировании перехода на ССРМ, но должен вас предупредить, что в реальности носителем сопротивления переменам всегда выступает конкретный живой человек. Нужно быть готовым бороться с этой проблемой в рамках межличностного общения. И для этого подход Браксик представляется наиболее подходящим из всех, мне известных.

Голдратт предложил концепцию «рубежей сопротивления», применяемую многими пользователями ТОС. И хотя модель эта — очень привлекательный объект для размышлений, я не считаю ее приемлемой для внедрения изменений. Судя по моему опыту, в рамках организации действует модель Коттера, а на уровне личности — подход Браксик, и в совокупности они составляют более эффективный метод, нацеленный на действие. В главе 9 описаны принципы внедрения метода ССРМ на основе данных методик.

2.8. Большой синтез

Любая управленческая теория достаточно сложна, если углубляться в детали, однако можно выделить два основных момента в наших предыдущих рассуждениях. Во-первых, ТОС — это стратегия и инструмент, помогающий направить действие любого управленческого приема на ограничение системы. Легко увидеть, что успех или поражение компании в применении TQM, шести сигм, бережливого производства зависит от того, нацелены усилия на ограничение или нет. Концентрируясь на чем угодно, кроме ограничения, вы затратите те же ресурсы, но не получите практически никакого результата. Уверен, что в этом заключается главное различие между теми, кто добивается и кто не добивается успеха в использовании новых управленческих методик. Я считаю, что просто одним повезло наткнуться на ограничение, а другим — нет. По той же причине не думаю, что существуют какие-либо критические доводы или весомые данные в поддержку мыслей, изложенных в главе 3 книги авторов П. Панде, Р. Ньюман и Р. Каванаг [10] «Почему шесть сигм работают там, где не сработало TQM?» (Why Is Six Sigma Succeeding Where Total Quality Failed?). Обе концепции работают, если направлены на ограничение. Вторым слагаемым успеха является грамотно построенное управление изменениями. Многие организации, применяя ТОС, также не достигли больших успехов и/или через пару лет вновь потеряли завоеванные высоты именно из-за отсутствия этой второй составляющей.

Во-вторых, любую управленческую теорию можно рассматривать через призму системы глубинных знаний Деминга.

2.9. Итоги

В данной главе показано, как совместное использование четырех управленческих концепций помогает совершенствовать систему управления проектами в целом. Эти концепции значительно пересекаются между собой, и в них практически нет расхождений по основополагающим принципам и ценностным установкам. Надеюсь, прочитав вторую главу, вы тоже теперь видите, что:

• РМВОК дает полное описание проектной системы (существующей теории);

• принципы и приемы ТОС позволяют усовершенствовать теорию;

• концепции бережливого производства и шести сигм подсказывают, как лучше приложить ТОС к положениям РМВОК ;

• бережливое производство, шесть сигм и ТОС используют принципы системы глубинных знаний Деминга: понимание системы, вариабельности, теории познания и психологии;

• в РМВОК и большей части специализированной литературы не делается различий между общими и особыми причинами вариаций. Поскольку производственная и проектная системы похожи (глава

1) и поскольку ТОС позволяет значительно улучшить работу производственных систем, то в применении к проектам ТОС также может помочь избавиться от существующих нежелательных явлений;

• ТОС предлагает логический процесс совершенствования систем путем определения «что менять», «на что менять», «как осуществить перемены»;

• пять направляющих шагов ТОС описывают этапы реализации процесса совершенствования: найти ограничение, максимально использовать мощность ограничения, подчинить всю работу нуждам и ритмам ограничения, снять ограничение, не позволять инерции вставать на пути дальнейших преобразований;

• чтобы совершенствовать проектную систему, необходимо сначала найти ограничение (ключевой конфликт), лежащее в основе НЯ существующей проектной системы (или существующей теории); ключевой конфликт покажет, что нужно менять;

• процесс логических рассуждений по ТОС позволяет сконструировать новую систему, то есть показывает «на что менять»;

• методики управления изменениями необходимы, чтобы вызвать перемены в привычном поведении, без которых не достичь всего, что может дать ССРМ.

В главе 1 была сформулирована проблема, а в главе 2 дан обзор теоретической базы, теперь мы подошли к этапу разработки улучшенной теории планирования и управления проектами. ТОС содержит стратегию использования приемов бережливого производства и шести сигм в этих целях.

ЛИТЕРАТУРА

1. PMI, A Guide to the Project Management Body of Knowledge, Newton Square, PA: PMI, 2000 (в русском переводе: Руководство к своду знаний по управлению проектами/Под. ред. В. Либерзона, Д. Лобанова. — М.: Институт управления проектами, 2004. — редакция 2000 года; Руководство к своду знаний по управлению проектами. — Project Management Institute, 2004. — редакция 2004 года).

2. PMI, Organizational Project Management Maturity Model Knowledge Foundation, Newton Square, PA: PMI, 2003.

3. Carnegie Mellon University, The Capability Maturity Model: Guidelines for Improving the Software Process, Reading, MA: Addison-Wesley, 1994.

4. Womack, J., D.Jones, and D.Roos, The Machine That Changed the World: The Story of Lean Production, New York; HarperCollins Publishers, 1990 (в русском переводе: Вумек Д., Джонс Д., Рус Д. Машина, которая изменила мир. — М.: Попурри, 2007).

5. Womack J., and D.Jones, Lean Thinking: Banish Waste and Create Wealth in Your Corporation, New York: Simon & Shuster, 1996 (в русском переводе: Вумек Д., Джонс Д. Бережливое производство. Как избавиться от потерь и добиться процветания вашей компании. — М.: Альпина Бизнес Букс, 2004).

6. Dettmer, W., Beyond Lean Manufacturing: Combining Lean and the Theory of Constraints for Higher Performance, 2000, доступна по адресу http://www.goalsys. com/HTMLobj-786/TOC_and_Lean_Paper Dettmer-rev_.pdf (материал для книги взят 30 апреля 2004 г.).

7. Wikipedia, “Agile software development”, доступна по адресу http://en.wikipedia. org/wiki/Agile_Methods (материал для книги взят 21 июня 2004 года).

8. Anderson, David J., Agile Management for Software Engineering, Upper Saddle River, NJ: Prentice Hall, 2003.

9. NIST, Baldrige, Six Sigma, & ISO: Understanding Your Options, 2002, доступна на http://www.quality.nist.gov/PDF_files/Issue_Sheet_SS.pdf (материал для книги взят 30 апреля 2004 года).

10. Pande, P., R.Neuman, and R. Cavanagh, The Six Sigma Way: How GE, Motorola, and Other Top Companies Are Honing Their Performance, New York: McGraw-Hill, 2000.

11. Hendricks, Kevin B., and Vonid R. Singhal, “Don’t Count TQM Out. Evidence Shows Implementation Pays Off in a Big Way”, Quality Progress, April 1999.

12. Deming, W.Edwards, Out of the Crisis, Cambridge, MA: MIT Press, 1982 (в русском переводе: Деминг Э. Выход из кризиса. Новая парадигма управления людьми, системами и процессами. — М.: Альпина Бизнес Букс, 2007).

13. Deming, W. Edwards, The New Economics, Cambridge, MA: MIT Press, 1993 (в русском переводе: Деминг У. Эдвардс. Новая экономика. — М.: Эксмо, 2006).

14. Senge, Peter, The Fifth Discipline, New York: Doubleday, 1990 (в русском переводе: Сенге П. Пятая дисциплина. Искусство и практика самообучающейся организации. — М.: Олимп-Бизнес, 2003).

15. Brooks, Frederick P., The Mythical Man Month: Essays on Software Engineering, Reading, MA: Adison-Wesley, 1995 (в русском переводе: Брукс Ф. Мифический человеко-месяц, или Как создаются программные системы. — Спб.: Символ-Плюс, 2006).

16. Hardin, Garret, Filters against Folly, New York: Viking, 1985.

17. Popper, Karl R., Objective Knowledge, An Evolutionary Approach, Oxford: Clarendon Press, 1979 (в русском переводе: Поппер К.Р. Объективное знание. Эволюционный подход. — М.: Эдиториал УРСС, 2002).

18. Shewhart, Walter A., Statistical Method, New York: Dover, 1986.

19. Skinner, B.F., Science and Human Behavior, London: The Free Press, Collier Macmillan, 1953.

20. Kohn, Alfie, Punished by Rewards, Boston: Houghton Mifflin, 1993.

21. Herzberg, Frederick, Work and the Nature of Man, Cleveland, OH: World Publishing, 1966.

22. Goldratt, Eliyahu M., Theory of Constraints, Croton-on-Hudson, NY: North River Press, 1990.

23. Dettmer, H. William, Eliyahu M. Goldratt’s Theory of Constraints, A Systems Approach to Continuous Improvement, Milwaukee, Wisconsin: ASQC Press, 1997 (в русском переводе: Детмер У. Теория ограничений Голдратта: Системный подход к непрерывному совершенствованию. — М.: Альпина Бизнес Букс, 2007).

24. Goldratt, Eliyahu M., The Goal, Great Barrington, MA: North River Press, 1984 (в русском переводе: Голдратт Э. М., Кокс Д. Цель. Процесс непрерывного совершенствования. — М.: Попурри, 2007).

25. Goldratt, Eliyahu M., It’s not Luck, Great Barrington, MA: North River Press, 1994 (в русском переводе: Голдратт Э. М., Кокс Д. Цель. Процесс непрерывного улучшения. Цель-2. Дело не в везенье. — Киев—Москва: Максимум, Логос, 2007).

26. Noreen, Eric, Debra Smith, and James T. Mackey, The Theory of Constraints and Its Implications for Management Accounting, Great Barrington, MA: North River Press, 1995.

27. Braksick, L. Unlock Behavior, Unleash Profits, New York: McGraw-Hill, 2000.

28. Kotter, J. “Leading Change: Why Transformation Efforts Fail.” In Harvard Business Review on Change, Boston, MA: Harvard Business Review Publishing, 1998, рр. 1-20 (в русском переводе: Коттер Д. П. Впереди перемен. — М.: Олимп-Бизнес, 2007).

Глава 3. Выбираем подход к решению

3.1. Решаем, что менять

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

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

И теперь, став свидетелем использования ССРМ во множестве организаций, могу объяснить, как это работает.

3.1.1. ОПРЕДЕЛЯЕМ СИСТЕМУ УПРАВЛЕНИЯ ПРОЕКТОМ

Цель системы управления проектом заключается в том, чтобы обеспечить достижение результатов, удовлетворяющих всех участников проекта. Для этого необходимо выполнить проектное задание (обещанный объем работ) в оговоренный срок или досрочно при заранее определенном или меньшем уровне затрат. Схематичное изображение проектной системы как «черного ящика» на рис. 3.1 показывает цель, входы и выходы и подсказывает, какие необходимы измерения для контроля за системой на пути к достижению цели.

3.1.2. ПРОВАЛ ПРОЕКТА КАК НЕЖЕЛАТЕЛЬНОЕ ЯВЛЕНИЕ

Чтобы улучшить систему управления проектом, согласно теории познания, необходимо определиться с проблемами, которые заложены в существующей системе. Сравнение прогнозов, сделанных с помощью существующей проектной системы (теории), с реальностью помогает установить такие проблемы. Наблюдая возникающие при работе системы нежелательные явления (НЯ), мы естественным образом сможем определить существующие в системе проблемы и понять, каких желаемых результатов (ЖР) нам необходимо добиться, чтобы говорить об улучшении проектной системы как таковой. В главе 1 были определены следующие НЯ:

1. Проекты часто идут с нарушением графика.

2. Проекты часто идут с превышением бюджета.

3. Чтобы уложиться в срок и в бюджет, часто приходится жертвовать содержанием проекта.

4. В проектах происходит слишком много изменений.

5. В компаниях, где одновременно реализуется множество проектов, часто идет борьба за ресурсы.

6. Длительность проектов все растет.

7. Многие проекты останавливаются, не дойдя до цели.

8. Проектные работы оказывают серьезное давление на большинство участников.

Нежелательные явления — это то, что нам не нравится в существующей системе. Хороший способ проверить, что перед нами действительно НЯ, — сформулировать предложение типа «Меня действительно беспокоит то, что.». Ваш список НЯ может включать в себя какие-то иные пункты, чем вышеперечисленные. Если нужно, дополняйте или сокращайте приведенный перечень.

ТОС помогает нам понять, что все эти явления — непосредственный продукт работы проектной системы, в которой мы в данный момент находимся. Хотя это и не преднамеренные результаты, их стабильное присутствие свидетельствует о том, что они — прямое следствие действия системы. Значит, где-то в системе есть нечто, вызывающее появление этих НЯ. Ввиду того, что нежелательные явления наблюдаются в любых типах проектов во всех сферах бизнеса и в разных видах культур, мы можем сделать вывод, что тип проекта, бизнеса и культуры не является первоочередным фактором или воздействием, вызывающим появление таких результатов. ТОС подводит нас к мысли, что НЯ — это следствие некоего глубинного конфликта или дилеммы, универсальных для любого окружения. Чтобы определить, что менять, необходимо выявить эту дилемму — ограничение существующей системы.

3.2. Определяем ограничение

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

В большинстве реализуемых сегодня проектов используется метод критического пути СРМ, разработанный в начале 1950-х и являющийся «гвоздем» большинства учебных программ по управлению проектами. (Я знаю, о чем говорю. Сам веду некоторые из них в Университете Феникса). Он же описан и во всех работах по управлению проектами. На рис. 3.2 показан типичный график, построенный методом критического пути. Самый длинный путь в диаграмме — критический путь.

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

Анализ проекта на рис. 3.2 позволяет прикинуть, сколько времени он на самом деле займет. Рассмотрим работу исполнителя 1 (операции 1, 3 и 5). Начало всех этих операций запланировано на одну и ту же дату, значит, каждая операция будет длится втрое дольше, поскольку все они должны выполняться одновременно. Таким образом, самая короткая операция 1 длительностью 5 дней завершится через 15 дней, а задания 3 и 5 будут выполнены на этот момент настолько, сколько можно сделать за 5 дней. Теперь исполнитель 1 должен будет распределять время между двумя оставшимися операциями, при этом из 2 дней работы по проекту на каждую будет уходить по 1 дню. Следовательно, оставшиеся 20 дней операции 3 выльются на деле в 40 дней и общая ее продолжительность составит 55 дней. Через 55 дней по заданию 5 еще останется сделать работы на 25 дней, и длительность ее в совокупности окажется 80 дней.

Расчет по исполнителю 2 более сложен ввиду взаимосвязанности операций. На 15-й день исполнитель 2 может начать работу по заданию 2 и посвящать ему 100% времени. Он не сможет приступить к операции 4, пока исполнитель 1 не завершит задание 3 (то есть не раньше дня 55). Таким образом, исполнитель 2 может полностью заниматься операцией 2 в течение 40 дней, однако последние 5 дней уже придется выполнять и задание 4, поэтому общая длительность операции 2 вырастет до 50 дней. Операция 4 теперь пересекается с задачами 2 и 6 и вырастает до 40 дней. На рис. 3.3 представлена схема ожидаемой фактической реализации проекта с датой окончания, сдвинувшейся более чем на месяц. Проект был обречен.

Существует метод решения данной проблемы — это выравнивание ресурсов. Большинство программных продуктов, основанных на методе СРМ, предлагают такую возможность. Рис. 3.4 — вариант графика с рисунка 3.1, к которому было применено выравнивание ресурсов. Обратите внимание: дата завершения плана-графика с выравненными ресурсами совпадает с датой, полученной на графике фактической реализации. Этот метод также устраняет первое нежелательное явление — частое нарушение графика. Еще бы, ведь для этого он и создан!

Рассматривая рис. 3.2 и 3.4, можно сделать интересное наблюдение. Компьютерная программа включила в критический путь только операции 5 и 6. Странно, что в критический путь не попали операции, идущие перед ними. Почему программа выбрала именно эти операции, для меня загадка. И я знаю, что после выравнивания ресурсов при помощи другой программы получится совсем иной критический путь, пусть даже выравнивание будет произведено одинаковым образом. Причина в том, что критический путь не определяется после выравнивания. До выравнивания в него не включен временной резерв («float», он же «slack»). Обратите внимание, что на рис. 3.2 у обоих некритических путей (операции 1 и 2 и операции 3 и 4) есть такой резерв, отмеченный чертой, продолжающейся справа от операции. После выравнивания ресурсов (рис. 3.4) резерв есть по всем операциям. Таким образом, ни одна из них не составляет критический путь.

На своих занятиях в PMI я устраиваю неофициальное исследование. Я спрашиваю, сколько студентов в планах своих проектов указывают загрузку по ресурсам (то есть обозначают, какие ресурсы назначены на выполнение каких операций, как на рис. 3.2). Обычно это от половины до двух третей слушателей. Затем я спрашиваю, кто из них проводит выравнивание ресурсов. Обычно таковых около 5%. Получается, что примерно 95% проектов уже с самого начала обречены на провал. Не забывайте, что я опрашивал элиту управления проектами, большинство из них — сертифицированные профессионалы РМР.

Тем, кто назначает, но не выравнивает ресурсы, я задаю вопрос о причинах подобного поведения. Большинство не находятся с ответом, а те, кто все же отвечает, обычно говорят одно из двух:

1. Тогда сдвигается дата окончания проекта (!).

2. Выравнивание влечет за собой действия, лишенные всякого смысла.

Первый ответ указывает на нежелание взглянуть в лицо реальности. О втором поговорим позднее.

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

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

Современные программы по управлению проектами работают следующим образом: сначала определяется структура действий (критический путь) и лишь затем учитываются ограниченные ресурсы, выделенные на проект. Программное обеспечение по проектному менеджменту выявляет критический путь, логически соединяя операции и высчитывая самую длинную цепочку работ. При этом предполагается, что ограничений по ресурсам нет. Затем менеджер проекта добавляет информацию о доступности ресурсов. Программы распределяют ресурсы, используя различные схемы, но обычно в первую очередь — на операции, находящиеся на критическом пути (то есть те, где самый минимальный временной резерв), потом на те, что занимают следующее место по длительности (со следующим наименьшим резервом). Люди, изучавшие вопрос распределения ресурсов, знают, что таким образом не всегда получается оптимальный график. Предлагаются различные решения для оптимизации, некоторые программы предоставляют множество разнообразных вариантов. Единственный метод сделать правильный выбор — метод проб и ошибок. Большинство программ предоставляют определенную возможность контроля за процессом.

Таким образом, первая ключевая мысль Голдратта — принять за ограничение в отдельно взятом проекте критическую цепь, а не критический путь. Критическая цепь строится с учетом ограничений по ресурсам и логической связанности задач.

3.3. Максимально используем ограничение

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

Не так давно Голдратт предложил новшество, которое кто-то (он не говорит кто) подсказал ему. Для многих процесс стал более очевидным и на вид простым. По новому методу необходимо выбрать три НЯ и проанализировать каждое из них как результат действия некоего конфликта. Затем все три конфликта рассматриваются вместе, чтобы вывести конфликт-первопричину, ключевой конфликт. Наконец, по обновленному методу, ключевой конфликт используется для построения модели текущей реальности, где отображается, каким образом он ведет к появлению всех (или большинства) нежелательных явлений в системе. В завершение процесса определяется изменение, которое необходимо произвести в первую очередь, чтобы начать пересмотр системы и создание модели будущего без нежелательных явлений. Хотя у меня имеются сомнения по целесообразности применения данного метода для анализа новой проблемы, полагаю, это удобный способ описания уже произведенного анализа, поэтому буду применять его при разговоре о работе с критической цепью проекта.

3.3.1. ДЛИТЕЛЬНОСТЬ ПРОЕКТОВ РАСТЕТ

Многие согласятся с тем, что проекты становятся все продолжительней.

На занятиях я спрашиваю слушателей: «Все знают, что такое непредвиденные обстоятельства?» Как правило, все утвердительно кивают в знак того, что на самом деле понимают значение данных слов. Тогда я прошу кого-нибудь дать определение. Начинается неуверенное ерзанье, но в конце концов, иногда по моему указанию, кто-то один выдает ответ в духе «то, на что нужны дополнительные деньги и время». «Дополнительные по сравнению с чем?» — уточняю я. Все приходят в еще большее замешательство. Я обращаюсь к рис. 3.6 как примеру вариабельности в реализации задания (с чем они уже столкнулись в упражнении на оценку длительности) и спрашиваю: «Будет огромная разница между тем, сколько мы добавим на непредвиденное, когда оценка сделана с 50%-ной вероятностью, и тем, что мы предусмотрим, когда точность оценки — 90%?» Все соглашаются и понимают теперь, что слово «непредвиденное» можно толковать совершенно по-разному, в зависимости от того, что брать за основу. Я предлагаю операциональное определение: «Непредвиденное — это разница между оценкой, сделанной с 50%-ной вероятностью, и оценкой, сделанной с 90%-ной вероятностью». Если кому-то не нравится, пожалуйста, предлагайте другое. Главное, удостоверьтесь, что собеседники вкладывают в это слово то же значение, что и вы.

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

С одной стороны, все менеджеры проектов хотят, чтобы исполнители соблюдали свои обязательства и завершали задания в срок. Все обычно согласны, что в компании те, кто выполняет задания вовремя, считаются хорошими работниками, а те, кто не завершает дела в положенный срок, считаются плохими работниками. Все признают, что, когда руководитель проекта просит оценить время операции, каждый хотел бы, чтобы в оценке учитывались непредвиденные обстоятельства.

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

Из всего сказанного следует: чтобы спланировать успешный проект, проджект-менеджер должен заложить короткий критический путь. А для этого и оценочная длительность операций должна быть как можно короче и без запаса на непредвиденные обстоятельства.

Рис. 3.7 представляет диаграмму «грозовая туча» для дилеммы, описанной выше. Естественно, не может быть, чтобы длительности операций были оценены одновременно и с 50%-ной, и с более высокой долей вероятности. Возникает конфликт. Чаще всего он проявляется так: эксперты дают максимально точную оценку длительности операций, а руководство, в том числе и менеджер проекта, уменьшает этот показатель, ставя тем самым менее реальную цель (в качестве вызова или повышенных обязательств). При этом обычно не используются никакие методы, действительно позволяющие сократить время выполнения работ. Такие усечения оценочной длительности представляются спорными. Как правило, люди понимают, что руководство тем не менее ожидает от них достижения целей именно за эти маловероятные сроки. Принятые обязательства по проекту фиксируются в графике, и руководство непременно затребует статус выполнения работ в запланированные сроки.

Исполнители, как правило, принимают вызов. У них попросту нет выбора. От них требуют быть частью команды и как следует выполнять свою роль. Субподрядчики зачастую испытывают такое же давление: либо выполняйте задание в укороченные сроки, либо мы предложим работу другим. Люди опытные оправдываются тем, что приходится принимать правила этой игры «на слабо», устроенной руководством. Помните фильмы, где два водителя мчатся на скалу или навстречу друг другу, чтобы посмотреть, кто даст слабину первым и свернет или затормозит раньше, чем другой? Участники проекта знают, что их случай не уникален и то же самое происходит и при выполнении остальных проектных работ. Если они согласятся на сокращение сроков, то, скорее всего, невыполнимость новых условий все равно проявится сначала на каком-то другом этапе, и руководству придется уступить перед фактами реальности и вновь увеличить длительность проекта. Так у исполнителей появится достаточно времени, чтобы завершить свое задание, и они получат выгоду, играя по общим правилам. Высказавшись против сокращения времени, они потеряли бы все и сразу, так как руководство признало бы их плохими работниками, не поддерживающими интересы компании. У людей нет выбора в мире, где правит сильнейший.

3.3.2. ПРОЕКТЫ ЧАСТО ИДУТ С НАРУШЕНИЕМ ГРАФИКА РАБОТ

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

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

На вопрос о причинах возникновения таких ситуаций обычно дается один из двух вариантов ответов. В первом варианте говорится о конкретной проблеме на конкретном проекте, которая еще свежа в памяти (или до сих пор не решена). Просрочка обычно объясняется плохой работой группы исполнителей, которым поручена данная часть работ. Второй вариант — более общий. Здесь вина за сорванные даты возлагается на исполнителей, склонных недооценивать длительность однотипных работ, или на руководство, назначающее спорные сроки.

Как часто исполнители завершают свои задания и передают их на следующий этап досрочно? Как часто они тратят на выполнение задания средств меньше, чем заложено в бюджете? Вы обнаружите, что это происходит намного реже, чем можно было бы ожидать при оценке ресурсов и времени с 90%-ной вероятностью. Даже при несимметричном распределении значений на статистической кривой работы должны завершаться раньше срока в значительном числе случаев. На рис. 3.8 приведены фактические показатели длительности операций в сравнении с плановыми значениями. Большая часть заданий завершается точно вовремя, часто эта цифра составляет до 80%. Это не соответствует представленной ранее оценке времени завершения работ.

Вот некоторые возможные объяснения того, почему в большинстве случаев проекты не завершаются досрочно, а выделенные бюджеты расходуются полностью:

1. Люди строго придерживаются сроков и не видят смысла в досрочном завершении работы.

2. Произведенная оценка ресурсов и времени занижена, и на досрочное выполнение не приходится рассчитывать.

3. Объем работ увеличивается по ходу выполнения проекта, и проект потребляет все выделенное время и бюджет.

4. Считается, что следующий этап все равно еще не готов к тому, чтобы начинать работать досрочно по мере выполнения предыдущего.

5. В большинстве организаций есть угроза наказания за несоблюдение запланированных сроков. А каковы поощрения за досрочное выполнение?

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

7. При досрочном выполнении снижается доверие к оценкам длительности и стоимости работ, получаемым от исполнителей, и со стороны руководства усиливается требование занижения оценочных значений.

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

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

Все это ведет к появлению второго конфликта, проиллюстрированного на рис. 3.9. Верхняя часть диаграммы относится к исполнителю. Чтобы считаться хорошим членом команды, я должен способствовать скорейшему завершению проекта. Чтобы способствовать скорейшему завершению проекта, я должен выполнять работу досрочно. Нижняя ветвь показывает, что для того, чтобы быть успешным членом команды, при оценке длительности заданий я должен закладывать достаточно времени, чтобы выполнить свои обязательства. А чтобы было достаточно времени на выполнение обязательств в будущем, не следует досрочно завершать работу сейчас. Очевидно, что нет пределов совершенству: всегда найдется что перепроверить и улучшить, даже если кажется, что все уже сделано. Даже если я отчитаюсь по результатам заранее и сдам работу на проверку менеджеру, вряд ли он возьмется за нее до того, как наступит положенный срок, ведь он очень занят.

Студенческий синдром

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

Вероятно, для вас не будет новостью, что с вами все нормально и что большинство людей склонны откладывать выполнение задания до последнего. Это тем более справедливо для людей занятых, востребованных, то есть для всех тех, на кого в первую очередь и рассчитывают менеджеры проектов, стремясь обеспечить своевременное выполнение работ критического пути.

Рис. 3.10 показывает типичную модель работы многих из нас. Менее трети задания выполняется в первые две трети срока, отведенного на него. И две трети — за последнюю треть срока. А когда, скорее всего, обнаружится, что справиться с заданием за оставшееся время будет весьма проблематично? В первую или в последнюю треть срока? Если вы уже работаете на все 100% и даже больше, чтобы завершить две трети дела за оставшуюся треть времени, то, попытавшись приложить еще сил, вы все равно не завершите работу вовремя. А каковы шансы справиться с какой-нибудь непредвиденной проблемой, например поломкой компьютера?

Студенческий синдром практически не оставляет шансов наблюдать положительные проявления вариабельности в длительности выполнения проектных работ. Соображения, приведенные ранее, не дают использовать возможность досрочного завершения и начала заданий, даже если мы и видим такие возможности. Неудивительно, что проекты редко завершаются досрочно! Реальность такова, что относительная длительность операций обычно характеризуется распределением, сильно смещенным влево,

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

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

3.3.3. «МНОГОЗАДАЧНОСТЬ»

Допустим, системой управления графиком предусмотрено, что исполнители приступают к своим заданиям как можно раньше и сообщают о дате начала выполнения менеджеру проекта. Предположим, что в течение дня исполнитель распределяет время между тремя заданиями, каждое из которых, если уделять все время только одному заданию, можно было бы закончить за неделю. Когда завершатся все три задания? Если считать, что на переключение от одной операции на другую время не теряется, то ни одна из них не завершится ранее, чем через три недели. Наличие нескольких заданий одновременно вызывает увеличение длительности по всем трем проектам с одной недели до трех. Получение результата сдвигается по первому проекту на две недели, а по второму — на одну.

Признавая справедливость всего вышесказанного, многие тем не менее возразят, что иначе и невозможно. Ведь нужно успеть сразу все и угодить сразу всем. Люди согласны с нашими доводами, логически обосновывающими, что многозадачность — не лучший (а может, и наихудший) способ эффективно обеспечить соответствие множественным требованиям (рис. 3.12). Они признают, что это заведомо снижает вклад каждого исполнителя в общий результат проекта. Более того, не принимается во внимание,

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

Питер Маррис [1] утверждает, что наличие «многозадачности» — социальное проявление эксплуатации более слабых более сильными, попытка сильных защититься от неопределенности. Иными словами, руководство извлекает выгоду из ресурсов нижних уровней организации путем давления, ведущего к возникновению «многозадачности».

3.3.4. КЛЮЧЕВОЙ КОНФЛИКТ

ВЕДЕТ К НЕЖЕЛАТЕЛЬНЫМ ЯВЛЕНИЯМ

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

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

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

Вот широко распространенный конфликт, о котором говорил и Деминг: работа во имя отдельной части системы не ведет к успехам всей системы. Это конфликт, описанный и среди принципов теории ограничений: в оптимально настроенной системе не все части будут работать на максимуме возможностей. Более того, ключевой конфликт ставит исполнителей и руководство проекта в ситуацию «выиграл — проиграл». Неудивительно, что для всех участников проект — это большой стресс. Неудивительно, что так много проектов заканчивается неудачно.

На рис. 3.14 видно, как ключевой конфликт ведет к возникновению всех нежелательных явлений. Отсюда следует, что ключевой конфликт — это та точка системы управления проектом, к которой необходимо приложить усилия, чтобы получить оптимальный результат. Решение (новая теория), представляющее собой иной способ снятия ключевого конфликта, должно сказаться на системе таким образом, что все НЯ превратятся в свою противоположность — желаемые результаты.

На рис. 3.14 представлена неполная логическая цепочка. Это лишь условные связи ключевого конфликта и НЯ. В главе 11 более подробно освещена логика выстраивания этих последовательностей, а полное дерево текущей реальности доступно на сайте http://www.Advanced-projects. com. Сейчас же, если вы согласны, что в основе большинства или всех НЯ лежит ключевой конфликт, вам, должно быть, не терпится приступить к процессу поиска решения.

3.4. К желаемым результатам

3.4.1. РАЗРЕШАЕМ КЛЮЧЕВОЙ КОНФЛИКТ

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

У Голдратта были все предпосылки разработать метод критической цепи в проектах. Идея критической цепи базируется на признании того факта, что вариабельность при выполнении проектных работ коренится в самой существующей системе управления проектом. Он с большим успехом использовал свое решение при управлении производством, как описано в романе «Цель» [2]. И ему было известно, что в большинстве случаев неопределенность оценок длительности проекта намного превышает уровень вариабельности производственных процессов. Он также знал, что в большинстве случаев степень взаимозависимости работ в проекте такая же или даже больше, чем на производстве. Естественно, что он рассматривал проекты с данной перспективы, чтобы выявить ложную установку.

Влияние вариабельности и взаимозависимости событий Голдратт описал в истории о Херби (роман «Цель»). Он использовал образ отряда скаутов, отправившихся в поход по лесу. Тропа очень узкая, поэтому скауты не могут обгонять друг друга и должны идти по одному. По мере продвижения цепочка все растягивалась. Алекс Рого, главный герой «Цели» и руководитель отряда, понял, в чем дело. Скорость ходьбы каждого скаута не является постоянной. В действие вступают статистические колебания. Каждый зависит от скорости впереди идущих, потому что обгонять нельзя. Колебания приводят к тому, что длина шеренги постоянно увеличивается.

Херби идет медленнее всех, он — ограничение. Просветы в строю подобны кучам заготовок на производстве, которые скапливаются, пока станок обрабатывает детали, поступившие ранее (первыми в цепочке).

В проектах роль просветов в шеренге скаутов играет время. Если следующий исполнитель окажется не готов к тому моменту, когда предшественник завершит свою работу досрочно, время на проекте потратится впустую. Мы теряем действие положительных статистических отклонений. Это все равно что самый быстрый скаут, которому приходится шагать за самым медленным: может догнать, но не обойти. Длина цепи увеличивается. На проектах эта ситуация более пагубна, чем на производстве. На заводе заготовки в конце концов все равно будут обработаны. На проекте же потеря времени невосполнима. Время не остановишь.

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

Как же по максимуму использовать критический путь? Голдратт защитил диссертацию по физике. Он разбирается в статистике, знает об «облачном», непредсказуемом поведении большинства явлений реальности и понимает, что единственный способ извлечь пользу из знания статистики — рассмотреть значительное число событий. Еще до него Эдвардс Деминг и Уолтер Шухарт показали, что наука не может точно предсказать единичное проявление статистически наблюдаемого явления. Это приводит к очень простой (как сейчас уже кажется) мысли: сконцентрировать весь запас времени на неопределенность в конце проекта — в буфере. Этот буфер — прямой аналог предложенного Голдраттом для производственных систем, где запасы заготовок стратегически располагаются перед станками, чтобы избежать простоев.

Сосредоточение запаса на непредвиденные обстоятельства в буфере дарует нам два значительных преимущества. Во-первых, более короткий план. Колебания суммы величин из нескольких независимых распределений равняются сумме колебаний тех популяций, откуда были взяты величины. Колебание — это значение стандартного отклонения в квадрате. Величина стандартного отклонения пропорциональна величине колебаний по отдельно взятой проектной операции. Иными словами, запас на неопределенность по сумме операций равняется квадратному корню из суммы квадратов запасов по каждой операции. Если пытаться обеспечить своевременность выполнения каждой отдельной работы по проекту, необходимо по каждой предусмотреть запас на компенсацию неопределенности. При классическом подходе к ведению проекта величины этих запасов механически суммируются и влияют на общую длительность цепочки. Если же изъять временные запасы из каждой операции, сложить их все и приплюсовать в конце пути, то величина их будет равняться квадратному корню из суммы квадратов значений, изъятых из каждой операции, а это уже намного меньшее число. Рис. 3.15 показывает, как это все работает в самом простом случае. Причина очевидна. Некоторые работы будут выполнены с запозданием, некоторые — досрочно. Распределение суммы не должно равняться распределению сумм отдельных колебаний, так как некоторых из них попросту не будет.

Во-вторых, при использовании данной стратегии в игру вступает и еще один закон статистики. Центральная предельная теорема гласит, что распределение независимых или слабо зависимых значений склонно иметь распределение вероятностей, близкое к нормальному. Нормальное распределение является симметричным. У него нет длинного «хвоста» справа, как это бывает у распределений значений по отдельным проектным работам. Это значит, что сосредоточение запаса на непредвиденное в конце проекта снижает вероятность значительного перерасхода данного запаса.

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

3.5. Реализуемость решения (доказательства)

Использование научного метода из теории познания ведет к выбору предпочтительной теории путем проведения критического обсуждения и эксперимента. Сравнивая концепции критической цепи и критического пути, мы обнаруживаем большую состоятельность первой, так как она:

1) предоставляет ясный способ управления вариациями, вызванными общими причинами;

2) явным образом решает проблему ограничения ресурсов.

Поппер [3] указывает, что новая теория должна содержать в себе и объяснять старую. Если бы ресурсы были неограниченными, то критическая цепь равнялась бы критическому пути. При наличии ограничений по ресурсам критическая цепь — приемлемое решение проблемы критического пути с выровненными ресурсами. Таким образом, критическая цепь включает в себя и критический путь.

Как предлагает Поппер, первым методом проверки новой теории должно быть критическое обсуждение. В ходе этой дискуссии новая теория подвергается сопоставлению со старой, проводится поиск логических дедуктивных обоснований и свидетельств в поддержку гипотез, легших в основу новой и старой теорий. Суммируя суть научного метода, Поппер указывает:

1. Индукция (то есть заключение, сделанное на основе множества наблюдений) — миф. Это ни факт психологии, ни явление повседневной жизни, ни научная процедура.

2. По-настоящему научный образ действий заключается в работе с гипотезами: мгновенное выдвижение предположения, зачастую исходя из одного-единственного наблюдения.

3. Повторяющиеся наблюдения и эксперименты выступают в науке в роли проверки наших предположений, или гипотез (то есть являются несостояв-шимся опровержением).

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

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

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

Для начала работ человеческие ресурсы являются таким же граничным условием, как и наличие всех исходных данных и материалов. Ресурсы — необходимое условие для выполнения операции. По методу СРМ вполне можно решить проблему ограниченных ресурсов, определив сначала критический путь, невзирая на ресурсы, а потом уже оценить влияние имеющегося ресурсного ограничения. Иными словами, исходное предположение при определении критического пути говорит нам, что ресурсы ограничением не являются. Считается, что они неисчерпаемы. Мне не удалось найти обоснований этой установке. Голдратт легко выявил данную скрытую установку, так как в производственных системах, с которыми он работал, она была очевидным фактом [4].

Некоторые специалисты, применяющие ССРМ, утверждают, что ограничение по людским ресурсам необязательно будет столь же жестким, как техническое ограничение. Другими словами, во многих случаях нельзя поменять последовательность работ: прежде чем устанавливать оборудование, необходимо подготовить площадку, а прежде чем заменить оборудование, нужно демонтировать установленное. Однако с ресурсами, как правило, можно обращаться более гибко: запланировать сверхурочные работы, назначить выходные дни рабочими или снять ограничение массой иных способов. Это не противоречит ССРМ, ведь техническая последовательность этапов в плане сохраняется. Для выполнения любой операции необходимо техническое обеспечение с предыдущего этапа и ресурсы, которые будут выполнять работу. ССРМ не запрещает использовать альтернативные методы снятия ограничений.

В этой главе мы показали, что СРМ, как правило, не позволяет обнаружить настоящее ограничение в проекте (ресурсы). А это простой и логичный шаг, заложенный в методе критической цепи: человеческие ресурсы и самая длинная цепочка операций — два основных потенциальных ограничения, обуславливающие сроки завершения проекта.

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

3.6. Определяем, на что менять

Сняв ключевой конфликт, мы производим в системе изменения, необходимые для ее перехода в желаемое состояние. В противовес имеющимся нежелательным явлениям существующей проектной системы, желаемыми результатами будут:

1) проекты, всегда завершающиеся вовремя или досрочно;

2) проекты, завершающиеся в рамках или с экономией бюджета;

3) проекты, показавшие все запланированные результаты;

4) проекты, в которых изменения минимальны;

5) проекты, не испытывающие нехватки ресурсов и не вступающие в бой за них;

6) проекты, длительность которых становится все меньше и меньше;

7) проекты, завершающиеся все без исключений;

8) проекты, обеспечивающие решение в духе «выигрывают все», одинаково выгодные для всех участников.

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

3.7. Итоги

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

• нежелательные явления указывают на проблему в существующей теории управления проектами;

• ограничение отдельного проекта — это критическая цепь, то есть критический путь после выравнивания ресурсов;

• предложен метод максимального использования ограничения путем более эффективного управления неопределенностью (ключевой конфликт существующей системы управления проектом) — это конфликт между стремлением обеспечить гладкое выполнение каждой операции в отдельности и необходимостью успешно завершить проект в целом;

• решение (новая теория) должно преодолеть ключевой конфликт, опровергнув главную исходную установку в основе существующей системы, указывающую, как управлять неопределенностью;

• вероятное решение может заключаться в методах управления неопределенностью, подобных тем, которые зарекомендовали себя в улучшении показателей производственных систем;

• решение должно предусматривать управление неопределенностью при помощи буфера — запаса времени на непредвиденные обстоятельства, добавленного в конец цепочки операций;

• растущее число практических примеров свидетельствует о реализуемости метода ССРМ на всех типах проектов.

Учтите: знать о неопределенности или анализировать неопределенность и управлять неопределенностью — это не одно и то же. Людям было известно о явлении неопределенности задолго до начала их проектов. Существует масса методов анализа неопределенности. И знания, и методы — необходимые, но недостаточные условия для управления неопределенностью. Управлять — значит предпринимать действия, приближающие систему к цели. В главе 4 дано полное описание такой системы управления.

ЛИТЕРАТУРА

1. Marris, Peter, The Politics of Uncertainty, London: Routledge, 1996.

2. Goldratt, Eliyahu M., The Goal, Great Barrington, MA: North River Press, 1984 (в русском переводе: Голдрат Э. М., Кокс Д. Цель. Процесс непрерывного совершенствования. — М.: Попурри, 2007).

3. Popper, Karl R., Objective Knowledge, An Evolutionary Approach, Oxford: Clarendon Press, 1979, р. 144 (в русском переводе: Поппер К.Р. Объективное знание. Эволюционный подход. — М.: Эдиториал УРСС, 2002).

4. Goldratt, Eliyahu M., Theory of Constraints, Great Barrington, MA: North River Press, 1994.

Глава 4. Комплексное решение для отдельного проекта

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

4.1. От системных требований к модели системы

4.1.1. МАТРИЦА ТРЕБОВАНИЙ

Табл. 4.1 представляет собой свод требований к эффективной системе управления проектом, разработанный по методу Джозефа Джурана [1]. В ней дается иерархия желаемых свойств, и в первую очередь самые необходимые условия реализации проекта. К ним относятся три граничных технических условия (содержание, бюджет и график) и необходимость удовлетворять ожиданиям участников проекта. Участники — это как минимум заказчик проекта и проектная команда, а в некоторых ситуациях и многие другие (например, субподрядчики, акционеры, законодательные органы, соседи, правительство и иные сообщества).

Это те требования, на которые я ориентировался, формулируя ССРМ. Многие сторонники ТОС и метода критической цепи не учитывают все их в полной мере по одной из следующих причин. Кто-то просто не знает всего набора требований, которым должна удовлетворять система управления проектом, и сосредотачивается лишь на том, о чем упоминает доктор Элияху Голдратт. Другие, возможно, не считают эти требования обязательными. Я думаю, некоторым организациям не удалось успешно реализовать возможности ССРМ потому, что они не выполнили все условия эффективного ведения проектов. Система управления, удовлетворяющая всем требованиям из табл. 4.1, будет соответствовать и необходимым условиям успешности проектов, хотя к каждому конкретному проекту могут предъявляться и какие-то специфические требования.

Во второй и третьей колонках приведены соответственно требования второго и третьего порядка, производные от главных из первой колонки. Содержание второй и третьей колонки может различаться от проекта к проекту. В данной таблице приведены требования общего характера.

Вряд ли у вас получился бы точно такой же список требований. Эта таблица основана на положениях РМВОК, моем собственном опыте и особенностях того решения, которое мы собираемся рассмотреть. То, что заданное решение определяет выставляемые к проектируемой системе требования, — факт жизни. Только определив и критически оценив искомое решение, мы по-настоящему начинаем понимать суть проблемы. Например, не зная теории Голдратта и основ концепции критической цепи, я бы не включил работу с общими причинами вариабельности в список требований к проекту.

Таблица не является и не может быть полной. Это только идея, предмет для обсуждения и совершенствования. Например, я не очень доволен тем, что требования полностью включают в себя только глубинные знания, особенно знание психологии. Полагаю, можно пойти и дальше, включая в список принципы шести сигм и бережливого производства. Я считаю, что список «вполне приемлемый» для того, чтобы выстроилась картина ССРМ и мы занялись совершенствованием проектной системы, бросив вызов трудностям, описанным в главе 1.

4.1.2. КРИТИЧЕСКАЯ ЦЕПЬ ДЛЯ ОТДЕЛЬНОГО ПРОЕКТА:

КРАТКОЕ ИЗЛОЖЕНИЕ

Рис. 4.1 показывает ключевые элементы метода критической цепи как решения для отдельного проекта. Это решение соответствует функциональным требованиям к системе управления проектом. Изображение наглядно демонстрирует разницу между ССРМ и СРМ. Основные особенности ССРМ следующие:

1) критическая цепь определяется как самая длинная цепочка операций проекта с учетом ограничений как по ресурсам, так и по логике последовательности операций;

2) конфликты по ресурсам не рассматриваются до момента определения критической цепи;

3) в плане используются среднеоценочные характеристики операций (имеющие вероятность 50/50), а запас на компенсацию влияния общих причин вариабельности сосредоточен в конце цепочек работ (на рис. 4.1 буфер изображен в виде амортизатора);

4) выполнение цепочек работ, вливающихся в критическую цепь, координируется с помощью специальных буферов на слияние путей (при одновременном продолжении работ по снятию конфликта ресурсов);

5) уделяется внимание обеспечению ресурсами, особенно по операциям критической цепи (на рисунке показан один из методов — ресурсный буфер, далее я расскажу и о других);

6) в качестве средств оценки и контроля за реализацией проекта используются проектный буфер и буфера на слияние путей.

В следующих разделах мы рассмотрим каждый из данных пунктов подробно.

Для эффективного применения ССРМ в отдельном проекте крайне необходимо добиться следующих изменений привычного стиля работы:

1) руководство должно способствовать тому, чтобы при оценке операций давались средние величины, и не требовать от исполнителей завершения работ в точно обозначенные сроки;

2) руководство должно дать исполнителям возможность в конкретный момент времени заниматься только одним заданием;

3) исполнители должны сосредотачивать усилия на одной операции и передавать результаты на следующий этап, как только работа завершена;

4) чтобы решить, над чем дальше работать, каждый должен использовать план проекта и отчеты по буферу.

Вот и все!

4.2. Разработка решения «критическая цепь»

Следующие разделы описывают характеристики метода критической цепи в свете пяти направляющих шагов ТОС. Не знаю, таким ли путем Голдратт на самом деле пришел к пониманию этих особенностей. В соответствии с приведенными у Поппера [2] описаниями теории познания и научного метода вовсе не важно, как именно Голдратт нашел эти характеристики (что Поппер назвал бы «дерзкой гипотезой»). Важно то, что мы должны подвергнуть данную гипотезу критическому обсуждению, проверить экспериментально и посмотреть, будут ли результаты свидетельствовать в пользу предпочтения критической цепи критическому пути.

4.2.1. ОПРЕДЕЛЕНИЕ ОГРАНИЧЕНИЯ В ПРОЕКТЕ

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

В этих определениях не уточняется несколько важных моментов. Во-первых, предположение о том, что длительность операции определяется точно и с первого раза (детерминирована). Во-вторых, не указано, с какой вероятностью сделана оценка (50% и более высокая степень вероятности?). А ведь это весьма существенно.

В РМВОК идет речь и о вероятностных подходах к составлению расписания проекта, таких как методы PERT и Монте-Карло. Однако определения даются очень скудные, так что пользоваться этими методами, исходя только из описаний в РМВОК, невозможно. Как показали мои исследования, реально на практике они применяются редко.

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

Базовое определение критической цепи заключается просто в нахождении ограничения проекта, или «последовательности зависимых событий, не позволяющих проекту завершиться за меньшее время. При нахождении критической цепи зависимость от ресурсов такая же, как и зависимость между операциями».

Поиск ограничений проекта в расписании связан с тем, что расписание влияет и на бюджет, и на содержание проекта. К независимым переменным, сказывающимся на результате, относятся проектное задание (содержание), установленная система управления проектом, а также ресурсы, которые доступны для работы по проекту. Результаты управления проектом — величины взаимозависимые (фактические содержание, бюджет и сроки). Когда увеличивается длительность при неизменном содержании, обычно растут и затраты. Если расширяется содержание без изменений имеющегося бюджета (или количества ресурсов), как правило, сдвигается график. А когда содержание расширяется, но сроки должны остаться неизменными, вырастут расходы. Следовательно, правильным будет в первую очередь сосредоточиться на своевременном выполнении проекта.

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

Читая курс для членов PMI, я провел небольшое исследование. Среди слушателей много сертифицированных профессионалов в управлении проектами РМР. Практически все они согласны с тем, что получить в свой проект ресурс именно в тот момент, когда он необходим, очень трудно и часто из-за этого случаются задержки. Однако мало кто (менее 5%) указывает, что регулярно занимается выравниванием ресурсов (то есть учитывает ограниченность ресурсов на проекте). Когда я интересуюсь причинами, большинство объясняет, что после выравнивания ресурсов срок реализации превышает ожидания руководства.

На рис. 4.2 изображен типичный график, построенный методом критического пути. Имена исполнителей на нем указывают на уникальные ресурсы. Очевидно, что не удастся уложиться в срок, поскольку исполнитель не может выполнять несколько заданий одновременно.

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

Что еще более важно, первоначальный критический путь не является ограничением для выполнения проекта. Поскольку ресурсное ограничение в проекте часто самое значительное, метод планирования проекта по ТОС всегда его учитывает. Таким образом, критическая цепь зависит от ресурсов, а эта зависимость и определяет самый длинный путь (ограничение) в проекте. Этот метод снимает все ресурсные ограничения в ходе нахождения критической цепи. В критической цепи проекта между операциями могут иметься разрывы. На рис. 4.4 приведена критическая цепь для рассматриваемого нами примера.

Если в вашей организации нет ограничения по ресурсам (или ресурсы неисчерпаемы), критическая цепь будет совпадать с первоначальным критическим путем. Это важный факт для проверки метода критической цепи. Концепция ССРМ (как минимум в части нахождения критической цепи) включает в себя СРМ как частный случай. По теории познания, это одно из свидетельств состоятельности нового научного метода.

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

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

4.2.2. МАКСИМАЛЬНОЕ

ИСПОЛЬЗОВАНИЕ ОГРАНИЧЕНИЯ

Определив критическую цепь как ограничение, мешающее выполнять проекты быстрее, мы должны теперь постараться максимально использовать возможности ограничения. Это означает сокращение как планового, так и фактического времени реализации проекта. ССРМ использует критическую цепь, опираясь на знание вариабельности. Вот в чем основное отличие метода критической цепи от существующих систем управления проектами: Голдратт учел как статистические колебания, так и явление взаимозависимости событий. Конечно, не только автор ТОС признает действие вариабельности. Новое в том, чтобы применить его метод в управлении проектами.

Деминг отмечал, что многие менеджеры, не понимая фундаментальной разницы между общими и особыми причинами вариабельности, наносят системам вред. Он говорит: «Исходя из собственного опыта, должен сказать, что для большинства проблем и возможностей для улучшения справедливо следующее распределение: 94% присущи системе (лежат в зоне ответственности руководства) и 6% — являются особыми случаями».

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

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

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

Подобная вариабельность в исполнении проектных работ, вызванная общими причинами, — не исключительное явление, в отличие от отдельных выявленных в проекте рисков. Методика PERT — попытка оценить воздействие общих причин вариаций, используя три варианта прогноза длительности операции, по ряду причин оказалась не очень удачной. Создатели РМВОК и других источников до сих пор ссылаются на этот прием, хотя сегодня он используется редко. Диаграммы PERT в том виде, в каком они упоминаются в большинстве источников по проектному управлению и применяются в программных продуктах, всего-навсего показывают логику сети проекта вне зависимости от временной шкалы; в них не задействованы три типа оценки длительности. В некоторых проектах для оценки степени влияния неопределенности длительностей и затрат используются симуляции или метод Монте-Карло. И хотя данные приемы позволяют оценить степень неопределенности, они не являются инструментом для систематического управления ею.

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

4.2.2.1. Извлекаем выгоду из оценок

ССРМ стремится использовать средние или сделанные примерно с 50% вероятности оценки отдельных операций. Руководитель, работающий с ССРМ, осознает, что реальная длительность выполнения отдельного задания включает отклонения, вызванные общими причинами. И он не критикует исполнителей, если фактические сроки исполнения работ расходятся с плановыми.

Большинство менеджеров проектов пытаются учесть действие общих причин вариабельности, добавляя резерв на непредвиденные обстоятельства к оценочным значениям длительности каждой операции. В явном виде наличие и размер этого резерва обычно никак не обозначаются. Специалисты, производящие оценку длительности работ, исходят из убеждения, что менеджер проекта хотел бы видеть максимально реальные цифры — такие, чтобы можно было с вероятностью 80%, а то и 95% утверждать, что работа завершится именно за это или меньшее время. Как видно на рис. 4.5, такая оценка в два и более раз превышает значение, выведенное с 50%-ной долей вероятности. Как правило, на проектах исполнителю будет хорошо, если он завершит свое задание в срок, и нехорошо — если нарушит плановую дату. Это также побуждает людей при оценке называть максимально вероятные сроки выполнения работ. Уолтер Шухарт, наставник Эдвардса Деминга, говорил [3]:

«Необходимо отметить, что специалист по статистике не станет пытаться делать какие-либо достоверные прогнозы для одного-единственного оценочного значения некоего показателя. Он сформулирует, как поведет себя все множество значений данного показателя, полученных путем оценки в тех же условиях, что и отдельное выбранное им значение».

Сказанное объясняет, почему попытки справиться с неопределенностью по каждой отдельной операции в проекте бесполезны.

Сейчас много говорят о «повышении точности оценок». Раньше я думал, что так и надо, что стоит организовать более строгий процесс — и можно будет лучше оценивать длительность и стоимость проектов. В общем-то, все правильно. Однако, поняв особенности явления вариабельности, я по-новому взглянул на смысл, стоящий за словами «повышение точности». Большинство людей под «повышением точности оценки» понимают увеличение точности оценки каждой отдельной составляющей, входящей в общую величину длительности и затрат. Шухарт объясняет, что это невозможно. Постепенно я понял, что вероятность оценки каждой отдельной составляющей равна нулю. Вы можете оценить конечную вероятность лишь тогда, когда речь идет об интервале значений, в котором может находиться некоторый показатель. Таким образом, точности в том виде, как ее трактует большинство людей, с научной точки зрения не существует.

Представим себе, что нужно определить точность боя ружья. Сделав один выстрел по мишени, вы не получите представления о том, какова эта точность. Под влиянием общих причин вариабельности пуля могла попасть точно в цель, а могла уйти и на несколько дюймов в сторону. Единственный способ определить точность боя — сделать серию выстрелов, оценить рисунок попаданий и соотнести его центр с центром мишени. Конечно, это тоже не настоящее измерение точности. Вы оцениваете работу данного ружья у данного стрелка с данным типом патронов и в данных обстоятельствах. Если изменить один из элементов, изменится и точность. Например, если стрелять буду не я, а мой сын, точность ружья окажется намного выше. Стрельба с расстояния 25 ярдов тоже будет более результативной, чем со 100 ярдов. И так далее.

Понимание настоящего смысла слова «точность» (степень отклонения результата от заданного среднего значения) ведет к осознанию двух способов повышения точности отдельной оценки. Можно более точно описать исходные установки, сузив тем самым границы стандартного отклонения, или улучшить процесс. Например, указав, что измеряется точность выстрелов, производимых из ружья данным стрелком на заданном расстоянии и определенным типом патронов, вы уменьшите область отклонений (снизите неопределенность при оценке точности). А если изменить процесс — стрелять с опоры или в закрытом помещении, где не мешает ветер, — то уменьшится степень вариабельности. В проекте аналогом первого подхода будет служить улучшение процесса оценки (например, использование базы оценок и стандартизированных, а не случайных процедур). Аналогия второму подходу — совершенствование самого рабочего процесса (письменные процедуры, новые инструменты и пр.).

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

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

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

1) руководитель проекта помнит в основном только случаи, когда в реальности было превышено плановое (оценочное) значение, и поэтому добавляет к оценке еще и от себя резерв на непредвиденные обстоятельства;

2) исполнители склонны в следующий раз оценивать длительность с запасом.

В-третьих, если бы действительно на проектах преимущественно использовались заниженные оценки длительности, то практически все работы завершались бы с опозданием. Если допустить, что мы в своих проектах даем возможность проявиться положительным отклонениям (хотя факты говорят об обратном), слияние цепочек работ снижает вероятность успешного завершения, если оценки были сделаны с менее чем 50%-ной долей вероятности. (В реальности все еще, конечно, усложняется деятельностью по контролю за исполнением проекта. Контролирующие мероприятия могут как способствовать, так и препятствовать своевременному завершению работ.)

Многие проекты идут с нарушением графика, однако наши наблюдения показывают, что значительная доля (например, около трети проектов в сфере информационных технологий) завершается своевременно. Вовремя заканчиваются практически все проекты по подготовке коммерческих предложений. Почти все крупные мероприятия проходят по плану с минимальными проблемами. Из-за срыва плановой даты проекта никогда еще не переносились Олимпийские игры. (Был ряд напряженных моментов с подготовкой к Олимпиаде-2004 в Греции, но и тогда все разрешилось благополучно.)

Анализ контрольных точек (milestones) в одном крупном проекте подтвердил положение Голдратта о том, что около 80% ключевых событий происходит точно по графику, одно или два — раньше срока, а остальные — с опозданием, при этом незначительное число — со значительным опозданием. Проект, который я анализировал, состоял примерно из 30 больших подпроектов, ряд из которых в свою очередь снова подразделялись на меньшие проекты.

Как показывает мой опыт, при планировании проектов в сотнях самых разных компаний либо не уточняется степень надежности оценочных значений длительности операций, либо не указывается, на чем основана оценка, либо и то и другое. РМВОК призывает менеджеров проектов показывать эти параметры, однако практически не объясняет, что с ними делать. Исключением являются строительные проекты. Здесь накоплен большой объем численных данных. Например, «Государственное руководство к составлению смет в строительстве» (National Construction Estimator) [4] написано с использованием обширнейшей базы данных. В нем приводится перечень потенциальных факторов (общих причин вариабельности), влияющих на точность оценки. Указывается, что действие почти каждого из этих факторов вызовет изменение оценочного значения затрат на несколько десятков процентов. Следовательно, зачастую они будут оказывать аналогичное влияние и на график.

4.2.2.2. Используем законы статистики для управления общими причинами вариабельности

Метод критической цепи основан на действии статистического закона суммирования стандартных отклонений¹⁰: защита проекта от действия общих причин вариабельности на каждую операцию обеспечивается путем добавления буферов на концах цепочек операций. В плане буфер указывается как очередная операция, только не имеющая содержательного наполнения.

Отметим, что в терминах статистики говорят о стандартном квадратичном отклонении, обозначаемом обычно как s¹¹. Для конкретного определенного статистического распределения заданное число стандартных отклонений определяет совокупную вероятность. Например, при нормальном распределении в область плюс-минус одно стандартное отклонение попадает 67% данных, или совокупная вероятность того, что результат будет наблюдаться в пределах одного стандартного отклонения от среднего значения, составляет 67%.

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

Рис. 4.6 показывает, как в простом случае закон суммирования отклонений ведет к сокращению графика. В данном примере мы предполагаем, что с 50%-ной долей вероятности длительность каждой операции составит одну неделю, а с 90%-ной вероятностью — две недели. Следовательно, срок завершения цепочки из четырех операций по плану равняется восьми неделям. Помня о студенческом синдроме и склонности не завершать работ до срока, мы можем ожидать, что вряд ли проект завершится быстрее, чем за восемь недель, и что, вероятнее всего, все закончится позднее.

Когда мы объединяем запасы на непредвиденные обстоятельства, работает и еще один фактор — центральная предельная теорема, описанная в разделе 3.4. Многие проектные работы характеризуются смещенным влево распределением, имеющим среднее значение стремящимся к минимальному и длинную правую ветвь кривой распределения. Это говорит о том, что длительность операции может оказаться намного больше средней. В таких смещенных влево распределениях среднее значение (mean) обычно оказывается левее, чем медиана, то есть наиболее часто встречаемый показатель. Таким образом совокупность операций в проекте будет, скорее всего, иметь симметричное распределение и суммарное отклонение меньшее, чем алгебраическая сумма отклонений по каждой операции. Это справедливо вне зависимости от того, известно ли вам, каково распределение на самом деле, или нет.

В ССРМ при построении плана берутся значения длительности с вероятностью 50%, так получилась критическая цепь из четырех операций общей длительностью четыре недели. Буфер проекта — квадратный корень из суммы квадратов отдельных отклонений, то есть в нашем случае разностей между оценочными значениями длительности каждой операции с вероятностью завершения 50% и 90%. Так как для каждой операции разность между оценочными значениями составляет одну неделю, то суммарное отклонение по проекту составит две недели¹². Следовательно, общий план проекта будет иметь длительность всего шесть недель. А с учетом такой особенности, как жесткая ориентация исполнителей на плановую дату, есть надежда, что проект завершится и за четыре недели.

4.2.2.3. Работаем с доступностью ресурсов

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

Я придерживаюсь более традиционного подхода, широко используемого в современных компьютерных приложениях. Метод, который я рекомендую, заключается в том, чтобы отсортировать данные в файле проекта по каждому исполнителю и дать им и их руководителям достаточное время (может, недели три-четыре), чтобы посмотреть, какие работы предстоят. Такая операция с графиком работ позволяет лучше всего оценить, когда и что, скорее всего, начнется. Я не показываю в таких отчетах колонок с датами, потому что иначе внимание приковывается к конкретным заданным датам. Вместо этого я готовлю календарь, который дает общее представление о временных промежутках. Пример дан на рис. 4.7.

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

4.2.3. ИЕРАРХИЧЕСКОЕ ПОДЧИНЕНИЕ ПУТЕЙ ПРИ СЛИЯНИИ

В большинстве проектов есть несколько последовательностей работ. И все последовательности к концу проекта «сливаются» в критический путь, хотя бы просто для того, чтобы достичь контрольной точки, знаменующей завершение проекта. Обычно такие объединения происходят ближе к окончанию проекта. Одна из причин этого в том, что различные сборки и тесты чаще всего проводятся в самом конце и для этого нужно иметь множество составляющих. Далее мы увидим, что в этом кроется основная причина всем известного явления: многие проекты 90% пути проходят в первый год, и оставшиеся 10% — во второй. На рис. 4.8 показан эффект слияния путей в проекте. Операция не может начаться, пока не закончится последняя из предшествующих работ.

Когда несколько цепочек работ сходятся в одну, возникает эффект фильтра: он «отсеивает» положительные отклонения и оставляет в силе, передавая на следующий этап, самую большую временную задержку. Объясняется это тем, что при слиянии путей объединенный путь не может начаться, пока не завершатся все «вливающиеся» в него цепочки. Следовательно, работы на объединенном пути не стартуют, пока не закончится самая последняя из вливающихся работ. Представим себе некую проектную операцию на критическом пути, для начала которой необходимы результаты трех отдельных заданий. Это распространенная ситуация, характерная для этапа сборки или для проведения крупных мероприятий, таких как шоу и съезды, например. В день открытия все должно быть готово. Обычно требуется не три, а гораздо больше составляющих. Однако даже если предположить, что их три и вероятность своевременного завершения каждой равняется 50%, то шансы того, что хотя бы одна поступит с опозданием, составляют 88%! И даже если вероятность того, что каждое задание будет выполнено вовремя, равна 90%, то ожидать срыва сроков хотя бы по одному из них можно с 30%-ной долей уверенности, то есть практически шансы один к трем.

ССРМ предлагает механизм защиты критической цепи от задержек, подчиняя выполнение всех работ, «вливающихся» в критическую цепь, ее потребностям. К каждому потоку работ, впадающему в критическую цепь, помещается «буфер на слияние путей». На рис. 4.9 показаны такие буферы и последовательности работ, которые в конце проекта сливаются с критической цепью. Буфера на слияние путей — это механизм оценки и контроля, защищающий критическую цепь. Также видно, как буферы нивелируют опоздания в выполнении работ.

Этот новый прием защищает (до определенных пределов) критическую цепь от потенциальных задержек, вызванных нарушениями сроков на сливающихся с ней путях. Он также позволяет оценивать состояние дел для сливающихся путей, сохраняя в центре внимания критическую цепь.

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

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

4.2.4. ВЫПОЛНЕНИЕ РАБОТ

4.2.4.1. Искореняем привязанность к датам

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

В планах проектов, управляемых методом критической цепи, приводятся только даты начала цепочек работ и дата окончания буфера проекта. В остальном же даны приблизительные даты начала работ и оценочная длительность каждой. Менеджеры, управляющие своим проектом по методу критической цепи, не критикуют исполнителей, нарушивших сроки, если те, во-первых, принялись за работу, как только получили результаты предыдущего этапа; во-вторых, 100% времени уделяли одному заданию (не допускали «многозадачности»); в-третьих, сразу же по завершении работы передали результаты на следующий этап. Руководители проектов, использующие ССРМ, готовы к тому, что 50% работ будут идти с опозданием.

Анализ промежуточных результатов практически всех проектов показывает, что исполнители очень редко рапортуют о досрочном завершении работ. Если оценки длительности операций вашего проекта сделаны с 50%-ной долей вероятности, то можно было бы ожидать, что в 50% случаев работы будут выполняться раньше срока. Если оценка сделана с вероятностью 99%, то и в отчетах 99% заданий должны быть помечены как выполненные с опережением графика. Обычно же люди сообщают о выполнении большинства работ точно в срок и о некоторых как завершенных с опозданием. И почему это на проектах не проявляются результаты положительных отклонений?

Причина в том, что в большинстве случаев исполнители блокируют действие положительных отклонений. В работе «Критическая цепь» (Critical

Chain) описаны несколько факторов, обуславливающих систематическое нарушение сроков, даже если изначально у исполнителя был очень хороший запас на непредвиденные обстоятельства. Джек Мередит и Сэмюель Мэнтл [6] пишут: «Действие “законов Паркинсона” — явная и реальная угроза. Работа по проекту практически неизбежно займет все даже дополнительно выделенное время». Выражаясь словами Голдратта, впустую тратится резервное время.

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

Можно найти массу оправданий необходимости придержать полученный до срока результат. Руководство приступит к приемке в последнюю очередь, так как время еще не пришло. Или же исполнитель найдет, что еще улучшить, ведь нет пределов совершенству. Следствие одно: тратится резерв на непредвиденное, включенный в длительность каждой операции.

В главе 3 говорилось о студенческом синдроме (рис. 3.10). Многие склонны не браться за дело до тех пор, пока оно не станет по-настоящему срочным. Это особенно справедливо по отношению к постоянно занятым специалистам, на которых наблюдается большой спрос, — а это наиважнейший ресурс, в котором менеджеры проектов видят гарантию от срыва сроков на критическом пути. Если исполнители считают, что в плановую длительность заложен некий резерв, очень часто, когда приходит пора браться за выполнение задания, у исполнителей появляются другие, более приоритетные дела. Под эти дела тратится резерв на непредвиденные обстоятельства, и приходится затем выполнять большую долю плановых работ, когда срок уже почти истекает.

От такого поведения защищает следующая комбинация приемов: агрессивные сроки (длительность работ, вполовину меньшая первоначальной оценочной), отсутствие точных дат начала и окончания, регулярные оповещения о том, сколько времени осталось на выполнение операции.

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

4.2.4.2. Улучшаем качество работ, устранив многозадачность

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

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

Как показал Голдратт в романе «Цель», оптимизация отдельного участка может негативно сказаться на качестве работы системы в целом. Так, описаны автоматы, которые задействованы постоянно, чтобы получить высокий показатель производительности. В производственных системах в результате скапливаются излишки продукции, а ограничение оказывается занятым в обработке деталей, которые не нужны для выполнения имеющихся клиентских заказов. Растут операционные расходы и время выполнения заказов, и для компании в целом ничего хорошего в этом нет.

При выполнении проектов многозадачность наносит еще больший вред. Представим себе исполнителя, за которым закреплено три задания по трем разным проектам длительностью по неделе каждое (рис. 4.10). Если бы человеку можно было работать сначала исключительно над одним заданием, то результат по первому проекту был бы получен через неделю, по второму — через две, а по третьему — через три. Если же действует модель «многозадачность» и каждый день исполнитель треть времени уделяет каждому проекту поочередно, результаты по всем трем проектам появятся не раньше чем к концу третьей недели. Работа по каждому из трех заданий продлится три недели, что потенциально увеличивает общую продолжительность всех проектов.

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

ССРМ стремится не допускать многозадачности, предусматривая 100%-ную занятость каждого ресурса только на одной операции в один момент времени. Таким образом, при планировании методом критической цепи первоочередной установкой является исключение «частичной занятости людей на проекте». ССРМ также предусматривает постоянное информирование исполнителей, чтобы каждый легко мог определить, над чем ему дальше работать.

Меня часто спрашивают: «Но разве работа над несколькими вопросами одновременно не является нормальной для менеджера?» или «А если так мы застрянем на одной операции?» Отвечая, я поясняю, что бывает и положительная многозадачность. Негативной является многозадачность, которая приводит к увеличению длительности проекта. Сумев поставить дело так, чтобы не допускать негативной многозадачности, вы окажете своей команде большую услугу.

4.2.5. РАННИЙ СТАРТ ИЛИ ПОЗДНИЙ ФИНИШ?

Многочисленный исследования выявили преимущества графиков обоих видов — ранний старт и поздний финиш. Менеджеры проектов считают, что при планировании с ориентацией на ранний старт снижаются риски, так как работы выполняются в самые ранние из возможных сроков. График типа «поздний финиш» отличается тем, что:

• снижает воздействие изменений на результаты уже выполненной работы;

• сдвигает на более поздние сроки денежные расходы по проекту;

• позволяет правильно сосредоточить усилия, поскольку одновременно запускается меньшее число работ, что позволяет команде как следует «разогнаться».

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

В ССРМ по умолчанию предлагается начинать операцию как можно позднее. Буферы на слияние путей дают запас четко высчитанной величины, защищающий весь проект от последствий срыва сроков на какой-либо из последовательностей работ, вливающихся в критическую цепь. Это дает дополнительное преимущество для проекта и обеспечивает защиту графика.

В некоторых проектах ряд операций необходимо начинать как можно раньше для снижения рисков. Пример — проекты по обновлению или ремонту сложных систем (таких как корабли и пр.). Обычно сначала, пока не произведена диагностика, ни у кого нет четкого представления о том, какие именно работы предстоят. Есть смысл осуществить диагностику как можно раньше в самом начале проекта, ведь может обнаружиться необходимость в очень длительных процедурах или материалах с большим сроком поставки. При планировании необходимо закладывать проведение таких операций на самых ранних сроках проекта.

Мне часто задают вопрос: «Что плохого в раннем начале работ, если есть кому работать?» Я отвечаю так: если вы понимаете теорию и видите, что вреда не будет, пожалуйста, начинайте раньше. Теория ограничений предполагает, что люди пользуются своими знаниями.

4.3. Получаем максимум из плана, управляя при помощи буферов

Результаты оценки хода работ заставляют вас предпринимать действия, приближающие систему к цели. В книге «Синдром стога сена» (The Haystack Syndrome) Голдратт отмечает [7]:

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

На рис. 4.11 дан алгоритмизированный вид процесса оценки, предложенный Джураном. Датчик в блоке 2 производит измерения. Процессор (блок 4) сравнивает показания датчика результатов процесса с заданной целью. Процессор принимает решение о действиях, необходимых для корректировки результата и уменьшения расхождения с целью. Так работают любые системы контроля. Это задача системы оценки реализации проекта, где под целью, которую нужно достичь, понимается соблюдение технических требований к продукту, бюджета и графика проекта.

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

Усовершенствованная система оценки ССРМ следует порядку, введенному Голдраттом для производственных систем. Для оценки состояния дел по выполнению последовательности работ используются буферы (то есть время). Размер буфера задается в соответствии с длиной цепи, которую он призван защищать. При формировании буфера проекта учитывается неопределенность длительности операций, находящихся в критической цепи. Аналогично величина буферов на слияние путей высчитывается с учетом неопределенности данных о длительности работ в цепочках, вливающихся в критическую цепь. ССРМ задает четкие границы для принятия решений различного уровня. Тип решения определяется остаточной величиной буфера и процентом пройденной критической цепи. В разделе 6.4.3 подробно говорится о границах принятия решений по буферу. Буфер условно делится на три части:

1) зеленая зона — действий не требуется;

2) желтая зона — оцените проблему и спланируйте действия;

3) красная зона — действуйте.

Таким образом измеряется и оценивается и проектный буфер, и буфера на слияние путей. На рис. 4.12 дан пример использования буферов.

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

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

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

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

4.4. Некоторые понятия РМВОК

Сами по себе уникальные свойства ССРМ недостаточны для создания системы управления проектом, удовлетворяющей всем описанным ранее требованиям. Думаю, руководство РМВОК описывает все, что еще необходимо для соответствия всем параметрам. Вслед за Джураном я составил матрицу свойств и требований, чтобы проверить, составляют ли элементы ССРМ и РМВОК в совокупности весь тот необходимый набор характеристик, отличающих удовлетворяющую всем требованиям систему управления проектом. Таблица получилась слишком большой, чтобы публиковать ее в книге. Но с ее помощью я выявил те описанные в РМВОК компоненты, которые в первую очередь необходимы, чтобы проектная система соответствовала параметрам из таблицы 4.1.

Подобная таблица соответствий помогает выявить требования к каждой из обязательных характеристик, что позволяет их развивать и совершенствовать.

Понятия, перечисленные далее, в большинстве своем описаны в РМВОК и обязательны для соответствия системы управления проектом упомянутым ранее требованиям.

4.4.1. УСТАВ ПРОЕКТА

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

4.4.2. ПЛАН УПРАВЛЕНИЯ ПРОЕКТОМ

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

4.4.2.1. Иерархическая структура работ

В ходе составления иерархической структуры работ (ИСР) определяются границы содержания проекта. Содержание проекта представляется в виде иерархических уровней — от общего результата проекта до отдельных рабочих заданий или пакетов работ. Составление ИСР обычно заканчивается на таком уровне детализации, когда каждую отдельную операцию (либо пакет работ) можно назначить определенному ресурсу для исполнения, а в совокупности все операции при исполнении позволяют выполнить общее проектное задание.

4.4.2.2. Роли и обязанности

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

4.4.2.3. График ключевых событий

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

4.4.2.4. Пакеты работ

Пакеты работ, составляют в ИСР план самого низшего уровня, позволяющий в совокупности выполнить проект. Обычно в пакет работ входит описание задач или необходимых результатов для данного пакета работ и план по достижению результатов. В плане определяются операции, логика выполнения этих операций и связи операций из данного пакета работ с другими элементами проекта, как правило, с контрольными событиями из расписания контрольных событий. Могут быть установлены связи и с операциями в других пакетах работ, но обычно в первой версии описания пакетов работ это не указывается, поскольку все пакеты разрабатываются одновременно. Кроме того, приводится оценочная длительность операций и требования по ресурсам, все допущения и предположения, учитывавшиеся при проведении оценки.

4.4.2.5. Сетевая диаграмма проекта

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

4.4.3. ОЦЕНКА И КОНТРОЛЬ ВЫПОЛНЕНИЯ ПРОЕКТА

ССРМ предлагает усовершенствованную технику оценки и контроля выполнения графика. В большинстве проектов также необходим процесс технического контроля качества, и во многих требуется механизм контроля затрат.

Матрица соответствий также определяет потребность в процессе непрерывного совершенствования и обеспечения качества итогового продукта проекта. В задачи данной книги не входит подробное рассмотрение процесса обеспечения качества продукта. Описание такого процесса дает Льюис Айланд [8].

4.4.4. УПРАВЛЕНИЕ ИЗМЕНЕНИЯМИ В ПРОЕКТЕ

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

4.4.5. УПРАВЛЕНИЕ РИСКАМИ В ПРОЕКТЕ

Управление рисками направлено на особые причины потенциальной вариабельности. Поскольку в РМВОК не проводится разграничения между общими и особыми причинами отклонений, вы увидите, что работа с вариабельностью обоих типов идет в рамках управления рисками. ССРМ строит управление проектом с учетом общих причин вариабельности, а особые причины остаются на долю управления рисками (смотрите главу 10).

4.5. Итоги

В этой главе мы рассмотрели требования к системе управления проектом и увидели, какие элементы ССРМ и РМВОК обеспечивают соответствие этим требованиям. Основные свойства получившейся системы следующие:

• критическая цепь показывает ограничение проекта;

• при максимальном использовании критической цепи применяется управление неопределенностью, выражающееся в сокращении плановых длительностей работ и добавлении проектного буфера;

• для максимального использования возможностей критической цепи исполнитель должен знать, над каким следующим заданием он будет работать. Этого можно достичь, создавая списки приоритетов работ, графики работ для определенного исполнителя или «оповестительные флаги»¹³;

• потребностям критической цепи должны быть подчинены все вливающиеся в нее цепочки работ и темпы работы исполнителей, для этого вводится буфер на слияние путей;

• в ССРМ для контроля выполнения в первую очередь используют управление с помощью буферов;

• чтобы система управления проектом соответствовала всем необходимым требованиям, нужно использовать ряд параметров, описанных в РМВОК.

Этот перечень является необходимым и достаточным для того, чтобы система полностью удовлетворяла заявленным требованиям.

ЛИТЕРАТУРА

1. Juran, Joseph J., Juran on Planning for Quality, New York: The Free Press, 1988.

2. Popper, Karl R., Objective Knowledge, An Evolutionary Approach, Oxford: Clarendon Press, 1979 (в русском переводе: Поппер К.Р. Объективное знание. Эволюционный подход. — М.: Эдиториал УРСС, 2002).

3. Shewhart, Walter A., Statistical Method from the Viewpoint of Quality Control, New York: Dover Publications, 1986 (впервые опубликовано в 1939 году).

4. Kiley, Martin D., 1997 National Construction Estimator, Carlsbad, CA, Craftsman Book Company, 1996.

5. Moore, David S., George P. McCabe, Introduction to the Practice of Statistics, New York: W.H.Freeman & Co., 1993, р. 398.

6. Meredith, Jack R., Samuel J. Mantel, Project Management, A Managerial Approach, New York: John Wiley and Sons, Inc., 1995.

7. Goldratt, Eliyahu M., The Haystack Syndrome, Croton-on-Hudson, NY: North River Press, 1990.

8. Ireland, Lewis R. Quality Management for Projects and Programs, Upper Darby, PA: PMI, 1991.

Глава 5. Запуск нового проекта

5.1. Процесс инициации проекта

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

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

РМВОК [1] разделяет процессы инициации и процессы планирования. В данной главе мы оба типа процессов рассматриваем как части процесса запуска-инициации проекта. При таком подходе результатами на выходе процесса будут устав проекта, назначение менеджера проекта, описание ограничений, исходных установок и допущений, а также другие компоненты полного плана управления проектом, включая график работ и бюджет.

5.2. Устав проекта

Устав проекта — краткое письменное заявление о запуске проекта, дающее основание для создания соответствующей проектной команды и начала планирования. Это определение намного шире приведенного в РМВОК и предполагает также, что в устав включаются ответы на шесть вопросов, необходимых для создания плана проекта, — кто делает, что делает, когда, где, как и зачем. Как правило, в уставе должны быть освещены все перечисленные ниже пункты, обозначенные авторами из CH2MHILL [2] как обязательные:

Главное различие между уставом и планом проекта в том, что устав уполномочивает команду приступать к планированию.

5.3. Определение участников проекта

В РМВОК дается следующее определение участников проекта:

«...Лица или организации, активно вовлеченные в проект, или те, чьи интересы могут быть затронуты — в положительном или отрицательном смысле — в ходе или по результатам выполнения проекта; они также могут оказывать влияние на проект и его результаты» (с. 16)¹⁴.

Всем нам хорошо известен пример активного и пассивного участия. Представьте себе яичницу с беконом. Курица — опосредованный, пассивный участник процесса, свинья — непосредственный, активный. Суть определения лиц, заинтересованных в проекте, заключается в том, чтобы все, кто может так или иначе повлиять на проект, с самого начала были активно вовлечены и выразили согласие с планом. Уж слишком часто такие участники проекта, как заказчик или руководство, имеющие непосредственное отношение к успеху всего начинания, ставят себя на позицию судей, а не сподвижников, считая, что не должны играть активной роли в самом процессе достижения результата. Такой путь, вероятнее всего, приведет к провалу. Задача команды — заручиться поддержкой всех, кто потенциально может повлиять на успех проекта, в той степени, что обеспечит достижение результата. Для этого есть много способов. И в первую очередь — удостовериться, что вы определили все заинтересованные стороны и выявили их потребности. Как правило, нужно получить формальное согласие участников как с уставом, так и с планом проекта. В некоторых случаях в роли устава или плана может выступать контракт на выполнение проекта.

5.4. Иерархическая структура работ (ИСР)

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

Хотя идея ИСР проста, я обнаружил, что многие испытывают трудности при составлении этого дерева работ. Думаю, проблема отчасти заключается в склонности человека мыслить в категориях конкретных операций, а не результатов этих операций. Результаты проекта — это все товары и услуги, производимые/появляющиеся в ходе проекта. Чрезвычайно важно, чтобы с самого начала был ясен перечень объектов, оборудования и услуг, которые будут созданы в рамках проекта. (Также очень важно указать, что именно не будет получено в этом проекте, а что появится в результате других, но об этом мы еще поговорим в разделе 5.7.) ИСР — ваш инструмент для систематизации содержания проекта и назначения ответственных за каждый из ожидаемых результатов.

5.4.1. ПОДХОД ТЕОРИИ ОГРАНИЧЕНИЙ

Сторонники ТОС предлагают два способа построения сетевой диаграммы проекта. Большинство опускают этап разработки иерархической структуры работ. Один из способов — дерево перехода (ДП) — можно условно назвать ИСР. Идея заключается в том, чтобы взять конечный или промежуточный результат и спросить участников команды: «Что мешает нам получить этот результат?» Как только составлен список препятствий, вы просите команду перечислить условия преодоления этих препятствий. Затем эти условия выстраиваются в логическую цепочку. Такой метод представляет последовательную стратегию и согласованную тактику преодоления проблем, выявленных командой. Для больших проектов можно создавать ДП разных уровней — по аналогии с уровнями иерархии в ИСР.

К сожалению, упрощенный метод построения ДП, описанный Голдраттом в романе «Дело не в везенье!» [3], не подходит для разработки ИСР проектов. Дело в том, что ДП позволяет только обеспечить выполнение условий преодоления препятствий, выявленных командой. Этот метод не отслеживает достижение всех промежуточных результатов, необходимых для получения конечного продукта проекта. Детмер [4] модифицировал метод так, чтобы он охватывал и необходимые, и достаточные условия успешного завершения проекта.

Второй подход, предлагаемый в ТОС, основан на обратном планировании. Рассматриваем последовательно все планируемые результаты проекта и к каждому задаем вопрос: «А какие исходные нам нужны, чтобы получить на выходе этот результат?» Так продолжается до тех пор, пока не достигается уровень операций, для которых уже не нужны никакие особые входные данные.

У обратного планирования есть несколько недостатков:

• не всем удобно думать «задом наперед», из конца в начало;

• компьютерные программы спроектированы по логике «сверху вниз и слева направо» (прямое планирование). Построить правильную диаграмму проекта методом обратного планирования в таких программах будет непросто. (Я предпочитаю помогать команде с разработкой подобных диаграмм, отображая процесс с помощью компьютера и проектора);

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

Однако для многих метод обратного планирования удобен и обеспечивает включение в диаграмму операций, необходимых для получения всех запланированных результатов. Этот подход хорош для небольших проектов и для детализации операций в пакетах работ по крупным проектам. Однако обычно сам по себе он не заменяет полноценной иерархической структуры работ, особенно когда дело касается крупных проектов.

5.4.2. ТРАДИЦИОННАЯ ИСР

Есть ряд полезных стандартов, которые помогут вам с разработкой ИСР. Один из них сравнительно недавно выпущен PMI [5], а наиболее полный предложен министерством обороны США [6]. Харольд Керцер приводит следующие критерии хорошей ИСР [7]: «Менеджер проекта должен разбить работу на мелкие элементы, которые:

• управляемы, на них можно назначить исполнителя либо ответственного;

• независимы или имеют минимальную зависимость от других событий;

• интегрируемы, то есть представляют часть общего пакета работ;

• измеримы, то есть можно оценить степень их выполнения.

Правильная ИСР обеспечивает следующее:

• лучшее понимание объема работ;

• планирование всех работ;

• выявление конечных продуктов и результатов;

• последовательную детализацию работ;

• соотнесение отдельных рабочих заданий с общими задачами проекта;

• назначение ответственных за весь объем работ;

• оценку сроков и затрат;

• планирование и распределение ресурсов компании;

• интеграцию содержания, графика и бюджета;

• отслеживание расходов, графика и качества выполнения технических требований;

• систематизацию и обобщение информации для руководства и отчетности, возможность проследить картину по разным уровням детализации;

• управление изменениями.

В ИСР обычно выделяются определенные уровни, например:

Уровень 1: программа в целом.

Уровень 2: суммарные статьи расходов.

Уровень п-1: пакет работ.

Уровень п: операция».

В некоторых случаях в эти слова вкладываются разные значения. Например, зачастую пакеты работ оказываются наименьшим уровнем при распределении задач, и ограничивающим критерием является привязка определенного ресурса (рабочей силы) к одному пакету работ.

В ИСР также используется система нумерации, при которой каждая операция получает уникальный идентификатор. Номера назначаются в соответствии с уровнем в иерархии. Расходы отслеживаются по каждому из номеров самого нижнего уровня.

Менеджеры проектов по-разному подходят к созданию ИСР для целого проекта. Самый предпочтительный путь — строить ИСР, исходя из результатов проекта. При таком способе в рамках каждого пакета работ производится определенный измеримый продукт. На более верхнем уровне разбиение может быть по функциональным направлениям или по основным видам оборудования (включая производственные мощности), подсистемам или системам.

Самым важным требованием к иерархической структуре работ является требование полноты. Поскольку ИСР выступает основой для планирования и оценки расходов, нельзя ничего упустить. При этом, если решение о финансировании проекта будет приниматься исходя из оценки затрат, в ней ни в коем случае не должно быть ничего лишнего.

Во многих компаниях для создания ИСР по однотипным проектам используются шаблоны. Шаблон может служить хорошей подсказкой для начала работы над ИСР. Однако у них есть один недостаток, общий для всех типовых заготовок: тенденция такова, что человек, использующий их, успокаивается и часто не задумывается ни над чем за рамками этих шаблонов. Менеджер проекта должен зафиксировать в ИСР все необходимые работы и не допустить, чтобы типовые формы ограничивали его мышление.

Иногда клиенты (особенно правительство) задают свой вид ИСР, обычно потому, что им необходимо сравнивать проекты разных подрядчиков или по разным типам закупок. Требование клиента — закон. И даже в этом случае менеджер проекта должен поместить в заданной ИСР полный объем работ, не допуская ничего лишнего, и правильно назначить ответственных.

5.4.3. ОРГАНИЗАЦИОННАЯ СТРУКТУРА ПРОЕКТА

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

Есть разные способы организации управления проектами в компании. Поскольку мало какому проджект-менеджеру выпадает счастливая возможность перестроить под свой проект всю организацию, данный способ мы рассматривать не будем. Как правило, руководителю дается определенная свобода действий в создании ИСР, подборе команды и распределении полномочий и обязанностей.

Деминг советовал за основу создания структуры организации брать процессы этой организации. Предлагаю аналогичный подход использовать при выстраивании команды: ориентироваться на ИСР. Или же можно назначить ответственных за критическую цепь и за каждую вливающуюся в нее последовательность работ. Но поскольку вряд ли ИСР будет построена подобным образом, обязанности членов проектной команды и руководителей пакетов работ могут пересекаться. Команда управления проектом также должна обеспечить точность и правильность взаимосвязей между пакетами работ и операциями, и это наиболее уязвимое место любого проекта.

5.5. Назначение ответственных

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

Такая матрица удобна для чтения (то есть лишь в некоторых ячейках на пересечении будут стоять отметки), если по каждой работе из ИСР ответственным назначается конкретный человек. В проектных структурах разумных размеров такая таблица будет слишком большой, ее трудно использовать и поддерживать в актуальном состоянии при изменениях организационной структуры компании.

Более удобный вид матрицы — линейная. В первой колонке перечислены компоненты ИСР, во второй — лицо (а не подразделение), ответственное за каждый компонент, и в остальных можно писать все, что нужно. Создавать и вести такую матрицу легко. Ее удобно смотреть на компьютере, а можно распечатать и подшить к остальным планам, чтобы все могли пользоваться. Матрица может содержать и гораздо больше информации. Табл. 5.1 — пример такой простой матрицы.

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

5.6. Последовательность контрольных событий

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

Эффективный способ выстроить логичную картину — определить основные фазы проекта, или ключевые события. На рис. 5.2 дан пример схемы контрольных точек. У каждого ключевого события должен быть свой определенный результат. В диаграмме контрольных событий даты не указываются. Ведь даты вычисляются в результате составления графика, а не задаются как исходные условия для его создания (исключение — проекты с жестко установленной датой окончания, такие как подготовка коммерческого предложения, проведение мероприятия, Олимпийские игры-2004 в Афинах).

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

Схему расположения контрольных точек можно также использовать как вспомогательный инструмент для оценки реализации проекта. Многие организации устанавливают точки принятия решений, по которым организуется анализ состояния дел по проекту. Например, завершение проекта системы, или первое тестирование прототипа в проектах по разработке компьютерных систем, или эскизный проект в строительстве. Такие контрольные точки могут попадать и в критическую цепь проекта. Руководство и заказчики любят ориентироваться на ключевые события как на показатель степени успешности реализации графика проекта. Если в своем плане вы помещаете контрольные точки на критической цепи, маловероятно, что они будут достигнуты точно в запланированный срок. Тот, кто еще не освоил концепцию критической цепи, неверно растолкует данные о ходе выполнения работ. В таком случае советую добавить буфер на каждое ключевое событие и называть плановую дату с учетом резервного времени из буфера. Образец приведен на рис. 5.3. Контроль за проектом все равно должен осуществляться по состоянию общего проектного буфера.

5.7. Пакеты работ

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

Формат документации по пакетам работ напрямую влияет на качество и удобство проведения процесса планирования. Тут большинство технических специалистов начинают сетовать на чрезмерные объемы бумажной работы. Процесс описания пакетов работ должен быть прост и удобен для исполнителей. На рис. 5.4 дан пример документа, описывающего логику расположения операций — это важнейшая составляющая пакетов работ. Вместе с перечнем установок и результатов (содержания проекта) она послужит исходной информацией для создания плана проекта.

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

5.7.1. ИСХОДНЫЕ УСТАНОВКИ

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

5.7.2. ДИАГРАММА ПРОЕКТА

Самой важной составляющей описания пакета работ является схема расположения операций. Обратите внимание, в этой диаграмме нет точных дат. Даны длительность операции, ее место в структуре работ и перечень требований по ресурсам для выполнения этих работ. Одна из причин отсутствия дат в диаграмме заключается в том, что мы не можем определить даты, пока не будет готова полная картина проекта и найдена критическая цепь. Указание дат может помешать программе правильно вычислить критическую цепь или путь. Кроме того, вероятность точного соблюдения дат, назначенных для отдельной операции, равна нулю, поскольку при реализации всех операций бывают отклонения, а предсказать величину статистических колебаний по одному событию невозможно. Компьютерная программа посчитает даты раннего и позднего начала и окончания каждой операции. Но вы не должны обращать внимания на эти даты. Я вообще не использую колонки «Начало» и «Окончание» для отдельных операций.

Мне встречались случаи, когда схему операций отдавали в руки финансовым службам, которые верстали по ней бюджет. Аналогично планировщики сами по себе должны были составлять расписание, а потом думать, как соотнести между собой разные составляющие. Используйте описание пакета работ как есть, и пусть компьютер рисует график и делает разбивку по бюджету. Даты выполнения работ и таблицы бюджета должны быть результатом создания единой картины расписания и затрат, а не исходными данными для нее. Конечно, при управлении с помощью критической цепи нас и не интересуют даты отдельных операций. Значение имеет лишь дата начала последовательностей работ и дата завершения всего проекта.

5.7.2.1. Логика проекта

Чтобы достичь цели проекта, необходимо выполнить ряд работ в определенной последовательности. Это и есть логика проекта. Каждый пакет работ — это просто маленький проект со своей логикой. Операции должны быть спланированы так, чтобы результат одной служил материалом для другой. Каждую операцию можно рассматривать как процесс с материалом на входе, преобразующимся в результат на выходе. Проектные операции соответствуют модели SIPOC из TQM: поставщик — исходный материал на входе — процесс — результат на выходе — клиент. Поставщик здесь — менеджер предшествующей операции. Клиент — менеджер последующей операции. Затем при помощи контрольных точек и связей между операциями определяются взаимосвязи между пакетами работ.

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

• Финиш-старт, часто называется также отношениями предшественника и последователя. Результат одного процесса является необходимым исходным материалом для следующего. Большинство операций в диаграмме проекта должны быть связаны именно таким образом.

• Старт-старт (с запаздыванием) — эта связь устанавливается, когда две операции могут выполняться одновременно. При этом сначала в ходе первой производится некий объем продукта, который может далее обрабатываться на второй. Например, вам нужно пропустить множество экземпляров продукции через три последовательных этапа. Вместо того чтобы запланировать три этапа для каждого экземпляра отдельно, мы делаем всего три операции типа «операция 1 для 100 экземпляров», «операция 2 для 100 экземпляров» и так далее, намечая начало каждой с отставанием на срок, равный обработке одного экземпляра на предыдущем этапе.

• Финиш-финиш — этот вид связи используется, когда операции должны завершиться одновременно, хотя начинаться могли в разное время. Например, одновременно должна завершиться выверка перекрестных ссылок в разных главах книги.

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

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

За исключением случаев с заданными неизменными величинами (например, дата начала готовности стадиона к Олимпиаде или доступные объемы финансирования), четкие даты должны быть результатом создания диаграммы проекта, а не исходной информацией. Не загоняйте отдельные операции в рамки точных дат. Укажите связи, и пусть программа сама все считает. Запомните: бессмысленно назначать конкретные даты для каждой операции проекта, точность этих дат равна нулю.

Логику проекта нужно выверить по следующим пунктам.

• Определены ли результаты каждой операции?

• Действительно ли предшествующая операция необходима для начала последующей?

• Достаточно ли предшествующей операции для начала последующей?

• Обеспечивают ли указанные операции достижение запланированных результатов проекта (по сравнению с заданными в ИСР)?

• Указаны ли ресурсы, необходимые для выполнения каждой операции?

• Не введены ли ненужные ограничения (даты) операций?

• Все ли контрольные точки (из схемы ключевых событий) попали в план?

• Если длительность операции зависит от исполнителя, предусмотрена ли 100%-ная занятость данного исполнителя на данной операции?

• Все ли последовательности работ сходятся воедино к концу проекта? Если нет, объедините их хотя бы в контрольной точке «проект завершен».

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

5.7.2.2. Назначение ресурсов в диаграмме проекта

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

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

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

Метод эстафеты, используемый в ССРМ, подразумевает, что тех, от кого зависит длительность операции, вы назначаете только на выполнение данных работ. Занятость остальных можно расписать в разных долях, однако помните, что при выравнивании ресурсов результат может оказаться неожиданным. Компьютерная программа производит выравнивание по определенному алгоритму. Некоторые параметры этого алгоритма можно изменять, но затем программа будет неуклонно следовать заданным вами правилам. Так, если у вас есть исполнитель, временем которого вы можете распоряжаться на 100%, и вы назначаете его на две операции по 49% времени на каждую, при составлении графика компьютер может заложить параллельное выполнение этих операций. А если установите занятость 51%, программа вообще может спланировать начало второй операции только после завершения первой. (В некоторых программах можно производить выравнивание по задаваемым пользователем единицам времени, например дням, неделям или месяцам. Таким образом, сдвинется ли операция после выравнивания, будет зависеть от ее длительности, места в графике и загрузки исполнителя.) На рис. 5.5 приведен пример потенциальных неожиданных последствий выравнивания ресурсов. Что-то подобное наблюдалось на одном из проектов, где использовался метод критической цепи. Технари заявили, что ошибка в логике. Нет, с логикой все в порядке. Компьютер работает так, как его запрограммируют. В этом случае, вероятно, не следовало назначать ресурсы на операцию «проверка документа», если не предусматривалась полная занятость исполнителей на данной операции. В большинстве программ существует возможность вставлять примечания по каждой операции, где и можно было бы указать, кто будет проводить проверку. Обычно, экспериментируя в ходе работы, можно определить оптимальный способ моделирования загрузки по ресурсам в конкретных планах ваших проектов.

5.7.2.3. Степень детализации плана

Многие планы проектов состоят из тысяч операций. Некоторые — из десятков тысяч. Обычно рекомендации по количеству строчек в плане сводятся к тому, чтобы разбивать операции на подоперации с минимальной длительностью. Тогда можно будет отчитываться конкретно о завершении операций, а не пытаться оценить процент выполненных работ или времени, оставшегося в запасе. Если же вспомнить смысл составления плана и положения теории ограничений, то станет ясно: детализация должна быть такой, какая необходима для успешной реализации проекта, не больше и не меньше. Обычно каждая операция в проекте должна быть, по сути, передачей определенного продукта от одного исполнителя или группы исполнителей другому.

План проекта не заменяет собой детальной информации о дизайне продукта. Есть много способов сделать ссылки на нее в плане проекта: ИСР как файловая структура, примечания, гиперссылки в программе, в которой вы создаете график проекта (если в ней есть такая возможность). Не поддавайтесь искушению, используйте программу для созданию графика проекта по ее прямому назначению. В самом общем виде план не должен включать более пары сотен операций. В крупных проектах должна быть своя иерархия планов, каждый из которых опять же будет размером не более нескольких сотен строк. В таком случае необходимо связать планы разных уровней — начиная с проектного буфера плана низшего уровня.

Первоочередная причина, по которой следует ограничить количество операций в плане проекта, — неопределенность. Когда план слишком подробный, нужно больше сил на его создание и поддержание. Также возрастает вероятность ошибок в плане. Мало кто может понять план, в котором больше ста записей, даже если тщательно изучит его. С увеличением числа операций в плане количество связей между ними растет в геометрической прогрессии. Поэтому даже в плане из сотни операций вряд ли будет все правильно.

Рассмотрим тот факт, что средняя величина операции в плане (затраты на нее в долларах, длительность выполнения или время работы исполнителей) обратно пропорциональна количеству операций. Следовательно, средняя операция в плане из 100 операций составляет 1% от всего проекта. Поскольку параметры большинства операций нельзя оценить точнее, чем с вероятностью плюс-минус 50%, нет смысла делить проект на более мелкие составляющие.

Часто говорят, что недостаточно подробный план становится причиной провала проекта. Но когда проект заканчивается неудачно, речь идет о гораздо больших величинах, чем доли процента (так, затраты могут превышать плановые в два-три раза). Не логично заключать, что план, в котором 100 или чуть больше операций, недостаточно подробен и приведет к проблемам. Вряд ли вы обнаружите недостающие для полного счастья работы, нехватка которых привела к нарушениям на сотни процентов от нормы, если будете дробить далее операции, равняющиеся всего 1% от всего проекта. Проблема не в этом. И решение тоже.

Чем больше операций вы включаете, тем больше усилий тратится на составление плана. Если определенное количество усилий тратится на большее количество операций, значит, на каждую из них уйдет усилий меньше. А значит, и план будет менее точным, а не наоборот. Раз вы можете позволить себе потратить на составление плана больше усилий, стоит направить их на связки между операциями, проверить, все ли «входы-выходы» учтены правильно, посмотреть данные по исполнителям и рабочим процессам выполнения операций, а не добавлять в план новые записи.

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

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

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

5.7.3. ОЦЕНКА ДЛИТЕЛЬНОСТИ ОПЕРАЦИИ

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

Важно удостовериться, что оценка производилась, исходя из 100%-ной загрузки исполнителя. Если это не так, сократите длительность, не меняя при этом объем работ в человеко-часах или человеко-днях. Иными словами, если на выполнение операции требуется 50% времени одного инженера в течение 10 дней, спланируйте работы на 5 дней при полной занятости на них этого инженера.

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

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

5.7.4. И СНОВА ПРО НЕОПРЕДЕЛЕННОСТЬ

Проблема неопределенности в оценках ставит менеджеров проектов перед дилеммой. Руководство и заказчики гнут свою линию, заявляя: «Если точность показателей ниже х%, значит, вы плохо провели оценку!» Людям свойственно иметь неоправданно высокое мнение о своих прогнозах.

Далее мы будем говорить о неопределенности показателей затрат и длительности операций как о взаимозаменяемых величинах. Мы считаем, что работа, выполненная людьми или иными ресурсами (например, арендованным оборудованием), оплачивается в расчете за единицу времени, то есть затраты равняются ставке, умноженной на время использования. Следовательно, степень неопределенности общей величины затрат — то же самое, что степень неопределенности величины времени использования. Аналогичным образом, поскольку общий объем работ — это нормированный объем работ в час, умноженный на время, то неопределенность выполненного объема работ прямо пропорциональна неопределенности затрат.

Проект по определению своему — нечто уникальное. Поэтому зачастую не хватает статистических данных, чтобы оценить степень неопределенности наших представлений о параметрах проектных операций. Подумайте, что нам известно о неопределенности. Попросите, чтобы кто-нибудь оценил постройку нового дома. У вас сразу же попросят спецификации. В Соединенных Штатах сегодня дом может потребовать вложений как в 80 000, так и в миллионы долларов. Определяющая характеристика — месторасположение дома. Второй по важности параметр — размер. И даже когда эти показатели определены, в ценах за квадратный фут может быть значительный разброс в зависимости от метода возведения, типа внутренней отделки и так далее. Разумеется, и у домов, одинаковых по расположению и другим характеристикам, цена может расходиться на 10%, в соответствии с тем, сколько продавец вложил в этот дом, насколько покупатель хорош в ведении переговоров, какова средняя рыночная стоимость жилья в данной местности, каковы мотивы продавца и пр.

Поэтому однозначно оценить дом мы не можем. А сколько стоит машина? Ситуация та же. Даже две абсолютно одинаковые машины у двух дистрибьюторов в одном и том же городе могут различаться в цене на 10%.

В одном бестселлере по управлению проектами (о названии которого из соображений гуманности умолчу) говорится: «Сначала прикидываем лишь порядок величин, для такой оценки — в первом приближении — не нужны никакие технические подробности. Точность анализа в целом может составлять плюс-минус 35%». (Я думал, под «порядком величины» подразумеваются десятки. Увы.) Через несколько предложений идет следующий текст: «Определенная оценка, также называемая детальной, имеет степень вероятности плюс-минус 5%». Минуточку! Мы же только что видели с вами, что фактические затраты на реальный автомобиль известной марки серийного, так сказать, производства, то есть на идентичные объекты могут в одном и том же месте в одно и то же время расходиться на величину, вдвое большую. Как можно ожидать, что оценка чего-то малоизведанного будет вдвое более точной?

Другой источник утверждает, что в проектах, где риски невелики, оценки пакетов работ имеют неопределенность 2%, операции — 5%, группы операций — 10%, проект в целом — 20%, а программа — 35%. Иными словами, утверждается, что при сложении отдельных оценок с низкой степенью неопределенности мы в итоге получаем большую неопределенность. Автор просто перечеркнул законы статистики! (Может быть, по ошибке данные привели в обратном порядке?)

Интересно отметить, что во многих трудах по управлению проектами повторяются одни и те же данные о степени точности оценок затрат. Однако никто нигде не указывает источник этих данных. Единственная ссылка — на руководство по оценке затрат в строительстве, где приводятся показатели вероятности оценок, не вполне соответствующие упомянутым выше положениям о точности оценки проектов и программ. Так, «Государственное руководство к составлению смет в строительстве» (National Construction Estimator) [8] утверждает:

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

Естественно, в других проектах, таких как научно-исследовательские разработки или создание ИТ-систем, степень неопределенности намного выше, чем при строительстве с подробнейшими спецификациями.

И наконец, мне не удалось найти ни одной книги, где бы давалось операциональное определение понятию «точность» именно с использованием амплитуды «плюс-минус 35%». Можно было бы предположить, что это величина стандартного отклонения, что это «граничная точка» или число с вероятностью 99%, если брать нормальное распределение, что, вероятно, будет неправомерно по отношению к оценке затрат. (Если не ошибаюсь, по данному определению точность составит плюс-минус 115%. Нет, ну минус-то уж точно быть не может!) Одинаковый ли смысл мы вкладываем в слово «точность»?

Всем нам известны примеры проектов, завершившихся с превышением первоначального графика и бюджета в два-три раза (см. главу 1). Приходится слышать и о совсем безрезультатных начинаниях, замерших на полпути, как только закончились отпущенные на них средства. В первую очередь на ум приходят крупномасштабные многомиллионные правительственные инициативы, однако та же участь не минула и многие большие коммерческие проекты. Свидетельствует ли это о систематической склонности недооценивать параметры проектных работ?

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

Если для участников проекта характерны модели поведения, описанные в главе 2, положительные колебания проявить себя не смогут. Одна задержка на критической цепи — и сорван срок всего проекта. Кроме того, поскольку расходование средств идет по принципу «все или ничего», увеличение длительности работ приведет к превышению бюджета. Учитывая все вышесказанное, превышение будет значительным. Такие перерасходы не являются частью новой парадигмы управления проектами методом критической цепи, поскольку ССРМ искореняет причины превышения плановых показателей.

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

5.8. Буфер на затраты

Если затраты — значимая для вас категория, то в плане управления проектом должны быть указаны результаты их оценки, а также буфер на затраты. Размер буфера определяется с учетом рисков, определенных для данного проекта, и степени точности оценки. Если для вычисления расходов вы пользуетесь компьютерной программой, не забывайте, что каждая операция оценена с вероятностью 50/50%. Будьте готовы к тому, что в ходе проекта израсходуется немалая часть общего проектного резерва и буферов на слияние путей. Величину расходовании тоже нужно оценить. Это ваш «затратный буфер».

Как уже говорилось, лучше всего создавать общий временной буфер проекта. Аналогично предпочтительней будет использовать и единый обобщенный буфер на затраты проекта. Мы получаем преимущество статистическое (от независимых оценок) и психологическое (оценки не завязаны на конкретные операции).

В работе «Нормирование размера буферов времени и затрат: как справиться с расхождениями между планом и фактом» (Schedule and Cost Buffer Sizing: How to Account for the Bias between Project Performance and Your Model) [9] я подробно описываю два типа неопределенности, с которыми необходимо считаться:

1) вызванные особыми причинами отклонения, которые просто суммируются;

2) статистические колебания вызванные общими причинами вариабельности, квадрат суммы которых исчисляется как сумма квадратов каждого отдельного отклонения рассматриваемых показателей затрат.

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

М.Р. Виджер и А.В. Карк [10], проведя недавно исследование проектов по разработке программного обеспечения, заметили:

«Среди изученных нами был ряд крупномасштабных проектов длительностью более четырех лет с трудозатратами более чем 100 человеко-лет. И во всех без исключения случаях плановые показатели расходов были чрезвычайно занижены».

Они приводят следующие причины.

• В крупных системах с появлением нового элемента все усложняется в геометрической (а не линейной) прогрессии.

• Чем крупней система и чем больше срок получения результата, тем сложнее в самом начале проекта точно и полно определить все требования к результату. В больших проектах — большие перерасходы.

• Чем больше промежуток между формулировкой первых требований и получением результата, тем выше вероятность изменения требований. Это может произойти по причине изменения потребностей пользователей, перемен в будущей рабочей среде системы, появления новых специалистов с иным пониманием требований к системе.

• Когда проект долгий, развитие технологий может сделать неактуальными первоначальные требования.

Думаю, большинство из перечисленных причин характерны не только для ИТ-проектов. Помните о них, когда будете прикидывать размер буфера на затраты, чтобы он покрывал возможные отклонения от оценочных величин. Определение величины буфера на затраты описано в разделе 6.5.

5.9. Оценка затрат

Принципы проведения оценки затрат должны быть указаны в описании пакетов работ. Это чрезвычайно важно для планирования контрактов с возмещением затрат и многих правительственных проектов. Зачастую технические специалисты испытывают трудности с формулировкой принципов собственных подсчетов. Оценить количество необходимых ресурсов — не проблема. А вот объяснить, как они получили ту или иную цифру, никак не получается. Все сводится к маловразумительному объяснению в духе «это экспертная оценка», «на основании имеющегося опыта». Для начала можно спросить, на каких предположениях и допущениях строится оценка.

Профессиональный оценщик без труда продемонстрирует вам принципы получения оценки. Обычно даже не приходится специально просить. Оценщик ссылается на руководства, конкретные случаи из практики, приводит данные от поставщиков или дает иные обоснования своим выводам. Как правило, несложно объяснить, откуда берется цифра по затратам на оборудование (например, 500 футов 4-дюймовых труб по $1,85 за фут — по данным о смете на водопровод, полученным Джимом А. от Джо 15 марта 1996 года). Про составление смет в строительстве, программировании и других специальных областях написаны целые тома. Итак, главная мысль в том, чтобы можно было определить, на чем основана оценка. Тогда впоследствии при необходимости внесения изменений сразу будет видно, что в нее входило, а что нет.

5.10. План управления проектом

План управления проектом, он же план проекта или рабочий план, объединяет в себе все описанные выше компоненты в формате, удобном и доступном для восприятия всем участникам проекта. Это — основа для обмена информацией в рамках проекта. РМВОК приводит следующий перечень задач, которые решает план управления проектом:

• задает направление для проектных работ;

• фиксирует исходные установки, легшие в основу плана;

• содержит задокументированные результаты выбора при наличии различных вариантов;

• служит основой для общения между сторонами в проекте;

• определяет основные моменты для проведения анализа со стороны руководства (суть, содержание, сроки);

• служит основой для оценки хода реализации и контроля за проектом.

В крупных проектах план может включать в себя (непосредственно или в виде ссылки) также другие компоненты:

• предметные планы, например по качеству, безопасности, поставкам, обеспечению персоналом, защите окружающей среды, системному проектированию;

• рекомендации по обмену информацией в проекте, правила отчетности, распространения и согласования документации;

• рабочие процедуры;

• спецификации и стандарты;

• процедуры управления изменениями.

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

5.11. Управление изменениями

Смысл управления изменениями в том, чтобы в проекте происходили только те перемены, которые контролируются проджект-менеджером. Самая важная задача контроля изменений — удостовериться, что все работают по одному и тому же плану, над тем же содержанием и с учетом одинаковых требований к продукту. Кроме того, в рамках процесса управления изменениями необходимо:

• обеспечить, чтобы работы проводились только по согласованным изменениям;

• оценивать последствия изменений — их воздействия на сроки и бюджет (на основании полученных оценок принимается решение о целесообразности внедрения изменений);

• определиться с выставлением счетов клиентам, если запрос на изменения шел с их стороны;

• регистрировать изменения;

• отслеживать ход проекта в сравнении с первоначальным — базовым планом.

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

5.12. Завершение проекта

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

5.13. Итоги

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

• устав проекта как обязательный предшественник удачного плана проекта, обеспечивающий выполнение требований всех участников проекта;

• ИСР, в виде логической схемы представляющая весь объем работ по проекту и дающая основание для распределения ответственности за выполнение отдельных видов работ;

• утвержденный участниками план проекта, в котором определено содержание, график, бюджет, роли и обязанности в проекте;

• диаграмма проекта — представленная в максимально простой форме для успешного выполнения работ;

• правильно составленная логическая последовательность работ с указанием необходимых ресурсов — нужна для разработки расписания проекта;

• даты, являющиеся результатом обработки логической диаграммы проекта, а не исходной информацией для ее создания;

• буфер на затраты как часть результатов оценки расходной части бюджета — если расходы критичны в вашем проекте;

• оценочная длительность работ, полученная путем распределения исходных данных между операциями и буфером проекта;

• процесс управления изменениями (необходим в большинстве проектов);

• этап завершения проекта как часть плана проекта.

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

ЛИТЕРАТУРА

1. PMI, A Guide to the Project Management Body of Knowledge, 2000 Edition Newton Square, PA: PMI, 2000 (в русском переводе: Руководство к своду знаний по управлению проектами/Под. ред. В. Либерзона, Д. Лобанова. — М.: Институт управления проектами, 2004. — редакция 2000 года; Руководство к своду знаний по управлению проектами. — Project Management Institute, 2004. — редакция 2004 года).

2. CH2MHILL, Project Delivery System: A System and Process for Benchmark Performance, Denver, CO: CH2MHILL, 1996.

3. Goldratt, Eliyahu M., It’s not Luck, Great Barrington, MA: North River Press, 1994 (в русском переводе: Голдратт Э. М., Кокс Д. Цель. Процесс непрерывного улучшения. Цель-2. Дело не в везенье. — Киев—Москва: Максимум, Логос, 2007).

4. Dettmer, H. William, Eliyahu M. Goldratt’s Theory of Constraints, A Systems Approach to Continuous Improvement, Milwaukee, Wisconsin: ASQC Press, 1997 (в русском переводе: Детмер У. Теория ограничений Голдратта: Системный подход к непрерывному совершенствованию. — М.: Альпина Бизнес Букс, 2007).

5. PMI. Practice Standard for Work Breakdown Structures. Newton Square, PA: PMI, 2001.

6. U.S. Department of Defense, DoD Handbook — Work Breakdown Structures. MIL-HDBK-881, 1998, доступна по адресу http://dcarc.pae.osd.mil/881handbook/ milhdbk 881_cover_chap1.pdf (материал для книги взят 24 мая 2004 года).

7. Kerzner, Harold, Project Management, A Systems Approach to Planning, Scheduling, and Controlling, 4th ed., New York: Van Norstrand, 1992.

8. Kiley, Martin D. and Marques Allyn, 1997 National Construction Estimator, Carlsbad, CA, Craftsman Book Company, 1997.

9. Leach, L. “Schedule and Cost Buffer Sizing: How to Account for the Bias between Project Performance and Your Model,” Project Management Journal, Vol. 34, No. 2, June 2003.

10. Vidger M.R., and A.W. Kark, “Software Cost Estimation and Control,” NRC-CNRC (National Research Council Canada), NRC No. 37166, February 1994.

Глава 6. Создание плана отдельного проекта по методу критической цепи

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

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

6.1. Процесс

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

Очень полезно построить несколько графиков вручную, ведь тогда вы лучше поймете, какую проблему призван решать компьютер. Кроме того, получив неожиданные результаты машинных вычислений, вы сможете разобраться, откуда они взялись.

1. Найдите критическую цепь.

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

1.2. Если в вашем проекте нет проблем с ресурсами (конфликта ресурсов), переходите к шагу 1.6.

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

1.4. Устраните конфликт ресурсов, запланировав выполнение некоторых операций на более ранний срок. (На данном этапе не задумывайтесь о появлении новых конфликтов; вы снимете их позже.)

1.5. Вернитесь в конец графика и выполните пункт 1.4 для следующего ресурса. Устраняя текущий конфликт, не допускайте повторного возникновения конфликтов, которые вы уже разрешили ранее. Повторяйте процедуру, пока не закроете все выявленные проблемы с ресурсами.

1.6. Найдите критическую цепь — самую длинную последовательность зависимых событий.

2. Найдите способ снизить влияние критической цепи.

2.1. Просмотрите ваш план, проверьте, можно ли, поменяв последовательность выполнения работ, сократить общую длительность. Если можно, внесите соответствующие коррективы. Не позволяйте испытывать различные варианты методом проб и ошибок.

2.2. Добавьте проектный буфер в конец критической цепи.

3. Подчините все операции, цепочки и ресурсы нуждам критической цепи.

3.1. Используйте механизм защиты критической цепи: добавьте буферы ко всем цепочкам работ, которые сливаются с критической цепью (буферы на слияние путей). Определяя размер буферов, ориентируйтесь на самую длинную из вливающихся цепочек. (Обратите внимание: чтобы проект завершился, все пути в конце концов сольются с критической цепью. Если последовательность операций «впадает» непосредственно в проектный буфер, к ней тоже необходимо добавить буфер на слияние путей.)

3.2. Снимите все конфликты ресурсов, появившиеся после добавления буферов, путем перепланирования операций на более ранние сроки.

3.3. Соответственно сдвиньте на более ранние сроки операции, предшествующие тем, которые вы только что перепланировали.

4. Сократите общую длительность проекта, используя дополнительные ресурсы на определенных участках, чтобы снять конфликты.

5. Возвращайтесь на этап 1, не позволяя инерционности мышления стать ограничением.

В плане критической цепи указываются только даты начала цепочек работ и окончания всего проекта. Старайтесь не говорить о конкретных датах начал и окончаний отдельных операций. Это бессмысленно. Поэтому правильнее называть то, что вы получите, «план», а не «расписание» или «график».

6.2. «Достаточно хороший»

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

6.3. Примеры и упражнения

6.3.1. ПРОСТОЙ ПРИМЕР

На рис. 6.1 дан небольшой пример работы с критической цепью. Вы видите классический график СРМ типа «ранний старт». Первая цифра в каждом прямоугольнике — идентификатор операции из иерархической структуры работ. Вторая цифра — в скобках — показывает длительность операции в днях. Обратите внимание, что операция 3 зависит от завершения операций 1.2 и 2.2.

Как описано в процедуре, в первую очередь мы должны сократить длительность операций до значения с вероятностью 50% и перенести все работы на максимально поздний срок, учитывая зависимость операций в диаграмме (рис. 6.2).

Далее мы добавляем проектный буфер и буферы на слияние путей. Поскольку исполнитель (ресурс) у всех операций один, в данном проекте нет необходимости добавлять ресурсный буфер (рис. 6.3).

Теперь рассмотрим тот же небольшой проект, но уже с конфликтом ресурсов. Рис. 6.4 показывает последовательность операций в виде диаграммы PERT и без временной шкалы. Необходимые ресурсы в диаграмме обозначены разными цветами. Под этими цветами можно понимать, например, различные профессии (инженер, музыкант, оператор станков и т. п.).

Чертим диаграмму, сдвигая все операции на максимально поздние сроки. В данном случае необходимо лишь добавить ограничение «начало как можно позднее» к операции 2.1.

Затем устраняем конфликт ресурсов, двигаясь с конца проекта к началу (рис. 6.5).

На рис. 6.6 дается два способа снятия конфликта за ресурс «зеленый». Посмотрите, в каждом графике отображается новый тип зависимости от ресурса-ограничения. Какой из способов предпочтительней? На первый взгляд может показаться, что второй — нижний, поскольку последовательность операций получается короче. Во втором случае длина обеих цепочек одинакова, так что любую можно выбрать в качестве критической. А теперь добавьте в оба расписания проектный буфер и буферы на слияние путей и посмотрите, что получится.

На рис. 6.7 показан план, полученный после применения первого способа снятия борьбы за «зеленый» ресурс. В критическую цепь вошли все операции, кроме операции 2.1. Размер буферов на слияние путей определяем как 50% от общей длительности работ пути, впадающего в критическую цепь.

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

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

На основе рис. 6.9 постройте план критической цепи со всеми соответствующими буферами. Первая строка в каждом квадратике — номер операции. Вторая — ресурс, обозначенный цветом. Третья — длительность операции в днях (уже сокращенная). (Чтобы проверить приблизительную длительность расписания, которое должно у вас получиться, смотрите последний вопрос раздела 6.10. Учтите: приемлемый вариант критической цепи может отличаться от критического пути лишь на небольшой процент от величины буфера проекта.

6.3.2. СЛОЖНЫЙ ПРИМЕР

На рис. 6.10 дана диаграмма проектных работ следующего, более сложного примера. Верхняя строка в каждом квадратике — идентификатор операции. Цвет обозначает необходимый тип ресурса. Цифры в нижней строке показывают длительность операции в днях. Длительность взята с 50%-ной вероятностью.

Необходимо составить план этого проекта методом критической цепи.

Первый шаг — начертить график работ. На рис. 6.11 работы представлены в виде диаграммы Гантта, составленной средствами MS Project. Посмотрите диаграмму слева направо и обратите внимание на пересечение операций А-1 и В-2, где исполнителем назначен «пурпурный». Также пересекаются операции В-3, С-3 и D-3, у которых ресурс «синий». Можно легко заметить, что критический путь в этой диаграмме — верхняя цепочка работ, так как в ней нет никаких разрывов.

Программа MS Project позволяет снять конфликт путем выравнивания ресурсов, как продемонстрировано на рис. 6.12. Обратите внимание, теперь почти во всех цепочках операций есть пробелы, и поэтому считать их критическим путем нельзя.

Теперь необходимо найти критическую цепь. Рис. 6.13 показывает критическую цепь, определенную при помощи программы ССРМ + . Как вы видите, критическая цепь несколько раз «перепрыгивает» с одной логической последовательности операций на другую. При этом, если смотреть с конца проекта, видно, что на данный момент в критической цепи нет пробелов, хотя они есть почти во всех логических цепочках работ.

И наконец, завершаем создание плана, добавив проектный буфер и буферы на слияние путей. На рис. 6.14 приведен готовый план. В данном случае размер буферов мы находили как половину от длительности цепочки работ, после которой добавляется буфер. В нашем проекте потребовалось три буфера на слияние путей.

6.3.3. СЛОЖНОЕ УПРАЖНЕНИЕ

Взяв за основу данные рисунка 6.15, постройте план проекта методом критической цепи со всеми соответствующими буферами. Как и прежде, первая строка показывает номер операции. Вторая — тип ресурса. Третья — длительность операции в днях (уже сокращенная). (Чтобы проверить приблизительную длительность расписания, которое должно у вас получиться, смотрите последний вопрос в разделе 6.10.) Учтите: приемлемый вариант критической цепи может отличаться от критического пути лишь на небольшой процент от величины буфера проекта.

6.4. Определение размера буфера и нахождение границ принятия решений

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

6.4.1. СТАТИСТИЧЕСКОЕ ОБОСНОВАНИЕ

Рекомендации по вычислению размера буфера основаны на законах статистики. Это относительно простые правила, имеющие под собой теоретическую подоплеку. Доктор Элия Голдратт советует задавать размер буферов (проектного и на слияние путей) как половину от длительности пути, к которому добавляется буфер. Буферы призваны защищать проект от неопределенности в выполнении цепочек работ. При подсчетах не нужно учитывать пробелы в последовательностях операций.

Метод Голдратта основан на правиле статистики, описывающем сложение неопределенностей независимых событий. Правило гласит, что неопределенность суммы событий намного меньше, чем сумма неопределенностей каждого события. Это удобно, так как можно ожидать проявления как отрицательной, так и положительной вариабельности. Необходимо использовать рекомендацию Голдратта по определению размера буфера только в совокупности с правилом сокращения вдвое оценочной длительности всех операций проекта. Чтобы дать математическое обоснование методу Голдратта, необходимо сделать ряд дополнительных оговорок, к этому мы вернемся позднее. Как правило, следуя рекомендации Голдрат-та, вы получите больший размер буфера, чем пользуясь другим, описанным далее методом. Это оправданно, если вы только начинаете работать с критической цепью и стремитесь к упрощению процесса.

При определении размера буфера работают два правила статистики. Первое — правило сложения вариабельности. Оно гласит, что для независимых событий вариабельность¹⁵ распределения суммы событий равняется сумме вариабельностей распределений отдельных событий. Вариабельность обычно в литературе по статистике обозначается как о или s² и является способом описания статистических колебаний в распределениях любого типа.

Разброс распределения пропорционален стандартному отклонению s², или о. Таким образом, разброс, или протяженность распределения суммы (в нашем случае это буфер всего проекта), равняется квадратному корню от суммы квадратов отдельных распределений. (Внимание: если вы не любитель статистики и не знакомы с ее законами, не переживайте. Можете спокойно использовать метод критической цепи, руководствуясь простыми рекомендациями Голдратта или процедурой, приведенной ниже. Чтобы теория работала, вовсе не обязательно понимать ее в деталях.)

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

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

Рассмотрим для примера цепочку из четырех операций длительностью две недели каждая. Две недели — результат обычной оценки с перестраховкой, то есть с высокой вероятностью. Тогда оценка с 50%-ной вероятностью даст нам длительность каждой операции, равную одной неделе. Следовательно, разница D между этими оценками равна единице.

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

6.4.2. ОПРЕДЕЛЕНИЕ РАЗМЕРА БУФЕРОВ:

ПРОЕКТНОГО И НА СЛИЯНИЕ ПУТЕЙ

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

Метод 1: 50% цепи. Необходимо сложить длительность всех операций цепи и разделить пополам — это и будет размер буфера. Считать пробелы между операциями не следует. Если цепочка, сливающаяся с критической, разветвляется, учитывайте только самую длинную последовательность.

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

Метод 2: квадратный корень суммы квадратов (КСК, SSQ — Square Root of the Sum of the Squares). В методе КСК используется информация о двух длительностях каждой операции в цепи — наиболее вероятной и средней. Размер буфера находится как квадратный корень из суммы квадратов разностей двух длительностей каждой операции. Как и в методе 1, в разветвляющейся и впадающей в критическую цепь последовательности работ учитывайте только самую длинную цепочку.

Основным преимуществом этого метода является возможность использовать данные о вариабельности операций. Главный недостаток же в том, что величина буфера для длинных цепей может оказаться заниженной по двум причинам. Во-первых, недооценка фактической вариабельности операций. Во-вторых, метод предполагает, что любые отклонения в проекте случайны, тогда как реальность иногда свидетельствует об обратном. Некоторые случаи вариабельности в проектах являются следствием особых причин: это нечто, способное затянуть, но практически никогда не ускорить выполнение проекта. Явной особой причиной вариабельности при слиянии путей является задержка сроков всего проекта, вызванная задержкой на некритической цепочке. Если вариабельность, обусловленная общими причинами, действует в сочетании с задержками, вызванными особыми причинами, то правила статистики, на которых основан метод 2, не работают.

Метод 3: задержки плюс КСК. Это комбинация двух предыдущих методов. Итоговый буфер состоит из двух частей: фиксированной части (для компенсации действия вариабельности, вызванной особыми причинами) и части, вычисляемой методом КСК (для защиты от общих причин вариабельности). Фиксированная часть обычно будет намного меньше половины длины цепи, к которой добавляется буфер. В табл. 6.1 содержатся некоторые рекомендации для определения фиксированной части буферов времени и затрат. Результаты разных типов задержек суммировать необязательно. Чтобы подобрать правильную величину на компенсацию задержек, руководствуйтесь своим опытом работы в проектах.

Дополнительные рекомендации. Следующие советы помогут вам организовать эффективный буфер для вашего проекта.

1. Старайтесь, чтобы в критической цепи было как минимум десять операций. Объяснение: чем больше элементов в цепи, тем эффективнее действуют правило суммы квадратов и центральная предельная теорема.

2. Не допускайте, чтобы длительность отдельной операции была более 20% общей длительности работ цепи. Объяснение: неопределенность одной долгой операции будет оказывать воздействие на всю цепочку. Уменьшаются шансы того, что при выполнении других операций можно будет компенсировать перерасход времени на длинную.

3. Следите, чтобы проектный буфер был не менее 25% от длительности критической цепи. Объяснение: когда в цепочке есть несколько операций приблизительно одинаковой длительности, при расчете величина буфера, то есть степень защиты, может оказаться заниженной.

6.4.3. ГРАНИЦЫ ПРИНЯТИЯ РЕШЕНИЙ ПО БУФЕРУ

Как только показатель расходования буфера переходит красную границу, необходимо восполнить запасы в буфере. Иначе резерва может не хватить на оставшиеся до конца проекта операции, и тогда проект будет завершен с перерасходом буфера (растратой более 100% запасов), то есть с опозданием.

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

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

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

По буферу на слияние путей устанавливайте границы с теми же показателями, что и для проектного буфера. Однако, расставляя приоритеты своих действий, исходите из степени их влияния на проектный буфер.

Таблица 6.2. Значения граничных точек принятия решений по буферу
	Расход буфера (%)
Прохождение	Точка перехода из зеленой зоны	Точка перехода из желтой зоны
критической цепи (%)	в желтую (%)	в красную (%)
0	15	30
100	17	90

6.4.4. РЕСУРСНЫЕ БУФЕРЫ

Голдратт рекомендует пользоваться ресурсным буфером, который поможет исполнителям операций критической цепи понять, когда от них потребуется приступить к работе. Поскольку в ССРМ мы не назначаем дат на отдельные работы, а исполнителям иногда нужно планировать свою деятельность заранее (например, не брать отпуск, если близится задание из критической цепи), возрастает роль процесса оповещения. Теперь-то мы с вами понимаем, что даты, которые проставляются в планах проектов по каждой операции, имеют нулевую вероятность, в то же время людям нужно на что-то ориентироваться. Поэтому возникает необходимость в ресурсном буфере.

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

Программа Concerto автоматически расставляет операции по приоритетам в зависимости от их влияния на проектный буфер. Это значительно упрощает задачу направления исполнителей на нужные работы. И в других программах можно создать подобные списки операций, отсортировав данные по исполнителям.

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

6.5. Определение размера буфера на непредвиденные расходы

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

научно-исследовательские разработки на основе самофинансирования), такой буфер не нужен.

При определении размера буфера на затраты нужно учитывать несколько факторов. Во-первых, вы должны заложить в проекте специальный бюджет, использование которого напрямую связано с состоянием временных буферов. Так, сдвиг начала работ напрямую на объеме затрат не скажется, а вот если исполнителю для завершения задания потребуется дополнительное время, расходы вырастут. В буфер на дополнительные затраты нужно закладывать как минимум 50% размера временного буфера в соответствующем денежном эквиваленте (по ставке за работы на цепи, которую защищает буфер). Или же, используя один из методов определения буфера времени, например «погрешность плюс КСК», изъять часть сумм, запланированных на каждую операцию, и буфер сформировать из изъятых долей. Тогда буфер на затраты будет равняться сумме квадратного корня из суммы квадратов изъятых из каждой операции частей и фиксированной величины затрат на компенсацию неожиданных сбоев. Не забывайте, что при использовании данного метода применительно к буферу на непредвиденные расходы действуют все те же правила, что и в случае с буфером времени. Например, если в цепочке много равновеликих операций, вычисленный данным методом буфер будет иметь величину меньше, чем при применении других методов.

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

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

Никогда не приступайте к работе, если величина буфера на затраты меньше 10% расходной части бюджета проекта. Дело в том, что в оценках затрат всегда есть погрешность. Непременно что-то не учли или недооценили. В ходе анализа проекта обычно устраняются все «излишние» статьи расходов и корректируются нереалистично большие оценочные величины затрат по отдельным операциям.

При определении доли буфера для компенсации неопределенности не забывайте, что редко когда удается испытать преимущество досрочного выполнения пакета работ (при использовании средней оценки), однако следует учитывать статистическую комбинацию положительных вариаций. Если один из пакетов работ оказывает доминирующее влияние на степень неопределенности и уровень затрат по проекту, именно он должен учитываться при статистическом расчете размера буфера на непредвиденные расходы. Если у вас несколько одинаковых пакетов работ, то статистическую составляющую буфера на затраты можно вычислить методом КСК.

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

Если в вашей организации используются отчеты по расписанию и затратам CSCS или же планы проектов служат для получения сводных данных о потребностях в ресурсах, можете добавлять в ваш план буфер на непредвиденные расходы. Рекомендую включить его в проектный буфер. Если для общего планирования ресурсов используются иные средства, можно составить буфер на непредвиденные расходы как постоянные затраты, распределенные по операциям. Если при планировании потребностей в ресурсах используются планы отдельных проектов, необходимо рассчитать общий агрегированный буфер и распределить его неким образом по всем проектам. Например, человеческие ресурсы в буфере могут быть распределены в том же процентном соотношении, что и в общем агрегированном плане.

6.6. Способы создания плана

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

6.6.1. РУЧНОЙ СПОСОБ

Создание пакетов работ вручную — самый простой и распространенный способ. Основан он на использовании диаграммы PERT и бумаги для заметок с клейким краем. Скорее всего, для совсем небольших проектов больше ничего и не потребуется. Процедура выглядит следующим образом:

1. Заготовьте клеящийся листочек для каждой операции, написав на нем идентификационный номер операции, ее название, длительность (уже сокращенную вдвое) и исполнителя/ресурс, от которого зависит длительность. Такой ресурс можно обозначать цветом. На левой части листа укажите номера работ, результаты которых служат для данной операции исходным материалом.

2. Расположите листки на какой-нибудь поверхности в соответствии с логикой и ориентировочными сроками выполнения работ. Мы получили диаграмму PERT (или логическую диаграмму) с сегментацией по времени.

3. Устраните конфликты ресурсов.

4. Найдите критическую цепь.

5. Добавьте листки с обозначением буферов на слияние путей и проектного буфера.

6. Вычислите размер буферов.

7. Рассчитайте критическую цепь методом «прямого прохождения». Начиная с самой первой операции, в нижнем левом углу листков записывайте дату начала каждой операции, а в нижнем правом — дату окончания (равняется дате начала плюс длительность работ).

8. Методом «обратного прохождения», начиная от точки слияния, рассчитайте последовательности работ, «впадающие» в критическую цепь.

9. Устраните все оставшиеся конфликты ресурсов и проверьте результаты предыдущих вычислений.

Эта процедура удобна для планирования проектов, в которых менее 20 операций. Для более крупных проектов применять ее сложнее, так как требуется много места.

Метод можно модифицировать, используя цветную бумагу и вырезая прямоугольники разной длины. Длина будет соответствовать длительности операции, а цвет — типу ресурса, необходимого для ее выполнения. Это упростит процесс снятия конфликта за ресурсы и последующие вычисления. Конечно, потребуется чуть больше подготовительных работ. Этот метод успешно применялся даже на крупных проектах из 500 операций и более. Для составления расписания также можно воспользоваться магнитной доской или такими компьютерными приложениями, как PowerPoint или Excel.

6.6.2. ПРОГРАММЫ С АЛГОРИТМОМ КРИТИЧЕСКОГО ПУТИ

Чтобы планировать и управлять проектом по методу критической цепи, можно воспользоваться компьютерными программами, разработанными для вычисления критического пути. Большинство программных продуктов предоставляет достаточно возможностей как для выравнивания ресурсов, так и для выстраивания методом «поздний старт» сливающихся с критической цепью последовательностей работ. Начинаем мы всегда с одного и того же: рисуем логику проекта, используя сокращенные длительности операций и данные о необходимых ресурсах. Обязательно проверьте сделанные установки (в зависимости от программы): во-первых, удостоверьтесь, что длительность операций — величина фиксированная и, во-вторых, что каждая цепочка работ строится по типу «поздний старт». В некоторых программах можно установить эти параметры сразу на весь проект. А иногда требуется программировать «поздний старт» на первую операцию каждой цепочки. Поэкспериментируйте, чтобы понять особенности программы, с которой работаете, и знать, какие установки в ней используются при выравнивании ресурсов.

Возможность задания алгоритма для выравнивания ресурсов заложена практически во все программы СРМ. Проверьте. Метод критической цепи не завязан на тот или иной алгоритм. Единственное требование — в готовом плане должны быть устранены все конфликты за ресурсы данного проекта. Обычно при желании можно выравнять ресурсы вручную и внести в программу финальный вариант распределения ресурсов по операциям.

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

Проверьте, на самом ли деле найденная вами критическая цепь является ограничением для выполнения проекта. Ошибочное установление связей между операциями иногда приводит к тому, что в критическую цепь попадает задание, которое не должно и не может определять длительность всего проекта. (Я называю это «математический критический путь или цепь»). Скорректируйте логику связей или длительность операции так, чтобы критическая цепь стала очевидным бесспорным ограничением в проекте. Повторимся: бывает так, что существует две практически одинаковые по длительности цепочки, претендующие на роль критической. Выберите ту, в которой, по вашим ощущениям, выше степень неопределенности или в которой чаще задействован пользующийся высоким спросом ресурс (потенциальное ограничение).

Кроме того, удостоверьтесь, что критическая цепь составлена так, что в ней заложена достаточная устойчивость и минимальная зависимость от вариабельности при выполнении отдельных операций. Вот две простые рекомендации:

1. Критическая цепь должна состоять как минимум из 10 операций (для средних по размеру проектов).

2. Величина операций критической цепи не должна быть более 20% цепи или 50% проектного буфера.

Далее необходимо добавить буферы на слияние путей и проектный буфер. Они обозначаются как обычные операции, только без указания ресурсов. Не забудьте пометить, что буфер на слияние путей является предшественником для определенной операции критической цепи, установите соответствующую связь. Затем нужно перепроверить результаты выравнивания ресурсов и произвести итоговые корректировки. (После добавления буферов на слияние путей обычно нужно повторно выравнять ресурсы.)

6.6.3. ПРОГРАММЫ С АЛГОРИТМОМ КРИТИЧЕСКОЙ ЦЕПИ

Программы, созданные для работы с критическими цепями, автоматически выполняют практически всю процедуру, описанную ранее. Сегодня существует несколько таких программных продуктов. Самые доступные из них либо интегрировали Microsoft Project в себя, либо являются дополнительным модулем к нему.

6.7. Внешние ограничения

У проекта могут быть и внешние ограничения. Это факторы, способные повлиять на длительность проекта, но действующие вне зоны контроля проектной команды. К ним относятся различные нормативные акты, контролирующие органы, организации, выдающие разрешения на проведение работ. Бывают внешние ограничения, исходящие изнутри самой компании. Например, для проекта иногда необходим результат работы другого подразделения.

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

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

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

Вряд ли вы пойдете на шаг четвертый и решите полностью избавиться от внешнего ограничения.

6.8. Сокращение запланированного времени (или навязанная дата окончания работ)

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

6.8.1. УСКОРЕНИЕ РАБОТ БЕЗ ВЛИЯНИЯ НА УРОВЕНЬ ЗАТРАТ (ОСЛАБИТЬ ОГРАНИЧЕНИЕ И ПОДЧИНИТЬ ЕМУ ВСЕ)

Есть несколько хороших способов сократить время выполнения проекта. Самые лучшие из них не вызывают роста расходов. Опишем два основных способа. Первый: привлечь дополнительные ресурсы на те участки работ, длительность которых увеличилась после выравнивания ресурсов. Второй: изучить сами работы на предмет выявления возможности их разбиения (то есть уменьшения размера группы работ).

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

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

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

Если речь идет о больших объемах продукции, можно запланировать их производство как повторяющийся процесс и применить к нему дополнительный метод отслеживания и контроля. В плане критической цепи такой процесс будет изображен как одна операция (например, «обработка 37 изделий»). Есть эффективный метод, объединяющий в себе черты процесса контроля операционной деятельности и управления проектом. Это метод «сбалансированного производства» (line-of-balance). Он предусматривает планирование того момента, когда каждая деталь должна попасть в производственную линию, таким образом, на каждый этап в определенное время поступает определенное количество деталей (движение деталей сбалансировано). Затем регулярно сравнивают фактическое и запланированное количество деталей на каждом этапе.

6.8.2. УСКОРЕНИЕ РАБОТ С УВЕЛИЧЕНИЕМ ЗАТРАТ НА СЫРЬЕ (УСТРАНЕНИЕ ОГРАНИЧЕНИЯ)

Сократить время выполнения проекта можно и более затратными методами. Например, прибегнуть к сверхурочной работе или нанять дополнительных временных рабочих (затраты на которых обычно выше). Можно приобрести материал за более высокую цену, но с более коротким сроком доставки. Можно установить крупные премии за сокращение сроков выполнения работ субподрядчиком.

По теории ограничений для принятия решения о незапланированных вложениях необходимо сопоставить уровень дополнительных операционных расходов с производительностью по денежному потоку — Т проекта. Производительность Т (в день), связанная с сокращением длительности проектных работ, равна для вас ценности всего проекта (в день). Сравните величину, на которую возрастут затраты на сырье, с тем, на сколько увеличится Т при ускорении работ. Если рост производительности всей системы по денежному потоку Т после завершения проекта превосходит рост затрат за один и тот же интервал времени, принимайте положительное решение и устраняйте ограничение. Как правило, Т увеличивается значительней, чем расходы. На двух проектах, с которыми я недавно работал, ускорение всего на один день принесло бы, соответственно, дополнительных $10 млн и $17 млн. Тут уж окупятся любые затраты.

6.9. Планирование ресурсов предприятия

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

6.10. Часто задаваемые вопросы о планировании

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

1. После добавления буфера на слияние путей некритические цепочки стали начинаться раньше критической цепи. Это нормально?

Так бывает, повода для беспокойства нет. Начинайте реализацию проекта с некритической последовательности работ. В некоторых программах по ССРМ такие операции переводятся в состав критической цепи. Если вам так спокойнее, сделайте так же.

2. После добавления буфера на слияние путей в некритическую цепочку перед соответствующей операцией критической цепи эта операция сильно сдвинулась вперед, и в критической цепи образовался пробел. Правильно ли это?

Для начала проверьте логику вашего плана и распределение ресурсов и попытайтесь устранить этот пробел. Проверьте точку слияния критической и некритической цепочек и прикиньте относительную вариабельность обеих. Помните, мы все подчиняем нуждам и ритмам критической цепи. В общем случае пробелы в ней должны появляться только под влиянием ресурсного ограничения, налагаемого компанией. Пробелы в плане не должны вести к простоям в работе.

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

3. Почему мы не соединяем между собой некритические цепочки с учетом ограничений по ресурсам и их логической зависимости?

Попытки расписать подобные подробности в плане не ведут к улучшению качества реализации проекта. Из-за действия вариабельности контролировать все зависимые цепочки невозможно. Методы определения размеров буферов, установка буферов на слияние путей, и (очень важный момент) управление с использованием буферов, и правильное направление усилий исполнителей — вот необходимые и достаточные меры защиты и контроля.

4. В нашем графике тысячи задач. Как можно при планировании обойтись без специальных компьютерных программ?

Рекомендую сделать обобщенную картину проекта из нескольких сотен операций максимум. Для детализации данных использовать описание пакетов работ или разбивать проект на подпроекты. Метод критической цепи успешно применялся на проектах общей численностью до 30 000 операций.

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

5. В плане нашего проекта есть операции вне зоны нашего контроля. Как с этим быть?

Такое часто бывает, когда в ходе работ происходит приемка результатов клиентом или регулирующим органом. Мы отвечаем за ту продукцию, которую им предоставляем, и за сроки ее предоставления, однако их рабочие процедуры находятся не в нашей власти. В данном случае поможет работа с участниками проекта, описанная в главе 1. Вы можете повлиять на то, сколько продлится приемка, а также снизить процент потенциальных переделок, если потратите достаточно сил на то, чтобы четко разобраться во всех требованиях и произвести качественный продукт, им соответствующий. Если на общение с вами у внешних организаций уходит значительный процент рабочего времени, вы можете облегчить их участь, подавая результаты на анализ не скопом, а порционно, избавив тем самым контрагентов от необходимости заниматься несколькими делами сразу. Особые случаи могут потребовать особенных решений. Пользуйтесь пятью направляющими шагами ТОС.

6. Наше руководство/заказчик хочет, чтобы мы назвали точные даты ряда промежуточных контрольных событий и обеспечили их соблюдение. Как нам поступить?

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

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

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

7. Клиент не хочет получать результаты наших работ досрочно, потому что мы являемся поставщиком для их проекта, и они не желают озадачиваться вопросами хранения нашей продукции, поступившей раньше запрошенного ими срока. Что нам делать?

Используйте метод критической цепи, чтобы рассчитать даты начала работ, соответствующие требованиям клиента. Обычно при этом вы сможете отложить запуск работ на более поздние сроки.

8. По мере реализации проекта выявилась необходимость в изначально не запланированных работах. Как с этим быть?

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

9. Программа для работы с критической цепью помещает в расписании некритические операции раньше тех, которые, на наш взгляд, более критичны. Что можно сделать?

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

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

10. Каков правильный ответ к упражнениям, заданным ранее в этой главе?

Существует много правильных вариантов ответов. Ваш ответ будет вполне приемлемым, если длина критической цепи (после выравнивания ресурсов) будет отличатся от длины критического пути не более чем на 15% величины буфера.

Простое упражнение:

длина критической цепи — 50, проектный буфер — 25, общее время выполнения проекта — 82.

Сложное упражнение:

длина критической цепи — 107, проектный буфер — 47, общее время выполнения проекта — 154.

6.11. Итоги

В этой главе описан процесс создания плана отдельного проекта методом критической цепи. Первые шаги этого процесса (создание логической диаграммы проекта и оценка параметров операций с максимальной вероятностью) выполняются в соответствии с рекомендациями РМВОК. Этапы планирования критической цепи следующие:

1. Планирование проекта ССРМ начинается стандартно — с определения проектного задания (объема работ) и составления диаграммы последовательности операций, необходимых для выполнения проектного задания. Для выполнения данного шага существует масса способов.

2. Прежде чем переходить к определению критической цепи, необходимо назначить ресурсы и выполнить их выравнивание.

3. Проведите оценку длительности операций как обычно. Затем часть оценочной длительности отнесите к операции, а часть — в буфер.

4. Для определения размера буферов используйте метод, подходящий для вашей организации. Как правило, сначала лучше закладывать величину буфера как 50% от длительности цепочки операций, которые этот буфер защищает.

5. Границы принятия решения по буферам (проектному и на слияние путей) задают ритм контрольных мероприятий. Определите и зафиксируйте эти границы в ходе планирования.

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

7. Пять направляющих шагов ТОС определяют порядок решения специфических проблем по проекту: определяй, уменьшай влияние, подчиняй, устраняй, избегай инерции.

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

Глава 7. Создание сводного плана нескольких проектов методом критической цепи

7.1. Как определить ограничение системы проектов

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

Представим себе всем знакомый процесс стрижки газона. Срезанная трава — это аналог выполненных проектов компании. Что будет, если трава слишком высокая или если вы чересчур быстро передвигаете газонокосилку? Механизм забьется травой и заглохнет.

То же самое происходит, когда в компании запускается слишком много проектов без учета возможностей имеющегося ограничения. Если в систему «подать» чересчур большое количество проектов, они в ней застрянут, система заглохнет. Люди будут трудиться изо всех сил, однако проекты станут идти все медленней (ведь двигатель регулярно глохнет), а усилия руководства — уходить на то, чтобы перезапустить двигатель и прочистить заторы. Складывается впечатление, что ключевых ресурсов, необходимых для завершения проектов, всегда будет не хватать.

Работая с газонокосилкой, вы получаете от системы обратную связь и регулируете степень нагрузки. Вы прислушиваетесь к двигателю: как только он замедляется, снижаете темпы работы или регулируете высоту ножей, чтобы пропускная способность механизма соответствовала подаваемой нагрузке. Как правило, вы не бросаетесь тут же покупать новый аппарат или переделывать старый. Организации же, бывает, в подобной ситуации начинают нанимать новых людей (все равно что покупка новой газонокосилки) или уповают на реинжиниринг (равносильно переделке имеющейся газонокосилки). Хотя достаточно лишь подрегулировать настройки (изменить высоту ножей в режущем механизме). То есть компании следует всего-навсего пересмотреть подход к планированию и ведению проектов, и результат превзойдет все ожидания.

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

Если предположить, что проекты на рис. 7.1 одинаковые, ресурсы придется распределять между всеми тремя проектами, даже если у вас всего по одному ресурсу каждого типа. То есть либо при планировании сразу предусматривается необходимость единовременного выполнения одним ресурсом нескольких заданий по разным проектам (учитывается частичная, а не 100%-ная занятость исполнителей по каждому из проектов), либо же из-за многозадачности проекты никогда не завершатся вовремя. Если проекты равнозначные, то сразу видно, когда один из исполнителей более загружен, чем остальные. Этот ресурс — ограничение по мощности системы. Таким образом, скорость выполнения проектов в компании определяется скоростью работы самого загруженного исполнителя-ограничения.

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

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

ограничение компании действует как «барабан». Этот термин взят у Гол-дратта — из методики налаживания производственных систем. Барабан определяет ритм всего производственного процесса. В нашем случае — проектов компании. Вспомните барабанщиков, задающих ритм гребцам на старинных кораблях. Что будет, если хотя бы один из гребцов собьется с такта?

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

На рис. 7.2 показаны результаты работы метода ССРМ. В отличие от приведенного ранее плана критических путей, при использовании критической цепи длительность каждой операции сократилась до 15 дней. Снизилась степень «многозадачности» (необходимость распределять усилия исполнителей между тремя задачами трех проектов одновременно), при этом в план заложена оценка длительностей операций с вероятностью своевременного выполнения 50%. По результатам планирования методом ССРМ ресурсом, ограничивающим мощность системы, является исполнитель операций 2 и 3. Метод позволяет снизить влияние этого ограничения, синхронизировав проекты и используя ограничение как «барабан». Правило подчинения работ ритмам ограничения реализуется путем добавления между проектами буферов на доступность ресурса (БДР). Буферы на доступность обеспечивают своевременное наличие ресурса, ограничивающего мощность системы, на работах следующего проекта.

По плану на рис. 7.2, созданному при помощи ССРМ, все три проекта (с учетом буферов) завершаются к концу августа 1998 года. А выполнение двух первых проектов ожидается даже раньше. А теперь сравните результат с планом на рис. 7.1, где окончание всех трех проектов прогнозировалось на май 1999 года. Исходя из того, что мы знаем о критических цепях в отдельных проектах, можно ожидать, что проекты, управляемые по методу ССРМ, завершатся сравнительно рано. О проектах же, выполняемых методом критического пути, можно сказать, что окончатся они, вероятнее всего, с нарушением даже самых осторожных сроков.

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

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

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

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

7.2. Как снизить влияние ограничения системы проектов

Ресурс-ограничение становится «барабаном» для проектов компании (подобно барабанщикам, задающим ритм гребцам на древних кораблях). Следовательно, процедура снижения влияния ограничения будет выглядеть следующим образом.

1. Найдите ресурс-ограничение компании.

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

2. Снизьте влияние ресурса-ограничения, максимально использовав его возможности.

2.1. Для каждого проекта в отдельности составьте график методом критической цепи.

2.2. Определите приоритетность проектов в борьбе за ресурс-ограничение.

2.3. Создайте график вовлеченности ресурса-ограничения во все рассматриваемые проекты, или график «барабана». Установите все потребности проектов и снимите явные конфликты, чтобы увеличить производительность всей организации (т. е. позвольте большей части проектов завершиться досрочно).

3. Подчините/согласуйте отдельные графики проектов между собой.

3.1. Начало каждого проекта определите с учетом графика вовлеченности ресурса-ограничения.

3.2. Обозначьте критическую цепь — от первой операции, требующей участия ресурса-ограничения, и до конца проекта.

3.3. Добавьте буферы на доступность — между графиками проектов перед тем графиком, в котором задействован ресурс-ограничение. Этот механизм защитит график «барабана», обеспечив своевременное наличие всех исходных материалов.

3.4. Если при добавлении буферов на доступность возникают накладки в графике ресурса-ограничения, устраните их.

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

4. Устраните ограничение — увеличьте мощность ограничивающего ресурса.

5. Вернитесь к шагу 1, не позволяя инерционности мышления становиться ограничением.

Далее мы рассмотрим некоторые составляющие этого процесса.

7.3. Важные аспекты управления несколькими проектами методом критической цепи

7.3.1. РАССТАНОВКА ПРИОРИТЕТОВ

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

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

7.3.2. ОПРЕДЕЛЕНИЕ РЕСУРСА-«БАРАБАНА»

Ресурс-«барабан» задействован во всех проектах, которые мы рассматриваем как части одной системы. В крупных компаниях может существовать несколько групп проектов, при этом одни и те же ресурсы задействованы внутри группы, но не между группами. В этом случае и ресурсов-«бараба-нов» будет несколько.

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

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

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

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

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

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

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

7.3.3. ГРАФИК «БАРАБАНА»,

ИЛИ НАЛАДКА КОНВЕЙЕРА ПРОЕКТОВ

График «барабана» — это план привлечения ресурса-ограничения к работам по всем проектам, где он нужен. Ведет график обычно тот, кто отвечает за ресурс-ограничение. Ресурс-«барабан» — первоочередной фактор, который определяет возможность системы выполнять проекты.

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

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

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

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

7.3.4. БУФЕР НА ДОСТУПНОСТЬ РЕСУРСА

БДР (The Capacity Constraint Buffer) обеспечивает доступность ресурса в тот момент, когда он требуется для проектных работ. Теоретически буфер помещается между операцией, где используется ресурс в предыдущем проекте, и первой операцией, для которой он понадобится в интересующем вас проекте. БДР влияет скорее не на общую продолжительность проекта, а на дату начала работы в нем данного ресурса.

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

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

При определении размера БДР нужно учитывать теорию очередей и методику выравнивания ресурсов. Теория очередей требует, чтобы буфер на доступность ресурса соответствовал как минимум 25% мощности ресурса, ограничивающего мощность системы. Иначе проекты начнут тормозить.

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

Своим слушателям я задаю вопрос: «Какова будет длина очереди, если ее пропускная способность, то есть скорость прохождения через нее людей, равняется скорости прибытия людей?» Большинство отвечает, что очереди вообще не будет или в ней окажется всего один человек. К сожалению, это яркий пример неспособности человеческого мышления оперировать категориями вариабельности. В данном случае постепенно величина очереди начнет стремиться к бесконечности. Конечно, только если мы располагаем бесконечным количеством времени. Так или иначе, длина может очень быстро вырасти и не будет сокращаться, если не увеличить пропускную способность обрабатывающего звена (не открыть «новое окошко») или не уменьшить пополняющий очередь поток. Может, поэтому многие магазины закрываются на ночь.

На рис. 7.5 изображена классическая кривая, описывающая одну очередь, обслуживаемую одним обрабатывающим звеном. Она показывает зависимость длины очереди от загруженности, где загруженность — это отношение средней скорости пополнения очереди к ее пропускной способности. Кривая времени ожидания будет иметь ту же форму. При х = 1 средняя скорость пополнения очереди равна средней скорости обработки. Обратите внимание, что чем ближе к этой точке, тем резче увеличение длины, которая в конце концов начинает стремиться к бесконечности. Конечно, эта модель основана на определенных статистических допущениях, однако в целом она дает весьма универсальную картину. Как только загруженность становится больше 70%, или 0,7, что соответствует 30%-ному БДР, очередь начинает стремительно расти.

Вероятно, следующие соображения помогут вам понять, откуда берется такой неожиданный результат. Допустим, вы работаете на 90% мощности и пропустили один день по болезни. Чтобы наверстать упущенное,

вам потребуется 9 дней, потому что на это каждый день у вас есть запас мощности лишь 10%. Теперь представим, что вы тратили 95% мощности. Чтобы нагнать, нужно будет уже времени вдвое больше, потому что свободного времени теперь вдвое меньше, а доделывать придется чуть больше. Если же работали на все 99%, то после пропуска догонять будете 99 дней. Когда речь идет о 100%, простой не компенсировать никогда.

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

Если вы не хотите бесконечно дожидаться, пока ресурс-«барабан» освободится для участия в вашем проекте, используйте буфер на доступность ресурса величиной от 25 до 30%.

7.3.5. БУФЕР ОГРАНИЧИВАЮЩЕГО РЕСУРСА

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

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

Если вы все же берете БОР, определяйте его размер по правилам для буфера на слияние путей, беря за исходные данные длительность предыдущей цепочки операций.

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

7.3.6. РАСПИСАНИЯ ПРОЕКТОВ

Получив график «барабана», можете приступать к созданию расписаний отдельных проектов. Дата начала проекта должна определяться с учетом доступности ресурса-«барабана». То есть, чтобы назначить дату начала работ, вы проходите цепочку операций от той, где потребуется ресурс-

«барабан», к началу проекта. Поскольку для составления графика «барабана» вам требовалось расписание критической цепи с некой точкой отсчета, даты начал некоторых проектов, возможно, изменятся. Срок, на который они сдвинутся, будет равен сумме величины отрезка, на который сдвинулась операция того или иного проекта при составлении графика «барабана», и величины БОР. Затем размечайте все оставшиеся операции, двигаясь от тех, где нужен ресурс-«барабан», к концу проекта.

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

7.4. Еще один взгляд

на ограничение одновременных проектов

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

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

Водителям помогает множество специалистов. Когда машина заезжает в бокс, у них должно быть все необходимое, чтобы быстро провести наладку механизмов, тем самым оптимизировав работу водителя и доведя скорость машины до максимальной.

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

7.5. Запуск новых проектов

В системе одновременно идущих проектов в любой момент могут появиться новые проекты. У вас уже есть на руках список приоритетов и график «барабана», а также информация о статусе работ. Нужно вписать в систему новый проект.

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

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

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

На рис. 7.6 показан процесс ввода нового проекта в график «барабана». Сначала предполагаем, что работы должны начаться немедленно. Помещаем новый проект пока над следующим за ним по приоритету, как сделано на рис. 7.6. Проекты, которые обладают меньшим приоритетом, размещаем над новым проектом. Затем располагаем операции в соответствии с доступностью ресурса, как показано на рис. 7.7. Это может вызвать приостановку ряда уже идущих проектов. Рассуждайте здраво. Не прерывайте почти завершенные работы, пока не получите их результатов.

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

7.6. Вопросы, часто задаваемые по системному планированию нескольких одновременных проектов

1. В нашей организации со временем произошли изменения. Как найти, что сейчас является «барабаном» системы?

Очень полезно время от времени проверять, не сменился ли ресурс-«барабан». Если сменился, пора пересмотреть проекты. Зачастую даже при смене «барабана» величина отсрочек, необходимых для оптимального выполнения проектов, сильно не меняется.

2. Все наши проекты чаще всего одновременно проходят одни и те же фазы. Так что в течение года ограничение меняется. Как его найти?

Эта широко распространенная ситуация является следствием слепой убежденности в том, что все проекты нужно запускать одновременно, например, с началом финансового или календарного года. Мой хороший приятель Скотт Баттон, консультант по ССРМ, проводит аналогию со змеей, заглатывающей свинью: огромный кусок мяса медленно протискивается по пищеварительной системе. Для начала системе управления проектами необходимо устранить это организационное ограничение.

3. Может ли одновременно существовать несколько ресурсов-«бара-банов»?

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

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

Если менеджмент не следует приоритетам, система одновременного ведения проектов работать не будет. Так что выбор прост: либо увеличивать производительность Т, либо нет. Как только руководство увидит результат, оно поймет, что все только выигрывают. В конце концов, если система делает деньги, мы обеспечены работой. Так что соблюдение приоритетов зачастую означает прибыль и для руководства.

7.7. Итоги

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

• ограничение системы нескольких одновременных проектов — это ресурс-«барабан»;

• руководство должно выявить ресурс-«барабан» и расставить приоритеты всех проектов, чтобы определить правило очередности использования этого ресурса;

• буфер на доступность ресурса обеспечивает наличие ресурса именно в тот момент, когда он необходим; размер БДР должен составлять от 25 до 30% мощности ресурса-ограничения;

• буфер ограничивающего ресурса БОР защищает ресурс-«барабан» от нехватки материалов для работы;

• даты начал отдельных проектов определяются при помощи графика «барабана», куда входят также БДР и БОР;

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

Практическое применение ССРМ в системном управлении одновременными проектами компании дает великолепные результаты. Ведь обычно в таких организациях всем приходится делать массу дел одновременно. Снижение уровня «многозадачности» ведет к значительному увеличению производительности Т всей компании.

Глава 8. Оценка и контроль выполнения плана

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

Приведу список характеристик, которыми должна обладать эффективная система оценок. Автор первых шести пунктов — Джозеф Джуран [1]. Похоже, про седьмой он забыл. Восьмой объяснялся в разделе 4.3, где речь шла о снижении влияния ограничения, о необходимости получить максимум из плана и использовать управление при помощи буфера. Там же говорилось, что Голдратт определяет информацию как «ответ на заданный вопрос». А пункт девятый — это кредо и теории ограничений, и бережливого производства. Итак, эффективная система оценок должна:

1) служить общепризнанной основой для принятия решений;

2) быть понятной;

3) широко использоваться;

4) давать однозначные результаты, не допускающие разных толкований;

5) быть малозатратной;

6) соответствовать существующим методам сбора информации;

7) вовремя побуждать к действию;

8) давать информацию тем, кому предстоит действовать;

9) быть простой.

Разрабатывая эффективную систему оценки и контроля ССРМ, я, кроме того, ориентировался на такие положения бережливого производства, как концентрация на потоке работ и использование средств визуального контроля. Система должна уменьшать потери (по-японски muda), вызванные излишней сложностью процесса.

Цель всех проектов организации должна так или иначе соотноситься с общей целью организации как системы. Цель коммерческих предприятий — делать деньги сейчас и в будущем. Как говорилось в главе 1, если даже у проекта нет жестко заданной и фиксированной даты окончания, он будет соответствовать цели компании, если служит выполнению всех требований заказчика, не выходит за рамки планового бюджета и завершается в срок или досрочно. Если же проект непременно должен завершиться в четко определенный день (например, проекты по строительству стадионов для Олимпийских игр), главной целью будет соблюдение сроков. Система оценок на проектах должна быть информативной, чтобы можно было принимать такие частные решения, которые положительно скажутся на общей цели проекта.

Читая далее о системе оценки и контроля в ССРМ, обратите внимание, каким образом она выполняет все приведенные ранее требования.

8.1. Роли в проекте

В этой главе поговорим о системе оценки и контроля для четырех типов пользователей: для менеджера операции, для руководителя проекта, для менеджера ресурсов и для высшего руководства.

8.1.1. МЕНЕДЖЕР ОПЕРАЦИИ

Задача менеджера операции — способствовать прохождению запланированных проектных работ без задержек. Для этого ему необходимо знать, за какую следующую задачу браться. Весь фокус — работать именно над тем, что способствует скорейшему завершению проекта. В. Херроелен, Р. Леус и Е. Демойлемеестер критикуют метод ССРМ за то, что в нем не используется «пересмотр расписания» по ходу проекта [3, с. 57]: «Оставшиеся работы можно ускорить, если пересмотреть даты в расписании». Авторы не поняли, что в ССРМ вообще не задаются никакие конкретные даты работ. Путем постоянного анализа того, какие далее операции выполнять, пользователи ССРМ получают тот же результат (скорейшее завершение проекта), как если бы им пришлось непрерывно переделывать расписание. Хотя в ССРМ и используется выравнивание ресурсов для определения общей длительности проекта, однако ошибочно полагать (как это свойственно тем, кто мыслит в категориях детерминизма, а не вариабельности), что получившиеся при этом даты действительно показывают, когда начнется и окончится та или иная операция. Работа начнется, когда завершится предшествующая задача и когда будет свободен соответствующий исполнитель, а закончится — как можно скорее. Херроелен, Леус и Демойлемеестер на самом деле лишь подтвердили преимущества ССРМ.

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

Для правильного распределения ресурсов очень пригодится список операций, показывающий порядок, в котором они должны начинаться, и приоритет каждой. Можно автоматизировать создание таких списков даже с помощью программ, не предназначенных для ССРМ. Так, один мой клиент написал скрипт, позволяющий составлять списки задач по приоритетам в программе Primavera. Самыми первыми в перечень помещаются операции, которые уже идут. Затем из текущего расписания (размер буферов на слияние путей в нем сведен к нулю) рассчитывается временной запас по всем остальным операциям. Более приоритетными будут задачи с минимальным или даже отрицательным запасом. Операции с наибольшим запасом попадут в самый конец списка. Кроме того, еще есть колонка, показывающая, завершена ли предшествующая операция.

Программа ССРМ+ [4] показывает готовые начаться операции по приоритетам в виде графика (рис. 8.1). Подобную задачу для системы одновременных проектов решает программа Concerto. Она автоматически создает перечень задач по приоритетам, что позволяет менеджерам операций быстро сориентироваться в ситуации и донести информацию до других (рис. 8.2).

Программа Concerto максимально ориентирована на удобство пользователей и позволяет получать информацию о проекте практически в режиме реального времени. При наличии соответствующих прав доступа с ней можно работать через Интернет когда угодно и откуда угодно. Менеджеры операций могут за пару минут обновить данные о своих работах в конце рабочего дня. В большинстве проектов, где используется данная программа, проводится ежедневный анализ состояния буферов. А если работы по проекту ведутся в несколько смен, то подобный анализ происходит дважды в день. Системный администратор дает разные права разным категориям пользователей, и все они могут работать с одной и той же базой данных. Так обеспечивается единство исходной информации, то есть все заинтересованные лица оперируют одними и теми же данными. Разным категориям пользователей в зависимости от уровня решений, которые им приходится принимать, доступны разные виды анализа и отчетов.

В ходе проекта работа системы управления ССРМ зависит главным образом от менеджеров операций. Они подают сведения о начале и завершении работ, оценивают остаточную длительность идущих операций. На оценке остаточной длительности строятся прогнозы по расходованию буфера, что в свою очередь может повлиять на приоритетность той или иной задачи. Менеджеры операций должны быть достаточно компетентны, чтобы давать реалистичные оценки. Кроме того, они обязаны своевременно подавать сведения об остаточной длительности работ (например, вводить их в программу), чтобы все данные были готовы к регулярным проектным совещаниям. Менеджеров операций необходимо научить вносить информацию в систему, где бы они ни находились и чем бы ни были заняты.

Менеджер операции также несет ответственность за конечный результат порученных ему работ. Он обязан обеспечить скорейшее получение результата, невзирая на обстоятельства. Если работать некому или исполнитель плохо выполняет свои обязанности, менеджер операции должен принять все меры для решения проблемы. Если он понимает, что не в силах справиться с ситуацией и обеспечить выполнение операции, необходимо немедленно обратиться за помощью к руководителю проекта и к начальству соответствующих исполнителей.

8.1.2. МЕНЕДЖЕР ПРОЕКТА

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

Кроме принятия решений по выполнению сроков (на основании отчетов о состоянии буферов), менеджер проекта отвечает за соответствие продукта заявленным техническим характеристикам и за соблюдение бюджета. При ведении проекта бывает необходимо принимать следующие оперативные решения:

• как быть с ситуацией, не предусмотренной планами (например, если не получен ожидаемый результат научных исследований);

• нужно ли для завершения проекта запрашивать дополнительные деньги или время и как это обосновать;

• как запросить расширение содержания проекта (часто приходится просить сузить границы содержания!);

• как разрешить непредвиденный конфликт ресурсов;

• что делать, если наблюдаются отставания в работах, угрожающие своевременному завершению всего проекта;

• как отреагировать на непредвиденные внешние обстоятельства (например, чрезвычайные происшествия, неблагоприятные погодные условия, новые постановления правительства) или нарушенные исходные установки (например, особенности почвы вынуждают сначала установить сваи, прежде чем начинать строительные работы);

• как исправить ошибки.

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

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

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

Менеджер проекта должен работать с диаграммами расходования буфера. Это тоже способ оценки и выявления тенденций. На графике отмечается точка, показывающая, какая часть критической цепи пройдена и какая доля буфера использована (рис. 8.3). При регулярном нанесении этих точек получается контрольная карта, и менеджер проекта может работать с ней по соответствующим правилам. Если точка попадает в «красную» зону, это сигнал к действию. Если четыре точки подряд приближаются к «красной» зоне, это тоже сигнал к действию. Подобные карты особенно важны, если процессы в вашем проекте не находятся в состоянии статистического контроля. Уолтер Шухарт [6] говорил, что данные о тенденциях в подобных ситуациях критичны.

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

8.1.3. МЕНЕДЖЕР РЕСУРСОВ

Менеджер ресурсов (начальник исполнителей) обеспечивает проект рабочей силой. В разделе 8.1.1 отчасти мы осветили систему оценок для менеджера ресурсов в ситуации, когда он же выступает и как ответственный за ту или иную операцию. Менеджеры ресурсов решают также и стратегическую задачу. Они обязаны обеспечить не только проект, но и всю организацию специалистами соответствующей квалификации. Менеджер ресурса-ограничения также может выступать и в роли составителя графика «барабана» для всей организации.

При исполнении своих обязанностей менеджер ресурсов может опираться на данные из различных программ по составлению расписаний. Так, в Microsoft Project можно получить диаграмму долгосрочного спроса на тот или иной ресурс. В большинстве программ есть функция сортировки проектных задач по заданному ресурсу. Результаты могут быть представлены в разных видах, в том числе и в виде диаграммы Гантта. Из полученных отчетов менеджер ресурсов должен спланировать предстоящие для его людей работы.

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

8.2. Управление при помощи буфера

Система оценок и контроля ССРМ основана на методе «барабан — буфер — веревка». Для отслеживания статуса работ на критической цепи используются данные о состоянии буферов. Наличие четких критериев для принятия решений позволяет избежать двух ошибок: ненужного вмешательства и опасного бездействия. В разделе 6.4.3 описывались четкие границы принятия решений, на которые должен ориентироваться менеджер проекта. Проектный буфер — важнейший инструмент для отслеживания ситуации по проекту.

8.2.1. СОВЕЩАНИЯ ПО ПРОЕКТУ

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

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

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

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

8.2.2. ОТЧЕТ О СОСТОЯНИИ БУФЕРА

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

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

Оптимальный способ обеспечить клиента точной информацией — приглашать его на проектные совещания. Другой вариант — предоставить заказчику доступ в систему, где вы планируете и ведете проект.

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

Сейчас — в наш век компьютеров и специализированных программ для управления проектом — намного проще составлять объемные отчеты. В комиксах про Дильберта¹⁶ была затронута проблема больших отчетов: начальник в офисе использует увесистый том отчетов в качестве подставки для ног. Отчетность должна помогать вести проект, а не занимать драгоценное время и без того занятых исполнителей. Поэтому в них должна содержаться только действительно интересная для клиента информация. На рис. 8.6 приводится шаблон простого — всего на одну страницу — отчета о состоянии проекта. В нем должен быть минимум данных, только то, что нужно клиенту, а также краткое резюме. Рис. 8.7 и 8.8 показывают, как можно представить статус работ портфеля проектов.

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

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

8.3. Буфер на затраты

Зачастую бюджет проекта играет не менее важную роль, чем расписание. Иногда затраты являются абсолютным ограничением в проекте. В таких случаях есть смысл применить управление при помощи буфера и к затратам, чтобы держать их в рамках заложенного бюджета. В разделе 6.5 рассказывается, как определить размер буфера на затраты.

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

8.3.1. СОСТОЯНИЕ БУФЕРА НА ЗАТРАТЫ

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

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

Есть еще одна причина, по которой нельзя напрямую сравнивать фактические и плановые затраты на определенную дату. Ведь фактические расходы на данный момент показывают, сколько денег потрачено на фактически выполненный к этому времени объем работ. В то же время плановый уровень затрат рассчитывался из планового объема работ, то есть из того, сколько операций мы, по расписанию, должны были бы выполнить к определенной дате. Основная идея ССРМ заключается в том, что под влиянием вариабельности фактическое положение дел никогда полностью с планом не совпадает. Поэтому для определения состояния буфера пользуйтесь методом освоенного объема. Как говорилось в главе 3, этот метод разработан именно с учетом разницы между оценочными и фактическими величинами, правильно оценить и понять эту разницу нельзя без сопоставления освоения бюджета и графика выполнения проекта.

8.3.2. МЕТОД ОСВОЕННОГО ОБЪЕМА ВКРАТЦЕ

В методе освоенного объема используются три ключевых понятия:

1. Фактическая стоимость выполненных работ (Actual Cost of Work Performed). Это та сумма, которую вы потратили на проект к определенному моменту (по различным статьям расходов в соответствии со структурой проекта). В РМВОК редакции 2000 года используется термин «фактическая стоимость» (actual cost).

2. Плановая стоимость запланированных работ (Budgeted Cost of Work Scheduled). Это бюджет проекта, расписанный по времени. РМВОК 2000 называет его также «плановый объем» (planned value).

3. Плановая стоимость выполненных работ (Budgeted Cost of Work Performed). Это освоенный объем. Вы смотрите, сколько средств (от 0 до 100%) предусмотрено бюджетом на данные операции (даже если на самом деле потрачено больше или меньше). В РМВОК 2000 это называется «освоенный объем».

Обратите внимание, это отчасти новая терминология, которая появляется в РМВОК 2000. Я привожу ее здесь для информации, но применять далее не буду, так как пока она еще широко не используется¹⁷.

Фактическая стоимость выполненных работ — это просто расходы на текущий момент. Плановая стоимость запланированных работ — это бюджет на текущий момент. Единственное новое понятие — освоенный объем, или плановая стоимость выполненных работ. Разница между проектными расходами на текущий момент и бюджетом — это отклонение в освоении бюджета. Она складывается из двух частей: отклонение в расходах и отклонение от расписания, о котором мы поговорим позже.

8.3.3. РАСХОДОВАНИЕ БУФЕРА НА ЗАТРАТЫ

Для определения состояния буфера на затраты можно ориентироваться на показатель «отклонение по стоимости» (CV, cost variance). Однако нельзя при этом забывать, что положительное отклонение в расходах — это хорошо, ведь вы завершили больше работ за те же деньги; иными словами,

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

Отклонение _ Плановая стоимость Фактическая стоимость по стоимости выполненных работ ^- выполненных работ

Эту часть метода освоенного объема можно смело использовать в ССРМ, учитывая ряд правил по определению фактической стоимости выполненных работ, о которых расскажем далее.

8.3.4. ПРОБЛЕМА

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

Чтобы спрогнозировать, сколько денег будет потрачено к концу проекта, можно использовать первоначальную оценку бюджета на конец проекта (бюджет по завершении) и индекс выполнения стоимости:

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

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

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

8.3.5. ЗАТРАТЫ НА ОПЛАТУ ТРУДА

В некоторых компаниях освоенный объем измеряется не в долларах, а, например, в человеко-часах или человеко-днях. ВМС США в терминологии освоенного объема заменили слово «стоимость» на слово «количество». Использование такого подхода по отношению к затратам на зарплату дает информацию, более полезную для управления работами. Посмотрим далее, почему так происходит.

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

8.3.6. ЗАТРАТЫ НА МАТЕРИАЛЫ

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

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

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

Материальные обязательства — это общая сумма всех подписанных контрактов, которая в бухгалтерских системах еще не отнесена к статье расходов. Вы могли заложить в бюджет $10 000 на приобретение определенного вида оборудования. А потом пришлось заключать договор уже на сумму 15 000 долларов, так как это оказался самый оптимальный вариант, доступный на момент размещения заказа. Разницу необходимо отразить в показателе «отклонение в расходах» сразу же по факту подписания контракта, ведь это затраты, которые лягут на ваш проект. В большинстве финансовых систем данное расхождение никак не проявится до тех пор, пока не будет проведена соответствующая операция и/или сделаны соответствующие выплаты. Некоторые системы управления проектом не предусматривают возможности вносить подобные изменения в бюджет. Поэтому придется отдельно учесть появившуюся разницу между плановой и фактической величиной расходов и показать ее в отчете о состоянии буфера на затраты.

8.3.7. КАК СОВМЕСТИТЬ МЕТОД ОСВОЕННОГО ОБЪЕМА И УПРАВЛЕНИЕ ПРИ ПОМОЩИ БУФЕРА

Управлять буфером на затраты можно так же, как другими видами буферов. На рис. 8.10 приведен график состояния буфера на затраты, показывающий соотношение потребления буфера в процентах и доли потраченного бюджета на выполнение операций, также в процентах. БПЗ — это бюджет по завершении, то есть оценка бюджета на конец проекта, включающая буфер на затраты. Процент потраченного буфера на затраты — это отклонение по стоимости, поделенное на буфер на затраты и выраженное в процентах. Процент освоенного бюджета на выполнение операций — это освоенный объем (плановая стоимость выполненных работ) в процентах от общей плановой стоимости всех проектных работ. Чтобы рассчитать плановую стоимость не до конца выполненных работ, можно использовать любой из традиционных методов:

• пока операция не завершена, она ничего «не стоит»;

• 50% после начала операции, 50% — по завершении;

• оцениваем примерное расходование средств по ходу операции.

Поскольку в каждый момент времени должно выполняться не очень большое количество операций, нет большой разницы между тем, какой из методов вы изберете.

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

8.3.8. ТАК НАЗЫВАЕМОЕ ОТКЛОНЕНИЕ ПО СРОКАМ

Кто-то пытается использовать метод освоенного объема также для отслеживания статуса выполнения графика проекта. Для этого необходимо проанализировать данные о фактическом выполнении проектных работ в соотношении с бюджетом проекта. Регулярность такого анализа зависит от ритма работы бухгалтерии, поэтому обычно он происходит раз в месяц, реже — раз в неделю. Подобные отсрочки нежелательны для проектов и чреваты проблемами. Ведь полученные таким образом данные о прохождении графика — это уже история. Принимать управленческие решения на основе этих данных — все равно что управлять машиной, глядя исключительно в зеркало заднего вида.

По аналогии с «отклонением по стоимости» и «индексом выполнения стоимости» в литературе по освоенному объему говорится об «отклонении по срокам» (SV, schedule variance) и «индексе соблюдения сроков» (SPI, schedule performance index). На мой взгляд, названия вводят в заблуждение, поскольку на самом деле понятия эти никакого отношения к распи

Так называемые «отклонение по срокам» и «индекс соблюдения сроков» на самом деле служат для оценки расходов. Они не учитывают критическую цепь или путь и, соответственно, не дают ответов на вопросы руководства об ожидаемых сроках выполнения работ. Эти показатели никак не помогут вам рассчитать, когда завершится проект. Давая информацию о расходах, иногда они мотивируют исполнителей браться в первую очередь за наиболее затратные, а не за наиболее срочные работы. Руководитель проектов крупнейшей в мире строительной компании гордо назвал такой метод управления «стратегией улучшения денежного потока и прибыльности проектов». Не рекомендую вам применять подобные методы.

Понятия освоенного объема, в названиях которых использовано слово «сроки», не подскажут вам, когда необходимо вмешаться, чтобы не допустить срыва сроков. У своевременно выполненного проекта показатель «отклонение по срокам» будет равняться нулю, а «индекс соблюдения сроков» — единице. Если проект занял вдвое больше времени, все равно отклонение в расписании у него будет нулевое, а индекс выполнения расписания — единица. Эти параметры не имеют никакого отношения к фактическому состоянию дел с прохождением графика. Поэтому для оценки и контроля исполнения плана используйте отчеты о состоянии буфера, рекомендованные ССРМ.

санию и срокам не имеют. Они не подходят для контроля за выполнением расписания и могут натолкнуть на ошибочные решения. Вычисляются эти показатели по следующим формулам:

8.4. Оценка качества

Основы управления качеством проекта описал Льюис Айланд [8]. ССРМ напрямую не фокусируется на процессах управления качеством. Теория ограничений ставит во главу угла качество процесса и продукта, поскольку это важно для достижения цели компании. По сути, ТОС — это процесс непрерывного совершенствования. В целом модель ССРМ полностью соответствует требованиям, которые ISO 9000 предъявляет к системам управления качеством.

В «Синдроме стога сена» (The Haystack Syndrome) Голдратт [2] говорит, что эффективной единицей измерения уровня качества является «количество долларов в день». Доллар/день — это выраженные в денежном эквиваленте последствия несоответствия чего бы то ни было заявленным требованиям. Хотя в сегодняшнем деловом мире нужно сильно постараться, чтобы найти компанию, использующую этот показатель, логика Гол-дратта достойна внимания. Распишу ее подробней.

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

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

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

Где взять данные для вычисления показателя «доллар/день»? Вариантов несколько. С одной стороны, это может быть скорость потребления выделенных ежедневно на каждую операцию средств. Другой вариант — ежедневная выгода от реализации всего проекта. Второй вариант в явном виде подходит для операций, связанных с критической цепью, на выполнение которых тратятся запасы из проектного буфера. Так мы сразу фокусируем внимание на самом больном для проекта месте. По операциям, не находящимся на критической цепи и не вызывающим расход проектного буфера, ориентируемся на скорость потребления выделенных на данную операцию средств.

8.5. Ответная реакция на сигналы буфера

8.5.1. РАСХОД ВРЕМЕННОГО БУФЕРА ПЕРЕШЕЛ ЖЕЛТУЮ ГРАНИЦУ

Это предупреждение о возможном превышении расхода буфера, которое негативно скажется на соблюдении графика проекта. Время планировать меры по пополнению буфера за счет текущих или последующих операций в цепи. Есть три способа сократить длительность операции: увеличить число исполнителей, сократить объем работ или усовершенствовать процесс выполнения операции. В табл. 8.1 перечислены некоторые меры по сокращению степени потребления временного буфера.

8.5.2. РАСХОД БУФЕРА НА ЗАТРАТЫ ПЕРЕШЕЛ ЖЕЛТУЮ ГРАНИЦУ

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

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

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

8.5.3. РОСТ ПОКАЗАТЕЛЯ «ДОЛЛАР/ДЕНЬ»

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

8.5.4. РАСХОД ВРЕМЕННОГО БУФЕРА ПЕРЕШЕЛ КРАСНУЮ ГРАНИЦУ

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

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

8.5.5. РАСХОД БУФЕРА НА ЗАТРАТЫ ПЕРЕШЕЛ КРАСНУЮ ГРАНИЦУ

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

8.5.6. РАСХОД БУФЕРА ПРЕВЫСИЛ 100%

Если у вас готов план пополнения буфера в конце проекта, ничего делать не нужно. Если плана нет, придется вносить в проект изменения. Возможно, нужно будет пересмотреть дальнейшие работы и пересчитать размеры необходимых буферов. Когда буфер растрачен более чем на 100%, а возможности пополнить его нет, он перестает быть инструментом контроля.

8.6. Контрольные события

Некоторые считают, что метод ССРМ противоположен методу управления по контрольным событиям. Точно не знаю, на чем основано это заблуждение, но могу предположить, что причина в неправильной трактовке слов Голдратта о бессмысленности установления четких дат контрольных событий без одновременного добавления соответствующих буферов. В разделе 5.6 я говорил, что считаю контрольные события действенным инструментом в управлении проектом. Когда проект продолжительный, контрольные события помогают направлять работу команды и планировать вознаграждения. Я всегда стремлюсь к тому, чтобы каждый квартал был пройден хотя бы один значительный этап проекта (наступило одно из запланированных ключевых событий).

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

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

8.7. Действия по управлению изменениями

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

• изменением считается вмешательство в логику плана (например, добавление и удаление операций, изменение порядка расположения операций);

• изменением считается серьезный пересмотр объема работ по операции (продумайте, что вы будете понимать под словом «серьезный»);

• изменением считается серьезный пересмотр требований к исполнителям операций (по количеству или квалификации); возможно, после этого потребуется пересмотреть также критическую цепь;

• перерасход или экономия времени, выделенного на операцию, не считается изменением;

• перерасход или экономия средств, выделенных на операцию, не считается изменением;

• изменения плана могут потребоваться по достижении критических границ расходования буферов (проектного, на слияние путей, на затраты);

• процесс управления изменениями должен работать быстро; для принятия решений о внесении изменений можно создать комиссию по контролю за изменениями и при необходимости включить туда представителя заказчика.

Не забывайте, что ваша задача — управлять не планом, а проектом при помощи плана. Например, нет необходимости вносить изменения в буфер на основании фактических данных о текущем статусе проекта.

8.8. Вопросы, наиболее часто задаваемые по оценке и контролю

1. Уже прошла половина проекта, а проектный буфер не тронут. Можно ли сократить его вдвое?

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

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

2. Почему список приоритетов операций у нас меняется каждый день?

Список работ по приоритетам может меняться каждый раз, когда вы обновляете расписание в соответствии с текущим статусом. Просто объясните, что исполнители должны довести до конца уже начатую работу, а затем взяться за следующую в списке приоритетов. Это обеспечит максимально быстрое выполнение проекта.

3. Судя по списку приоритетов, я должен сначала выполнить менее важную работу и лишь потом приняться за более приоритетную. Как такое возможно?

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

4. Я еще даже не начинал работать над задачей, а она уже попала в красную зону в отчете по буферу. Почему мне приходится отвечать за то, что кто-то не выполняет свои обязанности?

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

5. Почему в списке приоритетов некоторые задачи показаны как важные, в то время как мы знаем, что они менее приоритетны, чем некоторые другие?

Это может быть проявлением ошибочного выстраивания проекта. Иногда такое случается, когда при планировании ресурсов необходимо подогнать требования под то, что имеется в наличии. Работая со списком приоритетов, полагайтесь на здравый смысл. Вы должны понимать, почему та или иная операция попала в начало списка. Бывают и сюрпризы! Иногда исполнитель решает сделать сначала работу полегче, даже если она и менее важна, в надежде, что менее приятную операцию выполнит кто-то другой. Вы не должны этого допускать.

8.9. Итоги

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

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

2. Проектные совещания, посвященные конкретным проблемам и базирующиеся на заранее собранных данных о статусе работ, — мощный инструмент для успешного доведения проекта до цели.

3. Превентивное планирование и исполнение действий по пополнению буфера — важные составляющие процесса управления ССРМ.

4. Если затраты — существенный для вашего проекта фактор, для отслеживания состояния буфера на затраты используйте показатели по буферу и освоенному объему (плановой стоимости выполненных работ). Не применяйте показатель «освоенный объем» для отслеживания статуса выполнения расписания.

5. ССРМ ставит во главу угла качество процесса и продукта, поскольку это важно для достижения цели компании.

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

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

ЛИТЕРАТУРА

1. Juran, Joseph J., Juran on Planning for Quality, New York: The Free Press, 1988.

2. Goldratt, Eliyahu M., The Haystack Syndrome, Croton-on-Hudson, NY: North River Press, 1990.

3. Herroelen, W., R. Leus, and E. Demeulemeester, “Critical Chain Project Scheduling: Do Not Oversimplify.” Project Management Journal, Vol. 33, No. 4, December 2002, рр. 48-60.

4. Программа ССРМ+, доступна по адресу http://www.advanced-projects.com/ CCPM+.htm (материал для книги взят в июне 2004 года).

5. Программа Concerto, доступна по адресу http://www.Realization.com (материал для книги взят в июне 2004 года).

6. Shewhart, Walter A., Statistical Method from the Viewpoint of Quality Control, New York: Dover Publications, 1986 (впервые опубликовано в 1939 году).

7. PMI, A Guide to the Project Management Body of Knowledge, Newton Square, PA: PMI, 2000 (в русском переводе: Руководство к своду знаний по управлению проектами. 3-е изд. (Руководство РМВОК).

8. Ireland, Lewis R., Quality Management for Projects and Programs, Upper Darby, PA: PMI, 1991.

Глава 9. Как внедрить метод ССРМ

Многие компании, даже раньше никогда не проводившие организационных преобразований, довольно быстро перестраиваются на работу по методу ССРМ. Всего три месяца уходит у них на то, чтобы по-новому спланировать и синхронизировать свои проекты. Результаты проявляются незамедлительно: растет количество успешных проектов, снижается нагрузка на проектные команды. Причем успех не зависит от размера организации или типа проекта.

Читатели первого издания этой книги, а также слушатели двухдневного вводного курса ССРМ сообщали мне о том, что сумели добиться больших результатов, внедрив метод критической цепи для управления отдельными проектами. К сожалению, бывают случаи, когда компания после нескольких попыток по тем или иным причинам отказывается от ССРМ в управлении как отдельными, так и одновременно идущими проектами. У других (как правило, крупных) организаций на переход к управлению всеми проектами по методу ССРМ может уйти больше года. Предлагаю вашему вниманию проверенный процесс внедрения ССРМ как в компаниях, реализующих отдельные проекты, так и в компаниях, системно управляющих несколькими проектами одновременно. Вам также будет представлено теоретическое обоснование данного подхода.

9.1. Модель внедрения ССРМ

На рис. 9.1 дана упрощенная схема проекта по внедрению метода критической цепи. Внедрение чего-либо — это ведь тоже проект. В зависимости от особенностей организации планы таких проектов могут различаться по содержанию. Далее мы рассмотрим примерный план. По описанным ниже этапам должно проходить внедрение любого нового подхода. При этом степень детализации и широта охвата вашего плана, конечно, будут учитывать специфику конкретной ситуации. В разделе 9.2 вы познакомитесь с теоретическими обоснованиями предложенного плана.

9.1.1. УТВЕРДИТЬ ПРОЕКТ ПО ВНЕДРЕНИЮ ИЗМЕНЕНИЙ

Первые два пункта в разработанной Коттером модели проведения успешных преобразований [1] предусматривают создание ощущения необходимости перемен и формирование мощной руководящей коалиции. В нашей схеме они реализуются на этапе утверждения проекта. Необходимо найти тех, кто готов возглавить перестройку стиля работы компании, и четко объяснить им, для чего это нужно. Как говорит Коттер, в 50% случаев процесс изменений заканчивается, так и не начавшись, потому что инициатору не удается обосновать важность перемен. Как правило, чем к более высоким чинам вы обращаетесь, тем больший отклик в их душе найдет такой аргумент, как хорошие количественные показатели, обеспечиваемые методом критической цепи. Поскольку ССРМ предполагает тесное сотрудничество менеджеров проектов и менеджеров ресурсов, то создание сильной руководящей коалиции при внедрении метода для системного управления одновременными проектами, пожалуй, более важно, чем при любых других организационных изменениях.

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

В своей модели Коттер основывается на широко распространенном убеждении, что серьезные преобразования невозможны без активной поддержки со стороны высшего руководства. Как показала практика, в случае с ССРМ это действительно так. Однако я заметил, что сейчас активной поддержки формальных лидеров компании бывает недостаточно. Коттер пишет:

«Чтобы трансформация прошла успешно, собираются вместе председатель совета директоров или президент подразделения, генеральный директор и еще 5, 15 или 50 человек и договариваются, что необходимо путем обновления организации добиться улучшения показателей компании. По моим наблюдениям, в эту группу входят далеко не все топ-менеджеры организации, поскольку не все, по крайней мере сначала, поддерживают изменения. Однако правящая команда менеджеров иногда оказывается достаточно сильной, как по составу, так и по уровню опыта и знаний, и преобразования дают хороший результат» (с. 6).

Мой опыт внедрения ССРМ полностью подтверждает наблюдения Коттера.

9.1.2. РАЗРАБОТАТЬ УСТАВ ПРОЕКТА ПО ВНЕДРЕНИЮ ИЗМЕНЕНИЙ

Посмотрите примерный устав проекта по внедрению метода ССРМ. Старайтесь, чтобы ваш документ был не больше одной страницы и учитывал интересы участников проекта.

9.1.3. С САМОГО НАЧАЛА НУЖНО ИМЕТЬ ВИДЕНИЕ КОНЕЧНОЙ ЦЕЛИ

Если вы не знаете, куда идете, то как вы поймете, что уже добрались до цели? Видение идеального результата можно оформить разными способами. Согласно третьему пункту модели Коттера, необходимо сформулировать видение будущих перспектив, то есть показать, как будет работать компания после внедрения ССРМ. Очень полезно бывает использовать графические средства представления информации, так как многие лучше воспринимают визуальные образы, чем любые иные. Представьте, что будет представлять собой ваша организация, когда станет работать по ССРМ. Инженерам можно, например, показать какой-нибудь график. Менеджерам проектов — диаграмму Гантта, включающую элементы критической цепи. Начальникам рабочих групп нужно говорить о людях. Я предпочитаю рассказывать о моделях поведения, необходимых для успешной работы ССРМ. Руководство многих компаний ошибочно полагает, что главное — закупить специальное программное обеспечение. Нет, суть не в этом. Главное, что предстоит сделать, — это изменить привычный стиль поведения людей.

Четвертый и пятый постулаты Коттера говорят о необходимости сообщить всем о своем видении цели и уполномочить людей действовать в соответствии с ним. Видение перспектив работает, если о нем знает не только автор. Все, кого касаются перемены, должны быть готовы объяснить, к чему они ведут. После того как вы донесли до коллег, в чем видите конечную цель преобразований, следует дать им возможность внедрять преобразования и преодолевать встающие на пути препятствия. В таблицах 9.1 (а-е) даются перечни тех перемен, которые ожидают участников проекта.

9.1.4. РАЗРАБОТАТЬ ПЛАН УПРАВЛЕНИЯ ПРОЕКТОМ ПО ВНЕДРЕНИЮ ИЗМЕНЕНИЙ

Следующий за уставом проекта этап — создание плана проекта. План управления проектом включает в себя

1) подробное описание содержания проекта;

2) иерархическая структура работ для выполнения проектного задания;

3) список ответственных по элементам ИСР;

4) расписание проекта с выровненными ресурсами (критическая цепь);

5) бюджет проекта;

6) описание команды проекта;

7) рабочие процедуры команды проекта;

8) план закрытия проекта.

На рис. 9.2 представлена ИСР проекта по внедрению ССРМ. В ней учтены те преобразования, которые необходимы для перехода на управление по ССРМ, и правила, выработанные Коттером [1]. Также смотрите раздел 9.2. Шестой пункт модели Коттера предусматривает скорейшее внедрение того, что можно выполнить быстрее всего. Обязательно включите этот пункт в ваш план проведения преобразований.

Для того чтобы компания могла работать по методу ССРМ, необходимо не только изменение модели поведения сотрудников, но и соблюдение некоторых технических условий, а именно:

1) планы создаются по правилам ССРМ (длительность операций с вероятностью 50%, критическая цепь, буферы правильной величины);

2) менеджер «барабана» разрабатывает график «барабана» в соответствии с назначенными руководством приоритетами;

3) на основании графика «барабана» создаются планы всех проектов;

4) исполнители работают в стиле эстафеты;

5) исполнители объективно оценивают остаточную длительность своих операций;

6) чтобы не допустить многозадачности и определить, какие работы выполнять, исполнители и их начальство ориентируется на список приоритетов;

7) когда размер буфера попадает в желтую зону, менеджер проекта продумывает план действий по пополнению буфера и реализует этот план, когда буфер оказывается в красной зоне.

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

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

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

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

Два последних пункта из свода правил Коттера должны также найти отражение в ИСР и графике проекта: следует углублять преобразования, концентрировать улучшения и закрепить новый подход. На завершающем этапе нужно обеспечить включение метода ССРМ во все политики, процедуры, систему оценок, а также в программы обучения персонала, чтобы и новые сотрудники понимали процесс и вливались в него. ССРМ не должен восприниматься как чья-то необязательная для исполнения прихоть, факультативный изыск. Все должны осознавать, что это стиль работы компании.

Рис. 9.3 представляет собой график внедрения ССРМ. Это модифицированная под работу с критической цепью диаграмма Гантта, знакомая по Microsoft Project, в том виде, который предлагает специальная программа ССРМ+. Перечислены все операции проекта. Входящие в критическую цепь выделены цветом (по черно-белой иллюстрации, конечно, трудно представить, как это выглядит). Также обозначены те задачи, которые можно выполнить досрочно, не боясь накладок с исполнителями. Если проект является частью системы одновременно идущих в компании проектов, не беритесь за эти задачи раньше времени, чтобы не вызвать конфликт расписания.

В этом графике показаны только даты наступления ключевых событий и завершения проекта (с учетом проектного буфера). Начало запланировано на 2 января 2005 года, а конец проектного буфера помечен 12 октября того же года. Величина буферов (проектного и на слияние путей) равняется половине длины предшествующих им цепочек работ. Обратите внимание: каждый элемент из ИСР в графике разбит на 4-8 операций. Это не значит, конечно, что в пакет работ должно входить не более 8 операций. Чаще всего количество задач в пакете достигает 25.

Большую часть критической цепи составляет пилотный проект. На него заложено 60 рабочих дней, то есть почти три календарных месяца. Смысл его — выявить возможные препятствия на пути внедрения ССРМ в организации, а также испытать процедуры, разработанные для ведения полноценных проектов. Для того чтобы решить эти задачи, не обязательно выполнять пробный проект полностью. Формально можно объявлять об успешном завершении пилотного проекта, когда собрано достаточно информации и получены подтверждения того, что компания готова к следующему этапу внедрения ССРМ.

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

9.1.5. СПЛАНИРОВАТЬ ДЕЙСТВИЯ

ПО ПРЕДОТВРАЩЕНИЮ ИЛИ СНИЖЕНИЮ РИСКОВ

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

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

В табл. 9.2 представлен план управления рисками в формате, описанном в следующей главе и универсальном для всех типов проектов. Ваш реестр рисков будет отличаться от приведенного ниже, следовательно, у вас обязательно будет выработан свой план реагирования на чрезвычайные ситуации. Чтобы понять смысл цифр в колонках с третьей по пятую, посмотрите толкования обозначений ниже в таблице. Запомните, если вероятность наступления риска больше 50%, при планировании управления проектом мы предполагаем, что соответствующее событие на самом деле произойдет. По замыслу управления рисками следует регулярно пересматривать план в ходе реализации проекта.

Таблица 9.2. Пример плана управления рисками по проекту «Внедрение ССРМ»
№	Риск	В	П	Р	Меры по предотвращению	Меры по снижению степени влияния
1	Пилотный проект идет неудачно	2	2	4	Проанализировать, все ли было готово к запуску проекта	Регулярно отслеживать статус, консультировать менеджера проекта и команду проекта
2	Высшее руководство не соблюдает модель поведения, необходимую для успеха ССРМ	2	3	6	Обучить высшее руководство. Добиться поддержки со стороны руководства	Устроить тренинги для высшего руководства, рассмотреть правила принятия решений
3	Проекты, которые запущены по ССРМ, требуют участия исполнителей, задействованных в других проектах (управляемых не по ССРМ)	3	1	3	Для внедрения метода выбрать проекты, которые не пересекаются по ресурсам с другими	Обучить менеджеров ресурсов, как снимать конфликты за ресурсы и не допускать негативной многозадачности
4	Субподрядчики не работают по ССРМ	2	2	4	Включать соответствующие требования в контракты с субподрядчиками	Провести обучение субподрядчиков
5	Составлены некорректные диаграммы проектов	2	3	6	Для первых попыток планирования привлечь опытных консультантов	Пересмотреть планы проектов в рамках управления изменениями
Принятые обозначения: В (Вероятность)3 = 20-50%2 = 5-20%1 = < %		П (Последствия)3 = > чем проектный буфер2 = > от проектного буфера,< чем проектный буфер 1 = < 20%				Р (Рейтинг) = В х П

9.1.6. ДЕЙСТВУЙТЕ!

В таблицах с 9.3 по 9.5 перечислены действия, необходимые для внедрения ССРМ в крупных компаниях, где реализуется большое число одновременных проектов. Выполняйте эти рекомендации в той мере, в какой требует ваш конкретный проект.

Все мероприятия из табл. 9.3 можно уложить в однодневную встречу-совещание. Лучше всего, чтобы такое совещание состоялось сразу после двухдневного тренинга, знакомящего менеджмент с основами метода критической цепи. Нельзя, чтобы между этими двумя событиями прошло слишком много времени, поскольку содержание тренинга быстро выветрится из головы, если теория не получит скорейшего подкрепления на практике.

В табл. 9.4 показано, что необходимо сделать, чтобы начать внедрение ССРМ. В ходе совещаний с руководством, возможно, обсуждалась необходимость в дополнительных тренингах. Проведите обучение, если необходимо. При этом ни в коем случае не откладывайте выполнение пунктов 4 и 5. Шаги 3-5 нужно пройти с командой каждого проекта в отдельности. Всего на планирование должно уйти не более пары недель. Если проектов много, придется привлекать дополнительных консультантов, чтобы процесс не затянулся.

Табл. 9.5 дает список шагов по завершению проекта и переходу к использованию метода ССРМ в повседневной деятельности компании. Не позднее чем через три недели после первого тренинга для руководства необходимо установить процесс отчетности о состоянии буфера, иначе проект застопорится. Люди быстро забудут про правила критической цепи, что сильно подорвет шансы на успешное внедрение метода.

Приступив к использованию ССРМ на реальных проектах в рамках внедрения, вы столкнетесь с массой вопросов и проблем. Важно так построить работу, чтобы люди быстро получали ответы на свои вопросы, чтобы соответствующая информация была доступна всем, кому она необходима, и чтобы проблемы решались без промедления. Этот процесс может быть частью системы оценки и контроля.

9.1.7. ОЦЕНКА И КОНТРОЛЬ ВНЕДРЕНИЯ

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

Помимо этого, при изучении другой поступающей информации следует помнить, что:

1) список проектов по приоритетам служит ясным основанием для принятия решений;

2) график «барабана» и основанное на нем разнесение запусков проектов по времени почти полностью устраняют конфликт за ресурсы между командами проектов;

3) управление при помощи буферов — понятный инструмент для принятия решений по распределению ресурсов между проектами;

4) исполнитель должен работать над одной задачей, причем руководство должно приветствовать такой подход к делу;

5) исполнителей, участвующих в проекте, не должны перебрасывать внезапно на новые, более важные проекты;

6) количество изменений и соответствующих переделок сводится к минимуму, поскольку проекты начинаются позже и заканчиваются раньше;

7) количество изменений уменьшается, потому что критическая цепь не меняется;

8) количество изменений уменьшается, потому что некоторые случаи отклонений в выполнении работ, которые обычно вели к пересмотру хода проекта, теперь не попадают за границы принятия решений и не требуют принятия каких-либо мер.

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

Есть ряд естественных положительных явлений, которые свидетельствуют в пользу метода ССРМ. Например:

1) ввиду устранения многозадачности сотрудники компании испытывают меньшие нагрузки и меньшее давление со стороны руководства;

2) получая положительные результаты от внедрения метода ССРМ, команды проектов убеждаются в его действенности;

3) видя растущие показатели реализации проектов, руководство также убеждается в эффективности ССРМ;

4) наблюдая рост прибыли, руководство укрепляется в мысли о положительной роли метода критической цепи.

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

Составив список проектов и расставив их по приоритетам, руководство затем должно:

1) участвовать в управлении при помощи буферов;

2) обеспечить назначение приоритета всем новым проектам и их планирование с учетом графика «барабана».

9.1.8. КАК БЫТЬ, ЕСЛИ ВНЕДРЕНИЕ БУКСУЕТ?

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

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

следуя утверждению Деминга о том, что 96% проблем в компании происходят по вине руководства (и опыт это доказал), могу рекомендовать вам начать «с головы» — пристально изучить поведение менеджмента организации.

9.2. Теория организационных преобразований

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

Нам с вами важно помнить, что люди с большой опаской относятся к переменам. Статистика успешных преобразований неутешительна. Мюррей Дальциль и Стивен Шуновер [2] отмечают: «Руководители-технократы, с другой стороны, сосредоточены исключительно на результатах и не задумываются об опасениях тех, кому придется воплощать в жизнь планы изменений и работать в новой среде». В разряд руководителей-технократов попадают и менеджеры проектов (включая меня самого), поэтому обвинения Дальциля и Шуновера касаются и нас. Далее авторы пишут: «Такой подход чаще всего приносит ряд краткосрочных результатов, сопровождающихся непредвиденными проблемами и — в дальнейшей перспективе — глубоким разочарованием».

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

9.2.1. МОДЕЛЬ «СЕМЬ С»

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

Планируя переход на метод критической цепи, примените эту модель к вашей организации. Как правило, достаточно удостовериться, что при составлении плана вы учли все особенности вашей компании, которые могут помешать внедрению или вызвать непредвиденные последствия. Чтобы внедрить ССРМ, нет необходимости перекраивать структуру организации. Успешно смогли перейти на работу по ССРМ компании как с полностью проектной, так и с матричной структурой.

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

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

В большинстве организаций для успешного внедрения ССРМ важно изменить привычные модели поведения. Что именно придется менять, зависит от рабочей культуры и правил вашей компании. В табл. 9.1 представлен ряд мер, в рамках которых вы сможете провести сравнительный анализ текущего и желаемого состояния вашей организации. Таблица составлена с учетом модели «семь С» и типовых для бизнеса поведенческих рисунков.

Метод ССРМ обладает рядом свойств, благодаря которым провести его внедрение значительно легче, чем многие другие преобразования:

1) проигравших нет;

2) многие вдобавок получают при внедрении что-то важное;

3) все очень просто;

4) результаты видны очень быстро.

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

9.2.2. 3-4-3

Приведу несколько любопытных историй, касающихся основ теории управления. Однажды докладчик на одной конференции по вопросам управления поведал аудитории о правиле «3-4-3», с которым познакомился в ходе изучения вопросов внедрения «кайдзен» («непрерывное совершенствование» по-японски). Как объяснил ему японский коллега, при проведении любых преобразований в любой компании трое сотрудников из десяти, как правило, загораются новой идеей и немедленно начинают ее использовать. Еще трое остаются совершенно равнодушными к новшеству. И четверо занимают выжидательную позицию, присоединяясь к отряду сторонников перемен, только когда новая идея укоренится в компании.

Как и когда приступать к преобразованиям, зависит, конечно, от типа преобразований и от особенностей организации. Я как-то вычитал, что у вооруженных сил Великобритании ушло 125 лет на то, чтобы перейти к использованию асимметричной обуви (разные ботинки для левой и правой ноги). Так и слышу возмущение армейских снабженцев: «Да вы что, ребята! Вы же требуете от меня хороших показателей. А теперь хотите, чтобы я удвоил запасы? Вы только подумайте, реально ли будет держать обувь отсортированной по размерам, чтобы пары не перепутались при пересылке с фабрик на склады и по подразделениям! Расходы взлетят. Сроки поставок вырастут. Да солдаты такие ботинки и надеть-то не смогут. Вы только все усложняете!» Подобные доводы звучали на протяжении 125 лет. Конечно, англичане могли использовать другие формулировки, но суть, без сомнений, была именно такой.

Как считается в научных кругах, чтобы старая теория уступила место новой, должно пройти 25 лет и смениться целое поколение ученых. Кто-то утверждает, что даже два поколения. Чтобы утвердилась новая теория, должны уйти из жизни все сторонники старой. Но это, конечно, справедливо только для нашего цивилизованного века просвещения. Раньше проблема решалась проще: либо сажали в тюрьму, как Галилея, либо вовсе рубили голову. Понятно, почему научная революция так долго набирала обороты. Уоррен Беннис [4] выделяет три типа стратегий преобразований:

1) эмпирические, рациональные стратегии — предполагается, что люди сами пойдут на изменения, так как им это выгодно;

2) стратегии перестройки норм — изменения в организационной структуре, перераспределение ролей, пересмотр отношений необходимы;

3) политика силы — следование воле руководства.

Беннис выводит восемь типов программ преобразований:

1) путем демонстрации и продвижения;

2) через элитные группы;

3) путем проведения тренингов по межличностным взаимоотношениям;

4) через сотрудников организации;

5) путем привлечения специализированных консультаций извне;

6) путем скоординированного процесса циркуляции идей;

7) путем эволюционного исследования;

8) путем изучения процессов.

Каждая стратегия предполагает, что для достижения цели необходимо опираться на знания. Большинство стратегий основано на рационалистическом подходе. Однако Беннис замечает, что наличие знаний само по себе не ведет к эффективным действиям. В заключение Беннис пишет:

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

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

Возможно, все перечисленные выше соображения и подходы и справедливы, но это далеко не образчики строгого научного мышления. На каждую историю можно ответить другой историей, которая послужит исключением, подтверждающим правило. Многие компании успешно развиваются и достигают высот за сроки, считающиеся минимальными для успешного проведения преобразований (восемь-десять лет). Другие и за большее время даже сдвинуться с места не могут (пример — католическая церковь).

9.2.3. ПОНИМАНИЕ СИСТЕМЫ

Осознав, что организация — это система динамическая, мы ступаем на почву полноценного научного мышления. Чтобы определить, какие необходимы изменения для достижения желаемых целей, можно использовать модель текущего состояния системы. Поскольку бизнес-системы являются динамическими, такой же должна быть и модель. В данном случае работают «законы пятой дисциплины», описанные в главе 2. Один из самый важных и, пожалуй, самых сложных для понимания и применения — закон «разнесенности» причин и следствий во времени и пространстве. То есть событие, имеющее место сегодня в Милуоки, может оказаться следствием прошлогодних действий руководства в Тампе и вовсе не иметь никакого отношения к новому менеджеру в Милуоки, только что заступившему на этот пост. Да, между событием и новым менеджером есть корреляция, поскольку они совпали во времени и в пространстве, но не прямая взаимосвязь. Никто же всерьез не думает, что результаты финала Суперкубка действительно как-то влияют на фондовый рынок США, однако в СМИ регулярно обсуждаются удивительные совпадения¹⁸.

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

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

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

Ключевой конфликт часто кроется в процедурах оценки или других политиках системы. Он всегда влияет на действия тех, кто работает в данной системе. Чтобы понять, что необходимо изменить в первую очередь, следует — по правилам процесса логических рассуждений — выявить исходные установки и предположения, лежащие в основе конфликта. Затем нужно установить механизм получения обратной связи в будущем, чтобы ускорить переход и суметь удерживать систему в новом ее состоянии.

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

9.2.4. СОПРОТИВЛЕНИЕ ИЗМЕНЕНИЯМ

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

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

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

Сопротивление целой организации как единой системы бывает трудно отличить от препятствий, чинимых по воле отдельных людей. Когда дела идут не так, как хотелось бы, мы часто пытаемся понять, кто же встал на пути прогресса, и вдохновить его на принятие перемен. К сожалению, попытки оказываются бессмысленными. Думаю, у каждого из нас найдется немало знакомых, которые по-настоящему хотели бы похудеть, бросить курить или еще что-нибудь поменять в своих привычках, но которым это никак не удается. А если и удается, то лишь на время. Полагаю, вы согласитесь, что в данном случае проблема не в нехватке вдохновения, мотивации или каких-то умений. И помогут ли им ваши пламенные речи? А может, отправить всех на специальные тренинги?

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

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

9.2.5. В ПЛЕНУ ПАРАДИГМЫ

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

1. Почему в плане проекта, составленном при помощи СРМ, условием для начала операции является только завершение предыдущих работ и наличие их результатов? Чтобы началось выполнение операции, нужен не только результат операции-предшественника, но и наличие исполнителя. Это два одинаково необходимых условия.

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

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

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

Самюэль Калберт [6] считает устойчивость парадигм основной причиной проявления сопротивления переменам. Он пишет: «Очень важно, чтобы вы понимали: восприятие людей определяется абсолютно конкретными интересами, мотивами и движущими силами, которые, однако, вам неведомы и неподвластны». Возможно, вы будете противостоять не одной, а нескольким разным парадигмам. Данную идею он выводит из следующей своей гипотезы: «Организация — это творение направленной на нее мысли». Из чего следует, что «те, кому дают совет, меньше всего настроены воспринимать его как ценную идею и в первую очередь видят в нем угрозу своим планам и происки врагов, блюдущих собственные интересы». Иными словами, сопротивляетесь-то вы — хозяева организации, а не те, кто высказал свое мнение по поводу преобразований. В заключение Кал-берт пишет: «Какой бы очевидной ни была необходимость перемен, формулы трансформации парадигм не существует». Иными словами, универсального способа преодоления власти парадигмы нет.

9.3. Модель сопротивления изменениям по Голдратту

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

1. Это не мои проблемы! (Столкнувшись с трудностями, люди часто склонны винить других и перекладывать ответственность за решение проблемы на чужие плечи.)

2. Несогласие с новым решением. (Люди склонны мыслить в привычных категориях. Считается, что, если не сработало в прошлый раз, значит, просто приложили недостаточно сил, и надо попытаться снова.)

3. Несогласие с некоторыми деталями решения.

4. Да, но... решение приведет к нежелательным последствиям (например, руководство или клиент заставит нас убрать буферы из плана).

5. Да, но. у нас это не сработает. (Есть препятствия, якобы присущие только нашей ситуации.)

6. Беспредметный страх, мешающий двигаться вперед (сопротивление парадигмы).

Голдратт указывает, что, как правило, реакция людей на перемены проявляется именно в указанном порядке. Если где-то посреди пути внедрения нового человек запутывается и теряет ориентацию в происходящем, он вновь возвращается к первому рубежу сопротивления, а не остается на том, где запнулся.

Модель «3-4-3», описанная ранее, показывает, насколько трудно, в общем случае, провести большую организацию, состоящую из множества людей, через все рубежи сопротивления.

9.4. Нужен ли пилотный проект

Чаще всего, когда в компании рассматривается предложение внедрить ССРМ, руководство говорит: «Давайте сделаем сначала пробный проект». Я всегда в таких случаях тщетно стараюсь отговорить менеджмент от проведения подобных проб. Поэтому, когда и вы будете планировать пилотный проект, действуйте следующим образом:

1. Самое главное — в качестве пилотного выберите проект под руководством человека, который по-настоящему заинтересован во внедрении ССРМ.

2. Письменно изложите, чего вы ждете от пилотного проекта.

3. Составьте устав пилотного проекта.

4. По возможности постарайтесь, чтобы исполнителям не приходилось разрываться на части между вашим пилотным и другими проектами.

5. Перед запуском проекта обучите всю команду.

6. Составляйте расписание по методу ССРМ вместе со всей командой. Заручитесь их согласием с получившимся графиком.

7. Обеспечьте готовность ПО и процедур до запуска проекта.

8. Удостоверьтесь, что в компании как следует работают процессы управления проектами (например, управление изменениями, рисками, решением проблем, коммуникациями).

9. Отслеживайте настроения в команде проекта. Совместно решайте все возникающие проблемы.

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

9.5. Примеры возражений

Ниже приведен список возражений, которые приходится слышать в процессе перестройки компании на работу по ССРМ. Конечно, необязательно в любой организации высказываются именно все эти опасения и в данном объеме. Считайте, что это «горячая десятка» в рейтинге аргументов против ССРМ, которая даст вам представление о том, чего можно ожидать. Когда слышите что-то подобное, не падайте духом. Во всех компаниях, где мне приходилось выслушивать подобные речи, ССРМ в конце концов успешно внедрялась. Я не привожу ответов на данные возражения, поскольку думаю, что вы уже и сами понимаете, как можно ответить. Кроме того, в вашем случае, в вашей компании правильный ответ может отличаться от моего. Лучшая тактика — выслушать, принять к сведению и просто призвать собеседника все же попытаться.

1. Если это так здорово, почему в других компаниях нашей отрасли до сих пор этот метод не внедрен?

2. Мы и так уже используем слишком оптимистичные оценки и постоянно стремимся соблюдать сроки.

3. Нам это не подходит. Наши процессы чрезвычайно сложны, ССРМ тут не сработает.

4. Нам это не подходит. Неопределенность в наших проектах слишком высока.

5. Руководство не станет назначать приоритеты и затем придерживаться их.

6. Буфер потратится уже на самые первые операции проекта.

7. Когда буфер окажется в «красной» зоне, руководство начнет критиковать нас.

8. ССРМ не будет действовать, потому что нам нужно выполнять еще массу работы не по проектам.

9. Если руководство не меняет своих позиций, почему я должен? Думаете, я поверю, что по всем нашим проектам будут показаны четкие и однозначные приоритеты?

10. Традиционно мы ориентируемся на управление по ключевым событиям. Так что ССРМ не для нас.

11. Я очень сомневаюсь, что мы сможем правильно выстроить последовательность работ в системе на основе оценки имеющихся ресурсов.

12. У сотрудников моего отдела разный уровень подготовки. Нельзя будет автоматически заменить одного другим, как нужно по ССРМ.

13. Сомневаюсь, что с меня не будут требовать соблюдения конкретных дат. Как же иначе контролировать?

14. Меня поощряют за многозадачность.

15. У нас это работать не будет. Слишком много препятствий как в операционных процессах, так и в организационной культуре. Мы зря время теряем. Давайте вернемся к настоящей работе.

16. А что не так в нашем управлении проектами? Зачем переделывать то, что работает?

И, наконец, жемчужина моей коллекции:

17. Мы не будем внедрять методики, которые улучшат наши показатели на 50-100%. Иначе получится, что все это время я руководил неправильно!

9.6. Итоги

В данной главе мы рассмотрели в общем виде план внедрения управления проектами по методу критической цепи в организации, ведущей множество одновременных проектов. Поговорили о теоретических основах этого плана. Аналогично можно ввести метод ССРМ и для управления отдельными проектами. План соответствующих преобразований будет более простым. В этой главе обсуждались следующие основные положения:

• Эффективный план преобразований должен учитывать особенности организационной динамики, чтобы изменения произошли быстрее и качественнее.

• Активная поддержка со стороны высшего руководства является решающим фактором для успешного внедрения ССРМ в системное управление одновременными проектами.

• Для внедрения ССРМ используйте проектный подход и соответствующие процессы: создайте устав, заручитесь поддержкой, разработайте и выполните план, закройте проект по правилам управления проектами.

• Тщательно отбирайте пилотные проекты и координируйте их реализацию.

• И людям, и организациям свойственно стремиться к сохранению существующего положения (то есть противиться переменам). План внедрения должен это учитывать и предусматривать соответствующие меры.

• Действуйте!

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

ЛИТЕРАТУРА

1. Kotter, J. “Leading Change: Why Transformation Efforts Fail.” В издании Harvard Business Review on Change, рр. 1-20, Boston, MA: Harvard Business Review Publishing, 1998.

2. Dalziel, Murray M., and Stephen C. Schoonover, Changing Ways, A Practical Tool for Implementing Change within Organizations, New York: Amacom, 1988.

3. Covey, Stephen R., Principle Centered Leadership. Teaching People How to Fish, Provo, UT: The Institute for Principle Centered Leadership, 1990.

4. Bennis, Warren G., Kenneth D. Benne, and Robet Chin, the Planning of Change, New York: Holt, Rinehart and Winston, Ind., 1969.

5. Skinner, B.F., Science and Human Behavior, London: The Free Press, Collier Macmillan, 1953.

6. Culbert, Samuel A., Mind-Set Management, The Heart of Leadership, New York: Oxford University Press, 1996.

Глава 10. Управление рисками в проекте

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

Управление рисками является частью процессов планирования проекта. Ведь необходимо разработать и включить в план меры реагирования на риски. Делая то или иное допущение, вы уже рискуете, потому что считаете, будто предположение ваше окажется верным. Если ваши ожидания не оправдаются, вы столкнетесь с реализовавшимся риском.

По РМВОК [1], к рискам можно относить как негативные (угрозы), так и позитивные незапланированные события. Если вы видите потенциальные возможности, которые по каким-либо причинам не можете реализовать в базовом плане, добавьте их в реестр рисков. Спланировав определенные мероприятия, вы сумеете, может быть, повысить вероятность наступления или позитивные последствия при реализации этих «положительных рисков» и тем самым получить дополнительную выгоду для проекта. Советую вести отдельный реестр «положительных рисков», то есть так называемых благоприятных возможностей. Пожалуйста, не забывайте, что при работе с «положительными рисками» все соответствующие правила применяются в зеркальном виде.

Есть несколько способов реагирования на риски:

1. Принять меры по предотвращению риска (например, снизить потребление горючих материалов во избежание пожара).

2. Определить и отслеживать симптомы для своевременной диагностики наступления риска (например, изучать прогнозы и осуществлять мониторинг фактической погоды).

3. Принять меры по снижению потенциальных последствий наступления риска (например, создать насыпи, защищающие от распространения протечек нефти).

4. Застраховаться от наступления рисков.

5. Разработать мероприятия по борьбе с наступившим риском (например, обратиться в пожарную охрану).

6. Смириться с риском.

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

Описывая управление рисками, ни РМВОК [1], ни смежные с ним издания [2], ни множество авторов других трудов по управлению [3-4] не делают различий между общими и особыми причинами вариабельности. Как мы упоминали в разделе 2.5, Деминг, отец TQM, называл это фатальной ошибкой [5].

10.1. Что такое управление рисками в проекте

У рисков есть две характеристики — вероятность наступления события и его влияние на проект. Весомость риска можно оценить, просто перемножив два этих параметра.

Существуют следующие типы рисков:

• Риск некорректного определения содержания проекта: чреват неудовлетворенностью клиента. Примеры: не ясны потребности клиента; до конца не понятны границы содержания (то есть какие задачи призван решить проект); исходные установки и допущения, сделанные при планировании, не оправдались.

• Бизнес-риски: могут повлиять на ценность проекта для бизнеса в целом. Примеры: финансовые риски, угроза репутации компании.

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

• Риск непредвиденных расходов: под их влиянием приходится тратить больше трети предусмотренного буфера на непредвиденные расходы.

• Риски несоблюдения расписания: под их влиянием на выполнение работ тратится весь буфер на слияние путей или больше трети проектного буфера.

• Риски в сфере охраны труда: превышающая стандартно допустимый уровень потенциальная угроза вреда здоровью и безопасности населения или команды проекта.

• Риски, связанные с негативным воздействием на окружающую среду: некие природные факторы окружения, которые способны повлиять на соблюдение основных условий успешного выполнения проекта (содержание, время, деньги).

• Риски, связанные с законодательной базой в государстве: изменение тех или иных нормативов, задающихся извне, например новые требования к безопасности товара, требование получить новый разрешительный документ либо задержка при обновлении имеющегося разрешительного документа, которые могут повлиять на соблюдение основных условий успешного выполнения проекта.

10.2. Процесс управления рисками

На рис. 10.1 представлена схема процесса управления рисками. Сначала необходимо определить, с какими рисками вы можете столкнуться при выполнении проекта.

Риски можно оценивать как по качеству, так и по количеству. К приемам количественной оценки относятся: анализ характера и последствий отказов, метод Монте-Карло, симуляция проекта, PERT, оценка вероятной безопасности и дерево рисков. Для рисков, которые можно описать численно (например, когда речь идет о затратах или количестве дней в расписании), последствия их наступления можно выразить, умножив «стоимость» риска на вероятность. Например, если вероятность перерасхода бюджета на $100 000 равна 50%, то риск «стоит» $50 000. Такие вычисления могут дать относительное представление о ранге риска, но сама цифра нужна, только если вы собираетесь застраховать риск. Потому что если ничего не произойдет, то вы ничего и не потратите, а если все же произойдет, то потеряете все $100 000, но никак не $50 000.

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

10.2.1. МАТРИЦА РИСКОВ

Табл. 10.1 представляет базовую матрицу, используемую в управлении рисками. В ней приводятся перечень рисков, результат оценки, действия по мониторингу, предотвращению или уменьшению последствий наступления рисков. Наполнение таблицы — это только пример. В ваших проектах могут быть свои особенности и свои риски. Однако настоятельно рекомендую группировать однотипные риски так, чтобы итоговый список был разумных размеров — не более 10-12 пунктов. Более точно количество рисков необходимо прикидывать, исходя из масштабности вашего проекта и условий его реализации. Список рисков по проектам на сумму меньше нескольких миллионов долларов и длительностью до года не должен превышать 10 пунктов. Если вам кажется, что по вашему — относительно небольшому — проекту одних только максимально вероятных и ощутимых рисков намного больше, чем 10, стоит задуматься, а надо ли вообще за такой проект браться.

Во второй колонке табл. 10.1 дано описание рисков. Для начала можно внести в список все ситуации, которые приходят в голову вам и вашим коллегам, а потом сгруппировать их для дальнейшего анализа. Можно расклассифицировать риски по степени их вероятности и по значимости (следующие две колонки). Например, у вас в перечне будет одно связанное с погодными явлениями событие, чреватое большими последствиями, и одно — малыми. Почему их стоит разделить? Потому что для них должны быть предусмотрены разные меры реагирования.

Дэвид Хильсон [6] предложил очень удобный формат записи рисков: «В результате < причина > может наступить < следствие >, что приведет к определенным последствиям». Использование этой формулировки продемонстрировано в табл. 10.1: причины записаны жирным шрифтом, их следствия — курсивом, а финальные последствия — в стандартном виде.

В колонках 3, 4, 5 даны относительные количественные характеристики рисков. Риск интересен нам своей вероятностью и последствиями. Внизу таблицы толкуются принятые обозначения и также указан один из вариантов категоризации рисков по вероятности и по последствиям для проекта. При таком методе оценки вы сможете назначить риску ранг от 1 до 9. Обратите внимание: под вероятностью подразумевается вероятность наступления риска в ходе проекта. Максимальная степень вероятности здесь — 50%. Если вы уверены в неизбежности события больше, чем на 50%, его необходимо учесть при составлении плана проекта. То есть все риски с вероятностью больше 50% должны рассматриваться как исходные допущения уже при создании базового плана работ. Последствия таких рисков будут компенсироваться за счет проектного буфера и, при необходимости, буфера на непредвиденные расходы.

В вашей таблице могут оказаться и другие типы рисков, например связанные с охраной труда и безопасностью или с реакцией общественности. Дополнительная информация по качественному и количественному анализу рисков дана в разделе 10.3.

В шестой колонке перечислены параметры, подлежащие постоянному мониторингу. Необходимо регулярно производить оценку ситуации: может, пора пересмотреть рейтинг рисков или активировать запасной план действий на случай непредвиденных ситуаций. Конечно, следует по мере возможности установить заранее, что именно должно послужить для вас тревожным симптомом.

Колонки 7 и 8 — самые важные. Это перечень действий по предотвращению или снижению последствий наступления рисков. Действия могут влиять как на вероятность, так и на последствия. Например, система по предотвращению распространения утечки нефти сокращает уровень последствий, а не вероятность утечки. А цистерна с двойными стенками — мера по снижению вероятности утечки. Действия по предотвращению риска должны войти в план управления вашим проектом. Также может понадобиться спланировать и действия по снижению, например тренинги или срочную закупку комплектующих у другого поставщика.

10.2.2. ОЦЕНКА РИСКОВ

КАК ЧАСТЬ ПРОЦЕССОВ УПРАВЛЕНИЯ ПРОЕКТОМ

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

• предотвращение или снижение вероятности наступления риска (например, разделить проект на фазы или тщательнее проанализировать неясные моменты, чтобы повысить точность оценок и прогнозов);

• передача риска (например, можно отдать часть работ субподрядчикам);

• отслеживание ситуации для выявления роста вероятности наступления риска (например, определить симптомы нежелательного события и контролировать их появление);

• предотвращение последствий риска, если он все-таки наступит;

• страхование рисков;

• снижение последствий риска, если он все-таки наступит.

Можно использовать различные комбинации этих действий — например, в соответствии с табл. 10.2.

10.3. Идентификация рисков

10.3.1. РЕЕСТР РИСКОВ

Существуют разные способы идентификации рисков. Один способ — рассмотреть все допущения и исходные установки, на основании которых вы оценивали длительность или стоимость работ. Потенциально любое из этих допущений может не оправдаться — это риск. Можно воспользоваться проверочными списками. Пример такого списка найдете в приложении А труда Макса Вайдмана [2]. Кто-то прибегает к помощи специальных компьютерных программ [7]. Еще способ, которым обычно я пользуюсь, — просто собраться всей командой проекта и составить перечень рисков

Таблица 10.2. Рекомендации по работе с рисками

методом мозгового штурма. Можно вспомнить, какие проблемы возникали на подобных проектах ранее. Обычно с созданием списка рисков проблем не возникает. Однако никто не умеет заглядывать в будущее, поэтому реестр рисков никогда не будет полным. Фантазировать можно бесконечно, большого смысла в этом нет. Вам нужен список типов рисков, которые наиболее вероятны именно для вашего проекта.

10.3.1.1. Допущения проекта

Многие из сделанных вами допущений могут превратиться в риски, если в жизни все окажется не так, как вы предполагали. Например, вы исходили из установки, что инспекторская проверка займет, вероятнее всего, 60 дней, или 30 дней, если брать среднюю продолжительность. Если же на деле она длится больше, чем две трети проектного буфера, налицо риск, угрожающий успеху проекта. Исходя из этого опыта, при выполнении другого проекта с вовлечением того же инспектирующего органа вы будете уже готовы к тому, что инспекция может затянуться.

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

10.3.1.2. Проверочные списки

Проверочные списки помогают установить, не пропустили ли вы чего-то важного. Однако у них есть два недостатка:

1) в разработанных заранее проверочных списках могут содержаться вроде бы весомые и значимые риски, которые на самом деле не существенны для вашего проекта;

2) ориентация на проверочные списки вселяет ложное чувство уверенности в том, что вы все учли и предусмотрели, ограничивает ваше мышление.

И снова — полагайтесь на здравый смысл.

10.3.1.3. Критическое осмысление плана

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

10.3.1.4. Группирование рисков

Если список получается слишком длинным, следует сначала объединить похожие пункты и лишь затем приступать к выработке мер реагирования. Ваша задача — получить управляемое количество вероятных рисков. С увеличением детализации списка точность ваших прогнозов выше не станет. Ведь, по сути, число потенциальных рисков бесконечно. Вам никогда не перечислить их все. Гораздо более важно учесть самые существенные из угроз и установить систему мониторинга и реагирования на наступившие события. Невозможно сконцентрироваться, когда деталей слишком много, как невозможно и спланировать адекватные меры реагирования на все. Необходимо сократить список хотя бы до пары десятков наименований. А когда проект не из самых больших (то есть с бюджетом менее $10 млн и длительностью 1-2 года), список должен состоять не более чем из 10 пунктов. Иначе такой проект лучше, пожалуй, и не начинать.

10.3.2. КЛАССИФИКАЦИЯ РИСКОВ ПО ВЕРОЯТНОСТИ

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

Питер Бернштайн [8] отмечает: «Суть управления рисками заключается в том, чтобы расширить подконтрольные нам области и сузить зоны, логика событий в которых нам не известна и не поддается нашему влиянию». Далее он говорит, что страховка доступна лишь там, где действует закон больших чисел (смотрите четвертый пункт в перечне ниже). То есть там, где теория вероятностей работает на страховщика. В таком случае из самого определения риска следует, что мы имеем дело с маловероятным событием.

Наши способности в оценке вероятностей не выдерживают никакой критики [9-11]. Прикидывая вероятность события, люди чаще всего попадают в сети логических предубеждений и ошибок. Как показывают исследования, в то же время мы, к сожалению, придерживаемся неоправданно высокого мнения о собственных знаниях и способностях. Приведу список наиболее распространенных заблуждений и ошибок, чтобы вы могли отдавать себе в них отчет. Как преодолеть их — тема для отдельного разговора.

• Неспособность понять правила сочетания вероятностей. Вероятность наступления двух независимых событий вытекает из вероятностей наступления каждого из событий. Поскольку эти величины всегда меньше единицы, то совокупная вероятность наступления двух событий будет неизменно меньше, чем вероятность каждого из них в отдельности.

• Игнорирование базовой вероятности. Имеется в виду неумение учитывать распределение выборки. Представим себе, что из коробки с бусами, в которой 90% бусин белые, мы вытащили одну бусину. Вероятность того, что в сумеречном освещении мы правильно угадаем цвет бусины, равняется 50%. Тот, кто тащил бусину, говорит: «Она черная». Какова вероятность того, что она действительно черная? Практически все отвечают — 50%. Правильный ответ — всего 5%.

• Имеющийся опыт. Зачастую мы предвзято оцениваем вероятность события, исходя из недавнего опыта или общераспространенного мнения.

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

• Подмена основания. Люди принимают «наиболее типичное» за «наиболее вероятное». Например, описание человека содержит характеристики, которые вызывают у людей ассоциации со школьным учителем. Людям предлагается выбрать один вариант в ответ на вопрос «Кто бы это мог быть вероятнее всего — школьная учительница? Сотрудница учреждения?». В ответ получаем, что, скорее всего, это учительница. Однако школьные учительницы тоже попадают в разряд «сотрудниц учреждения». Поэтому гораздо более вероятно, что описана «сотрудница учреждения», чем конкретно учительница.

• Фиксация. Люди склонны придерживаться однажды высказанной позиции (собственной или чьей-то чужой), особенно когда речь заходит о цифрах. Поэтому так сильно влияние общественного мнения. Если вам нужна независимая оценка, не просите, чтобы человек посмотрел и оценил чужой результат, потому что тогда он сконцентрируется только на этом чужом результате, зафиксируется на нем.

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

Опираясь на эти пункты, вы можете критически оценить получившийся у вас список рисков и их ранжирование по вероятности и воздействию.

Спросите себя, не допустили ли вы какой-либо из перечисленных ошибок.

10.3.2.1. Высокая вероятность (3)

В реестр рисков не должны попасть события с вероятностью выше 50%.

Конечно, такие риски тоже необходимо учитывать — но в качестве допущений при создании базового плана проекта. Высокая вероятность — это вероятность между 50% и умеренной вероятностью (5-15%).

10.3.2.2. Средняя вероятность (2)

В упрощенном виде средней называется вероятность, которая меньше, чем высокая, но больше, чем низкая. Это события, которые на самом деле могут произойти, хотя об заклад вы за это биться и не стали бы (вернее, стали бы, только если ставки по-настоящему привлекательные).

10.3.2.3. Низкая вероятность

Маловероятные риски — это такие события, которые, скорее всего, за время реализации вашего проекта не случатся. Вероятность их наступления меньше 5%. Сюда, естественно, входят и ситуации, вероятность которых практически нулевая (1% и ниже). Маловероятные риски должны при необходимости учитываться в дизайне результата проекта (например, продукт должен быть устойчив к землетрясениям и неблагоприятным погодным условиям). Однако это не имеет отношения к оценке рисков самого проекта. Исключением может быть страхование от природных стихий (ураганов, наводнений) результатов строительных проектов.

10.3.3. КЛАССИФИКАЦИЯ РИСКОВ ПО ПОСЛЕДСТВИЯМ

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

10.3.3.1. Высокое воздействие (3)

Высокое воздействие риска на проект подразумевает такие последствия, как превышение проектного буфера или буфера на непредвиденные расходы, а также низкая степень удовлетворенности клиента или команды проекта результатом его выполнения.

10.3.3.2. Среднее воздействие (2)

Среднее воздействие оказывает такой риск, последствия которого вызовут утрату от одной до двух третей проектного буфера или от одной трети до полной величины буферов на слияние путей.

10.3.3.3. Низкое воздействие (1)

Последствия таких рисков приведут к уменьшению буферов не более чем на одну треть и не станут причиной недовольства клиента или команды.

10.4. Планирование управления рисками

10.4.1. МОНИТОРИНГ РИСКОВ

Необходимо спланировать мероприятия по отслеживанию статуса тех рисков, которые вы оставили в реестре рисков вашего проекта. Это означает, что необходимо как минимум регулярно анализировать список на проектных совещаниях (то есть раз в неделю или в месяц). Следует проверять, не наблюдается ли повторного проявления симптомов уже имевших место рисков или не ожидается ли наступление нового риска. Иногда нужно устанавливать более формальный процесс мониторинга ситуации с рисками.

10.4.2. ПРЕВЕНТИВНЫЕ МЕРЫ

Выработанные вами меры по предотвращению наступления рисков включаются в план проекта. Затем в рамках процесса оценки и контроля выполнения проекта следует проверять, выполняются ли эти меры.

10.4.3. МЕРЫ РЕАГИРОВАНИЯ

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

10.5. Итоги

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

• ССРМ упрощает процесс управления рисками, так как устраняет необходимость — в рамках этого процесса — бороться с общими причинами вариабельности. Управление рисками в ССРМ нацелено только на особые причины вариабельности.

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

• Необходимо определить перечень рисков, оценить их вероятность и воздействие на проект.

• Проектный буфер в плане проекта, созданном методом ССРМ, помогает оценить степень влияния риска на весь проект.

Команда проекта определяет стратегию реагирования на риски, как то предотвращение, снижение, страхование, отслеживание, игнорирование.

ЛИТЕРАТУРА

1. PMI, A Guide to the Project Management Body of Knowledge, Newton Square, PA: PMI, 2000 (в русском переводе: Руководство к своду знаний по управлению проектами/Под. ред. В. Либерзона, Д. Лобанова. — Институт управления проектами, 2004. — редакция 2000 года; Руководство к своду знаний по управлению проектами. — Project Management Institute, 2004. — редакция 2004 года).

2. Wideman, R. Max, Project and Program Risk Management, A Guide to Managing Project Risk and Opportunities, Newtown Square, PA: PMI, 1992.

3. Meredith, Jack R. and Samuel J. Mantel, Project Management, A Managerial Approach, New York: John Wiley and Sons, 1985, с. 68-71.

4. Wysocki, Robert K., Robert Beck Jr., and Daid B.Crane, Effective Project Management, New York: John Wiley & Sons, 1995.

5. Deming, W. Edwards, The New Economics, Cambridge, MA: MIT Press, 1993 (в русском переводе: Деминг У. Эдвардс. Новая экономика. — М.: Эксмо, 2006).

6. Hilson, David. “When Is a Risk Not a Risk: Part 2,” на сайте http://www.risk-doctor. com/pdf-briefings/risk-doctor07e.pdf (материал для книги взят с сайта 22 июня 2004 года).

7. Risk Trak, Risk Services & Technology, Amherst, NH, 03031.

8. Bernstein, Peter L., Against the Gods, The Remarkable Story of Risk, New York: John Wiley and Sons, 1996.

9. Kahneman, Daniel, Paul Slovic, and Amos Tversky, Judgment under Uncertainty: Heuristics and Biases, Cambridge: Cambridge University Press, 1982.

10. Belsky, Gary, and Thomas Gilovich, Why Smart People Make Big Money Mistakes, and How to Correct Them, New York: Simon & Schuster, 1999.

11. Russo, J. Edward, and Paul J.H. Schoemaker, Decision Traps, The Ten Barriers to Brilliant Decision Making, and How to Overcome Them, New York: Simon & Schuster, 1989.

Глава 11. Логические инструменты ТОС в управлении проектами

Эта глава подводит итог всему сказанному ранее. Я опишу, каким образом убедился в необходимости использовать метод критической цепи в управлении проектом. Также перечислю ряд идей, над которыми еще стоит подумать. Деминг видел одно из препятствий успешным преобразованиям в склонности менеджеров ориентироваться на примеры. Он говорил: «На просьбы привести пример аналогичной ситуации я всегда отвечаю, что никакие примеры успешных или неудачных попыток повышения качества и производительности не покажут, чего стоит ожидать именно в вашем случае» [1]. Далее Деминг пишет: «Вопрос не в том, успешно ли предприятие, а в том, почему оно именно такое, какое есть. И почему оно не добилось более значимых результатов? Необходимо в теории представлять, чего мы хотим достичь». Вы уже познакомились с принципами ССРМ вкупе с некоторыми сопутствующими положениями теории ограничения систем, TQM, шести сигм, бережливого производства, гибких методологий Agile и РМВОК. Описываемый в данной главе процесс логических рассуждений ТОС, разработанный Голдраттом, — это инструмент для наглядной передачи хода мыслей, изложенных ранее.

11.1. Синтез принципов

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

Рис. 11.2 демонстрирует соотношение ССРМ и ключевых управленческих концепций, описанных в главе 2. Верхние строки еще раз показывают, что ССРМ — это комбинация традиционного управления проектами и концепции критической цепи ТОС. Ключевые принципы бережливого производства взяты у авторов Дж. Вумек и Д. Джонс [2]; шести сигм — у П. Панде, Р. Ньюмена и Р. Каванаг [3]; принципы TQM — это пункты теории глубинных знаний Деминга, а теория ограничений представлена пятью направляющими шагами. (Другие инструменты ТОС, о которых пойдет далее речь, отражены на рис. 11.1.) Цель рис. 11.2 — передать, насколько многогранен результат синтеза перечисленных концепций. Конечно, существуют взаимосвязи и между пунктами, перечисленными в столбце (и, соответственно, между теми, которые приведены в верхней строке матрицы тоже). Если вдруг между ними возникает конфликт, можете устранить его при помощи инструментов ТОС, описанных далее.

Разработанный PMI стандарт ОРМ3 [4] является продолжением РМВОК в приложении к программам и портфелям проектов. До сих пор мы с вами не говорили об этом уровне управления проектами, однако и к нему можно применить метод ССРМ. Можно использовать описанные далее инструменты или просто подумать, а как бы изменился состав портфеля проектов, если при выборе руководствоваться правилами ТОС. Дискуссия в интернет-сообществе ТОС (ТОС Internet group) продемонстрировала, что некоторые простые приемы могут быть использованы и на этом уровне управления, однако в детали никто пока не вдавался и эффективной методики не сформулировал. В заключение прозвучала рекомендация учитывать влияние неопределенности применительно к любому проекту (причем неопределенность в окупаемости проекта чаще всего намного выше неопределенности содержания, сроков и стоимости), а также заранее просчитывать различные варианты развития событий и их влияние на производительность по денежному потоку и операционные расходы компании. Участники дискуссии справедливо подчеркивают, что выбор проектов для портфеля осуществляется на основании ранее принятых решений (то есть уже идущих проектов) и что все новые инициативы должны оцениваться с учетом этих уже запущенных проектов или, если хотите, вместе с ними.

11.2. Используем логические рассуждения по ТОС в управлении проектом

Процесс логических рассуждений, освещенный в главе 2, был предложен Голдраттом как средство нахождения инновационных системных решений. Все начинается с описания текущей ситуации, а в финале мы получаем план действий по созданию желаемой — будущей реальности. Это чистой воды логика, успех применения которой зависит от двух составляющих: критического анализа полученных построений и поддержки со стороны тех, кому вы будете демонстрировать свои выкладки.

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

Мне посчастливилось еще в августе 1994 года познакомиться с ранней версией процесса логических рассуждений ТОС в приложении к управлению проектами. Этот вариант использования инструментов ТОС был разработан Ди Джейкобом совместно с Голдраттом и другими специалистами института Голдратта AGI. В сущности, он уже обладал всеми признаками, присущими методу критической цепи в управлении отдельными проектами, и показался мне заслуживающим особого внимания. Изменения, произошедшие с 1994 года, по большей части касаются способов представления результатов и не затронули самой сути построения системы управления отдельными проектами.

В исходном виде управление проектами по ТОС не распространялось на системы одновременных проектов. В появившейся в 1997 году книге Голдратта «Критическая цепь» (Critical Chain) [5] проблеме конфликта ресурсов на подобных проектах посвящена всего пара страниц. На мой взгляд, важность системного подхода к управлению одновременными проектами открыл Тони Риццо из компании Lucent Technologies, однако пока у него не вышло никаких публикаций на сей счет. В этом отношении тон процессу достижения результата задавал сам результат, то есть сначала появилось решение для системы проектов и потом лишь были построены деревья текущей и будущей реальности (ДТР и ДБР), подводящие к этому решению.

К сожалению, находится не так уж много желающих досконально следовать правилам построения и критического анализа логических диаграмм ТОС. Данные, приводимые Эриком Норином, Деброй Смит и Джеймсом Маккеем [6], показывают, что информация, даваемая на так называемых курсах Ионы, очень мало используется в дальнейшем. (Иона — герой первой книги Голдратта [7], в честь которого в AGI назвали тренинг по процессу логических рассуждений ТОС.) Мои собственные (ненаучные) исследования в этой сфере, а также обсуждения в интернет-сообществе ТОС свидетельствуют о том, что ситуация не очень-то изменилась за последние несколько лет. То есть мало кто на практике использует знания, получаемые на курсах Ионы, и еще меньше тех, кто с помощью этой методики находит революционные решения своих проблем. Есть основания полагать, что индуктивным путем ТОС никогда не прийти к по-настоящему творческому решению вопроса [8, 9]. Думаю, Карл Поппер и Е. Де Боно согласились бы, что у таких людей, как Голдратт, гипотезы рождаются сами, а потом уже проходят проверку процессом рассуждений ТОС. Многие пользуются данной методикой, чтобы подвести логическое обоснование под решения, предлагаемые ТОС, например, для производственных систем или в управлении проектами. Логические деревья дают лучшее представление о системе и помогают совершенствовать ее. Однако они же могут и сдерживать дальнейшие улучшения, поскольку определенным образом ограничивают круг видимых проблем.

Понимая принцип работы метода критической цепи, вы сможете определить, соответствует ли ваша система тем предположениям о текущей реальности, на которых основан ССРМ. Если расхождения значительны, вам придется изменить модель желаемой действительности и те прорывные методы, которые позволят воплотить ее в жизнь.

Диаграммы, полученные в результате процесса логических рассуждений ТОС, весьма объемны и не могут быть полностью включены в книгу. Полную версию смотрите на сайте компании Advanced Projects по адресу: http://www.advanced-projects.com.

11.3. Дерево текущей реальности

Дерево текущей реальности ДТР описывает систему в том виде, в каком она существует сейчас. Такое представление необходимо, чтобы найти ключевой конфликт. Ключевой конфликт — это истинная причина множества нежелательных явлений (НЯ). Создание ДТР начинается с выявления НЯ — то есть тех явлений, которые беспокоят вас на данный момент. Например: «Меня по-настоящему беспокоит, что проекты идут с нарушением сроков». Нежелательные явления в управлении проектами перечислены в главе 3.

Затем выбираются три НЯ и формулируется ключевой конфликт. Сначала конфликт выявляется по каждому из трех НЯ, затем все три конфликта комбинируются и из них выводится один, обусловивший их появление, — ключевой. Диаграмма разрешения конфликтов «грозовая туча» для проблем управления проектами также представлена в главе 3. ДТР устанавливает причину появления ключевого конфликта, ведущего к большинству (если не ко всем) НЯ. Этот конфликт, играющий важную роль в системе, и будет той оптимальной точкой, к которой следует приложить усилия, чтобы добиться перемен.

На рис. 11.3 показано ДТР по текущему состоянию управления проектами. В нем нашел отражение и ключевой конфликт, расписанный в главе 3

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

Аналогичным образом читается правая цепочка, которая подводит нас к блоку 9: «Возникает насущная необходимость закладывать в оценочные значения операций запас на непредвиденные обстоятельства. Это противоречит необходимости уменьшать оценочные значения операций. Так при планировании проекта возникает конфликт».

Заметьте, что я опустил слова «все больше и больше», которые включены в схему. Они обретают смысл, если вы повторно несколько раз обсуждаете диаграмму в вашей организации. Также обратите внимание, что некоторые НЯ, являющиеся следствием на верхних уровнях диаграммы, служат в то же время причиной НЯ нижних уровней, и наоборот.

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

Дерево текущей реальности, посвященное управлению проектами в целом, не может отразить всех особенностей вашей ситуации. Мне приходилось консультировать компании как с очень развитой, так и с весьма упрощенной системами проджект-менеджмента. Как это ни странно, организациям с минимальным управлением проектами проще перестроиться на работу по методу ССРМ. Некоторые утверждают, что в этих случаях успех вызван не самим ССРМ, а просто тем, что вообще вводится некая упорядоченная система ведения дел. Я с этим не согласен, потому что в компаниях, где принято решать много задач одновременно, традиционный подход к управлению проектом только усугубил бы ситуацию. Не так уж редко доводится встречать людей, считающих планом проекта диаграмму Гантта, в которой нет никакой логики между операциями и указана лишь дата окончания работ, и то заданная кем-то извне. За несколько месяцев таких менеджеров спокойно можно научить строить эффективные планы по методу критической цепи, управлять при помощи буферов и вести проекты все успешнее и успешнее.

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

13 не были согласны с необходимостью соответствующих преобразований. Как вы думаете, кого из вице-президентов сместили через три месяца после запуска проекта? Полагаю, вы догадываетесь, какой был результат.

11.3.1. ПОЛИТИКИ, ОЦЕНКИ, МОДЕЛИ ПОВЕДЕНИЯ

Как правило, весьма полезным бывает проанализировать, каким образом имеющиеся в компании политики и система оценок влияют на стиль работы и как, в свою очередь, стиль работы сказывается на текущей реальности. В таких системах, как управление проектом, политики и системы оценки часто оказываются ограничением. Возьмем, к примеру, блок 4 в нашем ДТР: «В большинстве компаний работа исполнителей (в том числе субподрядчиков) оценивается по тому, достигнуты ли все ожидаемые результаты за плановый срок и в рамках планового бюджета». Это может проявляться в установившемся процессе регулярной аттестации сотрудников. Нередко принятые в компании оценки эффективности труда и соответствующие политики вынуждают работать по модели «многозадачность». В явном виде мы этот фактор в нашем ДТР не отразили. В каждой компании он может проявляться по-разному, поэтому трудно поместить его в диаграмму общего вида. Необходимо продумать, подкрепляются ли явления, отраженные в общем ДТР, принятыми в вашей организации политиками и процедурами.

11.3.2. ЦИКЛЫ ОБРАТНОЙ СВЯЗИ

ДТР в полном виде, как правило, содержит также особые структуры — замкнутые циклы, элементы которых поддерживают и усиливают друг друга. Пример — на рис. 11.3, где блоки 1, 2, 3 «питают» блок 9, а тот,

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

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

11.3.3. КРИТИЧЕСКИЙ АНАЛИЗ

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

Критический анализ результатов процесса логических рассуждений проводится следующим образом. Каждая диаграмма исследуется по Критериям проверки логических построений (КПЛП). Я впервые услышал об этой методике от членов AGI, однако подозреваю, что и они, в свою очередь, заимствовали ее логику у кого-то еще. К сожалению, ни Голдратт, ни кто-либо из AGI не раскрывают источников своих материалов. КПЛП описаны у Детмера [10] и других авторов, однако ссылки при этом даются только на AGI.

Критерии проверки логических построений:

• Ясность: все ли понимают значения используемых в диаграмме слов?

• Наличие утверждения: можно ли доказать или опровергнуть справедливость высказанной мысли?

• Наличие причинно-следственных отношений: можно ли доказать правильность указанной причины? (Обычно доказательством служит тот факт, что данное следствие всегда проявляется, если есть указанная причина, и никогда не обнаруживается, когда этой причины нет.)

• Достаточность приведенной причины: помимо указанной причины, не требуются ли еще другие условия, чтобы проявилось данное следствие?

• Проверка наличия альтернативной причины: может ли данное следствие проявляться без указанной причины или под действием каких-то других причин? (Принцип «достаточной приемлемости» в ТОС говорит, что необходимо останавливаться лишь на тех причинах, которые приводят к данному следствию хотя бы в трети случаев.)

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

• Проверочное следствие. Если бы в реальности действовала указанная причина, были бы у нее, помимо основного, какие-то другие следствия и наблюдаются ли эти следствия на самом деле?

• Тавтология: знаменитое «Этого не может быть, потому что этого не может быть никогда». Или еще пример:

Джо: «Если каждый день дудеть в трубу, у меня в гостиной слонов не будет».

Дэн: «Почему ты так считаешь?»

Джо: «Ну разве ты видишь в моей гостиной хоть одного слона?»

Обнаружить подобного рода ошибки бывает нелегко. Не все же обращаются за помощью к психологам.

Иона советует анализировать по данным критериям все логические деревья ТОС. Если вы считаете, что вашим собеседникам будет сложно понять диаграммы, попытайтесь вместе с ними критически проанализировать каждый элемент и все связи в логической схеме. Для многих это, конечно, будет тяжким испытанием. Однако других вариантов, к сожалению, нет.

11.3.4. ПОДДЕРЖКА УЧАСТНИКОВ

Вам следует заручиться поддержкой со стороны тех, кому предстоит пользоваться результатами ваших логических построений. То есть, в зависимости от их положения в системе и уровня воздействия на нее, люди должны подтвердить, что готовы осуществлять или поддерживать преобразования системы. К сожалению, логика не всегда оказывается сильнее укоренившихся глубинных верований и убеждений. Как мы говорили в разделе 9.2.5, если не изменить глубинные убеждения людей, то не удастся добиться устойчивых перемен в их поведении. Возможно, на какое-то время что-то и изменится, однако затем система вновь вернется в свое первоначальное состояние.

Получив поддержку со стороны представителей системы, вы обеспечите себе возможность решительно действовать для достижения смоделированного вами идеального состояния системы. Конечно, сразу добиться коренных перемен в убеждениях людей не удастся. Однако, если в идеальной модели вашей системы вы предусмотрели позитивные замкнутые циклы (обратную связь), которые станут поддерживать интересы наиболее влиятельных участников событий, преобразования будут подкрепляться за счет этих циклов. Для этих целей можно продемонстрировать кому-то из руководства всю цепочку ваших логических рассуждений и соответствующие построения. Однако, как показывает опыт, не у каждого топ-менеджера хватает терпения выслушать полный рассказ. Поэтому придется использовать особые методы, презентации и переговоры, чтобы достучаться до нужных людей.

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

Один из действенных методов привлечения руководства на свою сторону заключается в следующем. Вы отбираете те нежелательные явления, которые находятся на особом контроле интересующих вас людей, и основные из них включаете в свое дерево текущей реальности. Получая объяснения причин появления этих НЯ в системе, руководство соглашается не только с логикой ДТР, но и с теми решениям, которые вы предлагаете для преобразования системы.

11.4. Дерево будущей реальности

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

11.4.1. ЖЕЛАЕМЫЙ РЕЗУЛЬТАТ

Создание ДБР начинается с того, что все нежелательные явления мы переформулируем в желаемые результаты (ЖР). На рис. 11.4 приведены ЖР, характерные для эффективной системы управления проектами. Также показано, где в схеме находится прорыв — революционное изменение в системе.

11.4.2. ПРОРЫВНЫЕ РЕШЕНИЯ

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

Вот перечень прорывов для внедрения ССРМ:

• Снизить оценочную длительность операций на 50%. Руководители проектов составляют сетевую диаграмму проекта без закладывания резерва по ресурсам или времени. При этом учитывается максимально вероятная длительность операций. Мы же используем оценку с вероятностью 50%, то есть вдвое уменьшаем оценочную длительность работ.

• Устранить конфликт ресурсов и определить критическую цепь. Менеджер проекта снимает конфликты между операциями проекта за имеющиеся в системе ресурсы и находит критическую цепь как самую длинную последовательность связанных друг с другом работ. Это первый направляющий шаг.

• Рассчитать и добавить проектный буфер как защиту от непредвиденных обстоятельств для всей критической цепи (исходно равен половине длины цепи). Это один из шагов по максимальному использованию возможностей ограничения.

• Использовать списки работ с указанием приоритетов, а также «оповещающие флаги», чтобы исполнители работали над тем, что важнее всего в данный момент.

• Рассчитать и добавить буферы на слияние путей (ко всем цепочкам работ, впадающим в критическую цепь). Они служат для защиты критической цепи от негативной вариабельности, накапливающейся на всех предшествующих ей цепочках работ. Так происходит подчинение всех операций нуждам ограничения.

• Планировать начало операций по правилу «как можно позднее», соблюдение сроков защищается буфером. Это тоже подчинение операций нуждам ограничения, ведь в данном случае, как правило, в первую очередь запускается критическая цепь и не более одной-двух других цепочек работ.

• Работать в стиле «эстафеты». Не допускать многозадачности и проявления студенческого синдрома. Исполнитель принимается за операцию при первой же возможности, выполняет ее максимально быстро и сразу же передает готовый результат на следующий этап. Так мы начинаем устранять ограничение.

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

• Использовать для контроля прохождения плана отчеты о состоянии буферов. По величине проектного буфера и буферов на слияние путей менеджер проекта ориентируется, когда необходимо подготовить план по пополнению буферов, а когда — реализовать его. Это первая система превентивных оценок, когда-либо использовавшаяся в управлении проектами! И она также служит для устранения ограничения.

На рис. 11.5 показаны прорывные события в том порядке, в каком они появляются в ДБР.

11.4.3. ДБР КАК РУКОВОДСТВО

ПО ПРОВЕДЕНИЮ ПРЕОБРАЗОВАНИЙ

Дерево будущей реальности становится настоящим руководством по проведению преобразований. По мере реализации прорывных решений вы сверяетесь с ДБР и смотрите, начинают ли на деле проявляться означенные там желаемые результаты (ЖР). Основываясь на ДБР, можно также выяснить, не будет ли у предлагаемых изменений каких-либо неожиданных последствий. Помните, если в реальности перемены происходят быстрее запланированного или оказываются масштабнее, чем ожидалось, необходимо пересмотреть ДБР. Вероятно, вы пропустили какую-то причинноследственную связь.

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

В основе ДБР лежат перечисленные ранее прорывные события. Каждое из них сопровождается объяснением, почему именно оно видится нам необходимым и как оно может помочь.

11.4.4. ЦИКЛЫ ОБРАТНОЙ СВЯЗИ

ДБР включает в себя циклы обратной связи, которые поддерживают движение системы в заданном направлении, а по достижении цели фиксируют ее в стабильном состоянии. В ДБР по управлению проектом таких циклов несколько, какие-то начинают работать быстро, а какие-то — с некоторой задержкой. Первые способствуют закреплению перемен, а вторые — стабилизации системы в новом положении.

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

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

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

11.4.5. НЕЖЕЛАТЕЛЬНЫЕ ПОСЛЕДСТВИЯ И НЕГАТИВНЫЕ ВЕТВИ

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

Разница между препятствиями и НВ в том, что первые — помеха на пути к цели. А НВ появляются, когда вы, в общем-то, успешно выполнили запланированные действия. Просто оказалось, что прорывное событие, которого вы добивались, в сочетании с другими факторами текущей или будущей реальности привело также и к негативным последствиям.

Основной способ обнаружить НВ — попросить кого-то проанализировать ваше ДБР. У тех, кто смотрит диаграмму, должен быть достаточный опыт и интуиция, чтобы разглядеть, как запланированные вами преобразования, взаимодействуя с какими-то известными им явлениями, могут привести к нежелательным результатам.

На рис. 11.6 представлена НВ для ССРМ, отражающая распространенное опасение, что явное отображение запаса времени в плане неизбежно побуждает руководство и клиентов этот запас урезать. В литературе по традиционному управлению проектами в данном случае советуется планировать запасное время в скрытой форме. Однако это трудно назвать профессиональным подходом к делу!

Первым делом вы рисуете диаграмму, в которой прорыв связывается с неким НЯ. НВ основана на логике достаточности, как ДТР и ДБР, и читается при помощи формулировок «если... то». Думаю, вы уже поняли, как следует читать логические диаграммы. Построение необходимо проанализировать по КПЛП.

Построив НВ, мы должны подумать, как предотвратить появление нежелательного эффекта. Для этого мы тщательно изучаем диаграмму и выявляем ту точку, в которой ход событий меняет свой оттенок на негативный. В нашем случае этой поворотной точкой оказывается блок 602 — «Клиенты хотят сократить длительность проекта и урезать буфер». Затем мы выявляем исходные установки, легшие в основу появления стрелок, ведущих к этому блоку. На нашем рисунке таких стрелок две. Обратите внимание, эти стрелки исходят из элементов 600 и 601, которые связаны строгим логическим «и» (это передается символом «эллипс», или, как его еще называют практики ТОС, «банан»). Поэтому мы избавимся от блока 602, если сумеем устранить хотя бы один из ведущих к нему блоков, потому что для появления события 602 должны одновременно соблюдаться условия 600 и 601. Вот что значит «строгое и».

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

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

Порядок действий при создании НВ следующий:

1. Определите потенциальное НЯ, появления которого вы опасаетесь.

2. Определите, какое из планируемых вами мероприятий-прорывов вызывает это НЯ.

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

4. Проанализируйте логику связей НВ, зачитав построение вслух и заручившись таким образом согласием ваших слушателей с изложенной логикой.

5. Найдите точку, в которой цепь событий приобретает негативный характер.

6. Раскройте установки, лежащие в основе стрелки, связывающей первый отрицательно окрашенный блок с предыдущим.

7. Выработайте прорывные решения, которые нейтрализуют эти установки и предотвратят возникновение НЯ.

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

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

11.5. Дерево перехода

ДП — это последовательность событий, которые должны произойти, чтобы реализовалась идеальная модель системы из ДБР. Мы анализируем каждое прорывное решение из ДБР и проверяем, какие же препятствия нам предстоит преодолеть на пути к воплощению каждого решения. Затем прописываем все промежуточные цели по преодолению выявленных препятствий и соединяем их во временную последовательность с прорывными решениями. На рис. 11.7 представлено ДП первого прорыва для ССРМ. Препятствия показаны в шестиугольниках.

Чтобы получить схему перехода к новой реальности, необходимо дополнить ДП всеми решениями, которые вы разработали. А чтобы показать, как добиться реализации каждого решения, строим для них и для промежуточных целей из ДП диаграмму «план преобразований» (ППР).

ДП можно использовать самостоятельно в качестве инструмента планирования и достижения ваших амбициозных целей. Пример подобного

Дерево перехода, сетевой график проекта и иерархическая структура работ

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

использования описан у Голдратта в романе «Дело не в везенье» [11]. Это очень сильный механизм, который можно использовать при запуске проекта для идентификации возможных препятствий и планирования действий по их преодолению.

11.6. План преобразований

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

Рис. 11.8 — пример ППР для одного из прорывных решений по улучшению системы управления проектами. В данном ППР приводится план достижения промежуточной цели 1-1 из ДП на рис. 11.7. Одновременно можно строить ППР лишь для двух нижних уровней ДП. Описав, как добиться промежуточной цели одного уровня, необходимо строить отдельный ППР для целей следующего уровня ДП.

План преобразований читается снизу вверх, так же как и деревья текущей и будущей реальности. То есть используем формулировки «если... то». В ППР дается описание логики каждого действия и объясняется, почему мы ожидаем, что оно приведет к желаемому результату. Практика показывает, что это очень эффективный инструмент для разъяснения порядка действий, для инструктирования. Таким образом, ППР можно использовать и как отдельный метод описания процедур.

11.7. Системное управление несколькими проектами

11.7.1. ДОПОЛНИТЕЛЬНЫЕ ЭЛЕМЕНТЫ ДТР ДЛЯ СИСТЕМЫ ПРОЕКТОВ

В ДТР по системному управлению несколькими одновременными проектами необходимо добавить еще несколько НЯ:

• Руководство соглашается на нереальные сроки.

• Менеджеры проектов борются за ресурсы.

• Исполнителям приходится одновременно выполнять несколько работ из нескольких проектов.

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

• Исполнителей вынуждают работать сверхурочно без дополнительной оплаты.

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

11.7.2. ДОПОЛНЕНИЯ К ДБР

ПО СИСТЕМЕ ОДНОВРЕМЕННЫХ ПРОЕКТОВ

В ДБР, описывающее желаемую модель системы управления одновременными проектами, необходимо добавить следующие прорывные решения:

1. Определить ресурс-ограничение — «барабан» организации.

2. Определить приоритетность каждого проекта для создания графика «барабана».

3. Рассчитать даты начала и окончания проектов с использованием планов проектов и графика «барабана».

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

5. Добавить буфер ограничивающего ресурса перед каждой операцией, в которой задействован ресурс-ограничение.

11.7.3. ДОПОЛНЕНИЯ К ДП

ПО СИСТЕМЕ ОДНОВРЕМЕННЫХ ПРОЕКТОВ

В соответствии с обозначенными выше дополнительными прорывами из ДБР необходимо добавить следующие промежуточные цели в ДП:

1. Определен ресурс-«барабан».

2. Определен менеджер ресурса-«барабана».

3. Обозначен исходный приоритет каждого проекта.

4. Руководство утверждает сроки нового проекта только после того, как определен его приоритет по отношению к уже идущим проектам, разработан план и определена дата запуска, зависящая от доступности ресурса-«барабана» (то есть проект вписан в «конвейер»).

11.8. Перспективные направления применения ТОС

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

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

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

• Расширить ТОС на сферы, с которыми она поверхностно пересекается: теория поведения, психология, групповая динамика, творческое мышление. Так, можно приложить ТОС к идеям Де Боно [12] и ТРИЗ (теории решения изобретательских задач), а также распространить на основы мышления — архетипы, разрушить сами образы ограничений, лежащие на пути развития, согласно ТОС.

• Повысить эффективность использования практик РМВОК. Многие сталкиваются сейчас с трудностями в создании ИСР или сетевой диаграммы проекта.

• Более глубоко изучить процессы, связанные с психологией и поведением человека. На данном этапе ТОС, РМВОК, ОРМ3 не особенно сфокусированы на этих вопросах, хотя теория ограничений и предлагает мощное средство решения конфликтов — диаграмму «грозовая туча». В шести сигмах, похоже, этот аспект глубинных знаний, обозначенный Демингом, тоже обойден стороной.

• Продолжить движение в направлении использования в управлении проектами положений бережливого производства и гибких методологий. В ССРМ в некоторой степени использованы идеи из этих подходов, но можно копнуть гораздо глубже. Особенный интерес представляет положение об устранении потерь в бережливом производстве. А упор гибких методологий на создание полноценного продукта за короткий промежуток времени можно применить не только к проектам по разработке программного обеспечения.

Каждый день на свет появляются новые теории. Может, и у вас в голове зреют какие-нибудь свежие идеи. Часть новых теорий окажутся развитием старых (как шесть сигм продолжили начатое в TQM), часть отразят абсолютно инновационные подходы.

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

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

11.9. Итоги

Метод логических рассуждений помогает вам совершенствовать систему. Как было показано ранее, инструменты ТОС можно использовать и в качестве самостоятельных средств для решения отдельных вопросов. Диаграмма разрешения конфликтов работает на широком спектре проблем — от принятия личных решений до снятия напряженности в международных отношениях. Вот ключевые аспекты применения инструментов ТОС в управлении проектами:

• Ключевой конфликт, ведущий ко всем нежелательным явлениям в проекте, возникает между личностью и системой управления проектом.

• Ключевой конфликт связан с тем, решается ли в системе (и как именно) проблема неопределенности путем добавления запаса в буфер.

• Ограничение в отдельном проекте — критическая цепь — самая длинная последовательность работ проекта, выбранная с учетом логики расположения операций и ограниченности ресурсов.

• Максимальное использование возможностей данного ограничения достигается созданием в конце цепочек работ буферов, которые являются защитой от совокупной неопределенности по каждой операции.

• Управление при помощи буферов предполагает постоянное наличие информации о ходе работ в режиме реального времени. Информация — это ответ на поставленные вопросы, а не просто сырые данные. На ее основании возможно эффективное управление проектом, своевременное или досрочное доведение его до завершения.

• Ограничением системы проектов является ресурс, общий для всех проектов системы (ресурс-«барабан»).

• Чтобы максимально использовать возможности этого ограничения, необходимо искоренить многозадачность для всех исполнителей всех проектов.

• Оценка эффективности системы проектов должна быть подстроена под ограничение системы. Не забывайте: запасы мощности должны быть не только у «барабана», но и у всех ресурсов.

Вам придется несколько модифицировать идеальную модель системы управления проектом так, чтобы она учитывала специфику вашей ситуации. На практике предложенные здесь прорывные решения продемонстрировали свою состоятельность и универсальность на проектах самых разных типов. Разница, главным образом, проявляется в конкретных планах внедрения (то есть ДП и ППР). Как показывает опыт, решающими для успеха факторами являются грамотное управление преобразованиями и корректный план их внедрения. Не стоит недооценивать такое явление, как сопротивление устоявшейся организационной культуры, с которым вы неизбежно столкнетесь. Продумайте, как вы ответите на сопротивление, однако не планируйте никаких карающих мер против своих оппонентов. Зачастую самые злостные противники становятся самыми ярыми сторонниками преобразований, как только они поймут их суть и увидят новый подход в деле.

11.10. В заключение

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

Спасибо за то, что присоединились ко мне на этом пути. Всеми силами надеюсь, что и вы сумеете сделать членов вашей проектной команды счастливее.

ЛИТЕРАТУРА

1. Deming, W.Edwards, Out of the Crisis, Cambridge, MA: MIT Press, 1982 (в русском переводе: Деминг Э. Выход из кризиса. Новая парадигма управления людьми, системами и процессами. — М.: Альпина Бизнес Букс, 2007).

2. Womack J., and D.Jones, Lean Thinking: Banish Waste and Create Wealth in Your Corporation, New York: Simon & Shuster, 1996 (в русском переводе: Д. Вумек, Д. Джонс. Бережливое производство. Как избавиться от потерь и добиться процветания вашей компании. — М.: Альпина Бизнес Букс, 2004).

3. Pande, P.S., R.P. Neuman, and R.R. Cavanagh, The Six Sigma Way: Team Fieldbook. New York: McGraw-Hill, 2002.

4. PMI, Organizational Project Management Maturity Model, Newton Square, PA: PMI, 2003.

5. Goldratt, Eliyahu M., Critical Chain, Great Barrington, MA: North River Press, 1997.

6. Noreen, Eric, Debra Smith, and James T. Mackey, The Theory of Constraints and Its Implications for Management Accounting, Great Barrington, MA: North River Press, 1995.

7. Goldratt, Eliyahu M., The Goal, Great Barrington, MA: North River Press, 1984 (в рус ском переводе: Голдрат Э. М., Кокс Д. Цель. Процесс непрерывного совершенствования. — М.: Попурри, 2007).

8. DeBono, E., Lateral Thinking, Creativity Step by Step, New York: Harper & Row,

1970.

9. Popper, Karl R., Objective Knowledge, An Evolutionary Approach, Oxford: Clarendon

Press, 1979 (в русском переводе: Поппер К.Р. Объективное знание. Эволюционный подход. — М.: Эдиториал УРСС, 2002).

10. Dettmer, H. William, Eliyahu M. Goldratt’s Theory of Constraints, A Systems Approach to Continuous Improvement, Milwaukee, Wisconsin: ASQC Press, 1997 (в русском переводе: Детмер У. Теория ограничений Голдратта: Системный подход к непрерывному совершенствованию. — М.: Альпина Бизнес Букс, 2007).

11. Goldratt, Eliyahu M., It’s not Luck, Great Barrington, MA: North River Press, 1994 (в рус ском переводе: Голдратт Элия М., Кокс Д. Цель. Процесс непрерывного улучшения. Цель-2. Дело не в везенье. — Киев—Москва: Максимум, Логос, 2007).

12. Altshuller, G., And Suddenly the Inventor Appeared: TRIZ, the Theory of Inventive

Problem Solving, Worcester, MA: Technical Innovation Center, Inc., 1996. (Опубликовано впервые на русском языке под псевдонимом: И тут появился изобретатель/Г. Альтов. — 3-е изд., перераб. и доп. — М: Детская литература, 1989. — 142 с. — (Знай и умей).

13. Senge, P., et al., The Dance of Change, New York: Currency Doubleday, 1999.

Словарь ключевых понятий и сокращений

ABC - Опыт — поведение — последствия

Модель оперантного обусловливания Л. Браксик.

Activity - Операция

Низший уровень в иерархической структуре работ. Элемент, являющийся «кирпичиком» в сетевой диаграмме или плане проекта.

Activity Network - Сеть операций

Совокупность двух и более взаимосвязанных операций.

Actual Cost - Фактическаястоимость

Денежные средства, реально истраченные на выполнение операции на данный момент.

Actual Cost of Work Performed (ACWP) - Фактическая стоимость выполненных работ (ФСВР)

Термин, используемый в системах контроля затрат и прохождения расписания для обозначения сумм, реально истраченных на проекте.

Additional Cause Reservation - Проверка наличия альтернативной причины (критерий КПЛП)

Один из критериев проверки логических построений. Необходимо проверить, не существует ли одновременно с заявленной еще какой-то причины, вызывающей проявление исследуемого следствия как минимум в 30% случаев.

AGI - Институт Голдратта

Budjet at Completion (BAC) - Бюджет по завершении (БПЗ)

Banana - «Банан», эллипс

Символ для передачи логического «и», связывающего элементы в диаграммах ТОС. Овал, который объединяет стрелки от нескольких причин к следствию и показывает, что для наступления события необходимы несколько причин в совокупности.

Bar Chart - Диаграмма столбцов

См. также «Диаграмма Гантта».

Body of Knowledge - Свод знаний

Разработанный в PMI документ, выделяющий области знаний, формирующие дисциплину управления проектами.

Bottleneck - Узкое место

Ограничение в производственном процессе. Этап производства, сдерживающий общую производственную мощь системы. В управлении отдельным проектом «узким местом» является критическая цепь. В компании могут также быть ресурсы-ограничения, определяющие производительность организации в целом.

Budget - Бюджет

Плановый уровень расходов на проект, или ПСЗР. Может также включать в себя буфер на затраты, или запас на непредвиденные расходы.

Budgeted Cost of Work Performed (BCWP) - Плановая стоимость выполненных работ (ПСВР)

Освоенный объем средств — предусмотренная бюджетом сумма, которую планировали потратить на выполненные работы.

Budgeted Cost of Work Scheduled (BCWS) - Плановая стоимость запланированных работ (ПСЗР)

Заложенное в бюджет количество средств, которое планировалось потратить к данному числу на предусмотренный базовым планом проекта объем работ.

Buffer - Буфер

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

Buffer Penetration- Степень расходования буфера

Доля буфера, истраченная в ходе выполнения проекта.

Cost-Schedule-Control-Systems (SCSC) - Системы контроля затрат и прохождения расписания

См. «Системы контроля затрат и прохождения расписания».

Capacity Constraint Buffer - Буфер ограничивающего ресурса

Буфер, помещаемый между проектами или в графике «барабана», чтобы обеспечить непрерывность перехода исполнителя-ограничения от проекта к проекту в системном управлении одновременными проектами.

Capacity Constrain Resource - Ресурс-ограничение

В организации, выполняющей несколько проектов одновременно, — ресурс, который больше всего оказывается перегружен.

Categories of Legitimate Reservation (CLR) - Критерии проверки логических построений (КПЛП)

Правила выверки деревьев, построенных в рамках процесса логических рассуждений ТОС.

Causality Reservation - Наличие причинно-следственных отношений (критерий КПЛП)

Проверка того, действительно ли событие, на которое указывает стрелка в диаграмме, является неизбежным и непосредственным следствием события или событий у основания стрелки.

Cause - Причина

Событие, неизбежно ведущее к определенному следствию. Если при наличии одного события всегда наблюдается и другое событие, а при отсутствии первого второе никогда не наступает, значит, между данными событиями существует причинно-следственная связь.

Clarity Reservation - Ясность (критерий Один из критериев проверки логичности построения.КПЛП)

Если высказывается сомнение в соблюдении данного критерия, значит, говорящий не до конца понимает смысл того или иного элемента диаграммы.

Cloud (Evaporating) - Грозовая туча

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

Capability Maturiaty Model (CMM) - Модель зрелости системы (МЗС)

Common Cause - Общая причина

Событие, ведущее к нескольким результатам.

Common-Cause Variation - Вариабельность, вызванная общими причинами

Отклонения в параметрах результата процесса, определяемые спецификой самого процесса или системы и, следовательно, не связанные ни с какими особыми причинами вне рамок процесса. Также известны как «естественная вариабельность».

Communication - Коммуникация

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

Communication Current Reality Tree (CCRT) - Презентационное ДТР

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

Communication Future Reality Tree (CFRT)- Презентационное ДБР

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

Conflict Management - Управлениеконфликтами

Искусство эффективного управления конфликтами. ТОС предлагает использовать следующие инструменты: диаграмму разрешения конфликтов, презентационный план преобразований и ветвь негативного развития событий для хронических конфликтов.

Conflict Resolution Diagram (CRD) - Диаграмма разрешения конфликтов (ДРК)

Другое название диаграммы «Грозовая туча».

Constraint - Ограничение

Процесс или этап процесса, мешающий системе показывать большую производительность.

Constraint Buffer - Буфер ограничивающего ресурса, то же что Capacity Constraint Buffer

Буфер, размещаемый в графике «барабана» в качестве обеспечения достаточного запаса мощности.

Constraints - Ограничения

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

Contingency - Запасна непредвиденные обстоятельства

Буфер.

Core Conflict - Ключевой конфликт

Конфликт, вызывающий появление ключевой проблемы.

Core Problem - Ключевая проблема

Первопричина большинства нежелательных явлений в системе. Чтобы определить ключевую проблему, ищем элемент в ДТР, который вызывает (связан причинно-следственными отношениями) как минимум две трети всех НЯ и на который вы в состоянии хоть как-то повлиять.

Core Problem - Ключевая проблема

Проблема, ведущая к появлению по меньшей мере двух третей всех нежелательных явлений в ДТР и посильная для вас. Часто — первопричина нескольких истинных причин, или общая причина.

Corrective Action - Корректирующее воздействие

Процесс исправления ошибок, в рамках которого выявляется дефект, назначается ответственный, проводится анализ первопричин, планируются и реализуются меры по решению проблемы.

Cost Buffer - Буфер на затраты

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

Cost Schedule Control System - Система контроля затрат и прохождения расписания

Система оценки объемов выполненных работ, на основании которой рассчитываются выплаты по проекту. Главное новшество — использование показателя «плановая стоимость выполненных работ», то есть оценочных параметров фактически завершенных операций как меры выполнения проекта.

Cost Variance (CV) - Отклонение по стоимости

Разница между плановой и фактической стоимостью выполненных работ (то есть ПСВР минус ФСВР). Если результат получается минусовой, налицо перерасход бюджета.

Cost World - Управление по затратам

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

Cost-Schedule-Control-Systems Criteria - Критерии системы контроля затрат и прохождения расписания

В 1967 году министерство обороны США разработало стандарт по использованию анализа освоенного объема в оборонных проектах. С тех пор сфера применения стандарта расширилась, соответствующие правила легли в основу многих программ по составлению планов проектов.

CPI - ИВСТ

Индекс выполнения стоимости.

CPM - Метод критического пути

Когда-то инновационный метод работы с сетевой диаграммой проекта и нахождения критической для успеха проекта последовательности работ.

Critical Activity - Критическая операция

Операция, входящая в критическую цепь.

Critical Chain - Критическая цепь

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

Critical Path - Критический путь

Самая длинная последовательность работ в сетевой диаграмме проекта, как правило, но не всегда, с нулевым временным резервом. Продукт математики. Кроме вычисленного критического пути могут иметься и другие цепочки работ с минимальным временным резервом.

Critical-Chain Feeding Buffer - Буфер на слияние путей в ССРМ

Временной буфер, добавляемый в конец последовательности операций, которая «вливается» в критическую цепь.

Critical-Chain Project Management (CCPM) - Управление проектом по методу критической цепи

Система управления проектом, в которой минимизированы все нежелательные явления из ДТР, описывающего текущее состояние управления проектами.Предусматривает наличие плана проекта, составленного по методу критической цепи, мощного инструментария для снятия измерений, управления при помощи буферов, а также работу в стиле «эстафеты».

Critical-Chain Resource Buffer - Ресурсный буфер в ССРМ

См. «Ресурсный буфер».

Critical-Chain Schedule - Расписание по методу критической цепи

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

CS2 - Система контроля затрат и прохождения расписания

CSCS - Система контроля затрат и прохождения расписания

Current Reality Tree (CRT) - Дерево текущей реальности (ДТР)

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

Data - Данные

Любая последовательность знаков, описывающая какой-то аспект реальности.

DBR - Барабан-буфер-веревка(Drum-Buffer-Rope)

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

Dependency Links - Зависимости

Различные типы связей, соединяющие операции в сетевой диаграмме: финиш-старт, старт-старт, финиш-финиш, старт-финиш.

Dependent Events - Зависимые события

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

Desired Effect (DE) - Желаемый результат (ЖР)

Положительное событие, которое в будущей модели системы должно прийти на смену нежелательному явлению текущей реальности.

DMAIC - Define — определяй, Measure — измеряй, Analyze — проанализируй, Improve — совершенствуй, Control — контролируй.

DOD - Министерство обороны США

DOE - Министерство энергетики США

Dollar Days - Доллар-дни

Интегрированный ежедневный поток наличности по данному продукту (разница между поступающим и проданным товаром), умноженный на количество дней.

Drum - Барабан

Ресурс, определяющий последовательность запуска проектов. На производстве мощность «узкого места» задает темп и порядок работ всего завода. См. также Ресурс-ограничение».

Drum Buffer - Буфер ограничивающего ресурса, буфера «барабана»

Буфер, помещаемый в план проекта как механизм защиты от простоя ресурса-ограничения, от нехватки материалов для него. Также его иногда называют буфер «барабана», буфер стратегического ресурса, буфер ограничения.

Duration - Длительность

Отрезок времени, за который ожидается выполнить ту или иную операцию.

EAC - Прогноз по завершении

Early - Finish Date-Раннее окончание

Самое раннее, когда может быть завершена операция. Высчитывается методом прямого прохождения критического пути.

Early-Start Date - Раннее начало

Самое раннее, когда может быть начата операция. Высчитывается методом прямого прохождения критического пути.

Earned Value - Освоенный объем

Сумма, которая по плану должна быть затрачена на выполненный объем работ. Также обозначается термином «плановая стоимость выполненных работ» в системах контроля затрат и прохождения расписания.

Earned-Value Analysis - Анализ по методу освоенного объема

Анализ состояния проекта, в рамках которого фактически истраченные суммы оцениваются в соответствии с тем, каков объем выполненных работ. См. также «Критерии систем контроля затрат и прохождения расписания».

Effect - Следствие

Блок в логической диаграмме, обозначающий результат влияния одной или нескольких причин.

Efficiency - Производительность

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

Elevate - Устранить ограничение

Термин в теории ограничений, обозначающий увеличение пропускной способности ограничения системы. В применении к проектам это, как правило, достигается увеличением количества исполнителей.

Entity - Элемент логической диаграммы

Часть диаграммы, описывающая факт действительности.

Entry Point - Отправная точка

Элемент в диаграмме достаточности, к которому не ведут стрелки ни от каких причин.

Erroneous Information - Ложная информация

Неправильный ответ на заданный вопрос.

Estimate at Completion - Прогноз по завершении

Плановый объем совокупных расходов по проекту.

Estimate to Complete (ETC) - Прогноз до завершения (ПДЗ)

Оценочная величина времени/бюджета, необходимых для завершения работ.

Estimating - Оценка

Процесс определения плановых стоимости и длительности работ.

Evaporating Cloud - Рассеивающееся облако

См. Грозовая туча.

Existence Reservation - Наличие утверждения

Вопрос типа «Чем докажешь?», направленный на любой элемент или стрелку в логической диаграмме ТОС.

Exploit - Максимально использовать ограничение

Термин ТОС, обозначающий мероприятия, нацеленные на максимальное использование возможностей ограничения для достижения цели системы.

External Constraint - Внешнее ограничение

Фактор, воздействующий на проектные работы извне проекта. Как правило, законодательные нормы, заданная и неизменная дата окончания проекта, особенности среды реализации проекта.

F&OR - Функциональные и операционные требования

Feeding Buffer - Буфер на слияние путей

См. «Буфер на слияние путей в ССРМ».

Finish to Start - Финиш-старт

Тип связи между операциями в диаграмме проекта, показывающий, что операция не может начаться, пока не завершится предыдущая.

Five Focusing Steps - Пять направляющих шагов

Процесс определения и снятия ограничения, состоящий из пяти этапов. См. раздел 2.6.3.

Float - Временной резерв

Интервал времени, дающий некоторую свободу в выполнении операции. Бывает трех видов: общий, свободный и независимый. Минимальный срок, на который можно увеличить время выполнения операции под влиянием факторов, не входящих в зону контроля менеджера проекта.

Free Float - Свободный временной резерв

Время, на которое можно задержать выполнение операции без риска вызвать задержки по следующим за ней операциям.

Future Reality Tree (FRT) - Дерево будущей реальности

Логическая диаграмма, основанная на принципах достаточности условий для наступления события. Показывает связи прорывных решений и желаемых результатов.

Gantt Chart - Диаграмма Гантта

Схема, показывающая соотнесенный с временной шкалой перечень операций в виде горизонтальных столбцов, длина которых пропорциональна длительностям операций.

Goal, the - Цель

См. «Иона».

Hockey Stick - Хоккейная клюшка

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

House-on-FireReservation - Подмена причины следствием

Утверждение типа «Если виден дым и пожарные машины, значит, в доме пожар». Ни дым, ни пожарные машины не являются причинами пожара. Это симптомы, по которым мы догадываемся, что дом загорелся. Деревья ТОС — это диаграммы, передающие причинноследственные отношения. Поэтому такая логика для них не годится.

Identify - Найти ограничение

Первый из пяти направляющих шагов ТОС, суть которого заключается в определении элемента системы, ограничивающего ее мощность.

Information - Информация

Ответ на заданный вопрос.

Injection - Прорыв

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

Integrated Plan - Интегрированный план

План проекта, показывающий как сроки, так и бюджет работ.

Intermediate Objective (IO) - Промежуточная цель (ПЦ)

Действие или результат действия, являющиеся необходимым условием прорыва или достижения другой ПЦ.

Invalid Data - Недостоверные данные

Данные, на которых нельзя строить логические заключения.

Inventory - Вложения

Все деньги, вложенные в оборудование, необходимое для преобразования сырья в продукт, приносящий прибыль, то есть обеспечивающий показатель «производительность по денежному потоку».

Jonah - Иона

Звание, присваиваемое выпускникам курсов Ионы, проводимых Институтом Голдратта AGI. Ключевой герой романа Голдратта «Цель» — наставник, обучающий методом диалогов Сократа.

Late-Finish Date - Позднее окончание

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

Leadership - Лидерство

Делать, что должно, и побуждать других следовать за собой.

Linked Projects - Связанные проекты

Термин, используемый в некоторых компьютерных программах для обозначения проектов, в которых используются одинаковые ресурсы.

Logic Link - Логическая связь

См. «Зависимости».

Logic Loop - Логическая петля

Циклическая зависимость между операциями в диаграмме проекта.

Mean - Среднее

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

Median - Медиана

Величина, находящаяся в середине ранжированного ряда значений выборки.

Merge Node - Узел слияния

Точка соединения нескольких связей или операций в диаграмме проекта.

Milestone - Контрольное событие, контрольная точка, веха

Операция, обозначающая достижение важного результата или прохождение некоторого этапа проекта. В плане имеет нулевую длительность.

Milestone Plan - План контрольных событий

Последовательность прохождения исключительно контрольных точек проекта.

Multiproject Management - Системное управление несколькими проектами

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

Multitasking - Многозадачность

Наличие у исполнителя нескольких проектных заданий одновременно.

NBR - НВ

Негативная ветвь.

Necessary Condition #1 - Необходимое условие 1

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

Necessary Condition #2 - Необходимое условие 2

Еще одно условие, необходимое для достижения цели любой компании, — удовлетворять потребности сотрудников и мотивировать их сейчас и в будущем.

Necessity Tree - Дерево необходимости

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

Need - Потребность

Требование, которое обязательно должно быть удовлетворено, чтобы достичь промежуточную или общую цель системы.

Negative Branch - Негативная ветвь (НВ)

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

Network - Сетевая диаграмма

Схема расположения операций в проекте, составленная методом предшествования («операции в узлах») или методом стрелочных диаграмм («операции на дугах»).

Network Analysis - Анализ сети расписания (сетевой диаграммы)

Общий термин для обозначения методов анализа расписания и определения дат начала и окончания работ. Например, PERT, метод критического пути.

Node - Узел

Точка соединения стрелок, обозначающая конец одной операции и начало другой в диаграмме типа «операции на дугах», или прямоугольник, обозначающий операцию, в диаграмме типа «операции в узлах».

Obstacle - Препятствие

Элемент логической диаграммы, обозначающий событие, мешающее получению некоторого результата.

Operating Expense - Операционные расходы

Все деньги, которые система тратит на перевод сырья в продукт для повышения производительности по денежному потоку Т.

Overtime - Сверхурочное время работы

Дополнительное время работ, которое можно назначить исполнителю при составлении расписания в некоторых компьютерных программах.

PDCA - Plan — планируй, Do — делай, Check — проверяй, Act — внедряй.

Percentage Complete - Процент завершенных работ

Число, показывающее, какая часть операции уже выполнена. Один из способов, участвующих в определении плановой стоимости выполненных работ.

Performance Measurement - Оценка качества работ

Метод соотнесения объема выполненных работ с объемом потраченных денежных средств. Определяется, чем вызваны отклонения стоимости: тем, что выполнено больше (или меньше), чем планировалось; или тем, что работы оказались более (или менее) затратными, чем ожидалось. Таким образом оказывается возможным установить, идет ли проект в рамках бюджета или с превышением или экономией. См. «Анализ по методу освоенного объема».

Pessimistic Duration - Пессимистичная оценка длительности

Максимально возможная длительность — одна из трех оценок, получаемых методом PERT.

Plan - План

Общий термин для обозначения некоего изложения намерений в области сроков, средств или качества. Бывает в самых разных формах.

Project Management Body of Knowledge (PMBOK) - Свод знаний по управлению проектами — совокупность всех знаний в данной отрасли.

PMBOK Guide - Руководство РМВОК

Руководство к своду знаний по управлению проектами — отраслевой стандарт.

Project Management Institute (PMI) - Институт управления проектами

Основанная в 1969 году ведущая международная некоммерческая ассоциация профессионалов в управлении проектами, разрабатывающая специализированные стандарты, проводящая конференции, семинары, образовательные программы и осуществляющая профессиональную сертификацию.

PMP - Профессионал в управлении проектами

Project Management Professional — звание, присваиваемое практикующим проджект-менеджерам, сдавшим специальный экзамен Института управления проектами.

Predecessor - Предшествующая операция

Операция, логически идущая перед другой операцией. См. также «Последующая операция».

Predicted Effect Reservation - Поиск проверочного следствия

Один из критериев проверки логических построений, сводящийся к следующему утверждению: «Эта мысль неверна, поскольку если бы действительно было так, то мы бы наблюдали и другое следствие данного явления».

Prerequisite Tree (PRT) - Дерево перехода (ДП)

Логическая диаграмма, показывающая последовательность действий по достижению цели. Соединяет промежуточные цели по преодолению препятствий с результатами преодоления. Читается с помощью формулировок «Чтобы проявилось событие, на которое указывает стрелка, нужно обеспечить наличие события в основании стрелки, потому что имеется следующее препятствие...».

Priority - Приоритезация

Метод определения порядка следования операций при составлении планов работ для исполнителей.

Probability - Вероятность

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

Problem - Проблема

Несоответствие между желаемым и действительным.

Process - Процесс

Последовательность взаимосвязанных действий, у каждого из которых есть некий материал на входе и результат на выходе.

Program - Программа

Совокупность проектов, отобранных и планируемых совместно для достижения ряда определенных целей, способствующая продвижению ряда, как правило, перекликающихся инициатив и/или осуществлению некоей стратегии. Иногда — отдельный, но крупный или сложный проект. Иногда — ряд независимых проектов, объединенных лишь расположением в производственном цикле организации.

Program Evaluation and Review Technique (РЕРТ) - Метод оценки и анализа программ

Метод составления расписания, отличающийся от СРМ ориентацией на три точки — оптимистичную, пессимистичную и наиболее вероятную оценки длительности работ.

Program Management - Управление программой

Отбор и синхронизированное планирование совокупности проектов по достижению определенных бизнес-целей организации. Эффективное выполнение этих проектов в рамках контролируемых условий для достижения максимальных результатов.

Program Manager - Менеджер программы

Специалист, отвечающий за повседневное управление программой.

Program Plan - План программы

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

Progress Reporting - Отчетность по статусу проекта

Процесс сбора информации о выполненных работах, пересмотра плановых значений длительностей и затрат, обновления плана и обнародования пересмотренного плана.

Project - Проект

Временное предприятие для достижения определенной бизнес-цели путем контроля и координации материально-технических и иных ресурсов.

Project Buffer - Проектный буфер

Буфер, содержащий запасное время и помещаемый в конец критической цепи с целью защитить проект от срыва сроков.

Project Management - Управление проектом

Управленческая задача по завершению проекта в рамках установленных сроков, бюджета и технических условий. Главным ответственным за выполнение задачи является менеджер проекта.

Project Manager - Менеджер проекта

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

Quality - Качество

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

R&D - НИОКР

RDU - Остаточная длительность

Required Data - Необходимые данные

Данные, наличие которых предписывается процедурой принятия решений для определения ответа на некий вопрос.

Resource - Ресурс, исполнитель

Исполнитель проектных работ, будь то сотрудник компании, субподрядчик или техническое приспособление.

Resource Buffer (Flag) - Ресурсный буфер

Оповестительный флаг, помещаемый на критической цепи, чтобы исполнители были готовы к тому моменту, когда они потребуются. Призван защищать выполнение расписания ССРМ. Обеспечивает наличие ресурсов и не увеличивает длительность цепи. Бывает в форме договоренности с исполнителем о том, что тот будет наготове весь тот период времени, когда может вам понадобиться. Часто называется ресурсным буфером критической цепи.

Resource Leveling - Выравнивание ресурсов

Процесс перераспределения операций в соответствии с имеющимися в распоряжении менеджера ресурсами и ограниченностью их времени.

Resource Limit - Ограниченность времени ресурсов

Количество времени, которое исполнитель может уделить проекту в тот или иной момент.

Risk - Риск

Нежелательное событие с определенной вероятностью и степенью последствий для проекта. Как правило, несет угрозу срокам, бюджету или содержанию проекта. Бывают также риски, связанные с безопасностью, экологией, бизнесом.

Root Cause - Истинная причина, первопричина

Причина, удаление которой повлечет за собой избавление от ее нежелательного следствия.

Rope - Веревка

Канал информации от барабана (ограничения) к звену, подающему материал на производственный участок и управляющему таким образом темпами производства.

Rational Unified Process (RUP) - Рациональный унифицированный процесс (в методологии Agile).

Schedule - Расписание

Расположение операций во времени.

Schedule Variance (SV) - Отклонение по срокам (ОСР)

Разность между объемом выполненных и плановых работ (то есть ПСВР — ПСЗР). Отрицательный результат показывает, что есть отставание от графика.

Scheduling - Составление расписания

Определение оптимального по времени способа достижения целей проекта. Включает в себя установление ограничений по срокам, по ресурсам, а также иных внутренних и внешних ограничений и соответствующее последующее расположение операций проекта.

Scrutiny - Анализ дерева ТОС

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

Software Engineering Institute (SEI) - Институт инжиниринга программного обеспечения.

SIPOC - Supplier — поставщик, Input — материал на входе, Process — процесс, Output — результат процесса, Customer — клиент.

Slack - Резерв времени

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

SOWs - Содержание работ

Special-Cause Variation - Вариабельность по особым причинам

Вариабельность в результатах процесса, у которой есть некая особая причина.

SSQ - Квадратный корень суммы квадратов

Statistical Fluctuations - Статистические колебания

Вызванная общими причинами количественная или качественная вариабельность процесса (включая длительность и стоимость проектных работ).

Student Syndrome - Студенческий синдром

Естественная склонность большинства людей оттягивать выполнение работы до последнего момента и с наступлением его усиленно взяться за дела. См. также «Хоккейная клюшка».

Subordinate - Подчинить все нуждам ограничения

Третий из пяти направляющих шагов ТОС. Все, что напрямую не работает на достижение цели компании, должно отойти на второй план. Самым важным является то, что непосредственно влияет на способность системы достичь поставленные цели.

Successor - Последующая операция

Операция, идущая логически после другой операции. См. также «Предшествующая операция».

Sufficiency Tree - Диаграмма достаточности

Дерево ТОС, в котором события, на которые указывают стрелки, являются неизбежным следствием причин у основания стрелок.

System - Система

Сеть зависимых элементов, которые взаимодействуют для достижения цели системы. Без цели нет системы.

Systems and Procedures - Системы и процедуры

Стандартные методы, практики и процедуры для проведения ряда мероприятий проекта: утверждение с руководством, контроль, формализация технических требований. К системам также относятся методы передачи и хранения информации.

Task - Задача

То же, что операция.

Theory of Constraints (TOC) - Теория ограничений

Теория системы, разработанная Э. Голдраттом и впервые изложенная в его романе «Цель». Ключевым положением является утверждение, что результативность системы всегда определяется неким ограничением.

Thinking Process - Процесс логических рассуждений ТОС

Пять шагов, позволяющих понять, что менять, на что менять и как провести преобразования. Последовательность процесса такова: ДТР, ДРК, ДБР, ДП и пПр.

Throughput - Производительность системы по денежному потоку

Все деньги, которые платят клиенты, за вычетом расходов на сырье.

TQM - Всеобщее управление на основе качества.

Transitions Tree (TRT) - План преобразований (ППР)

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

UDEs - НЯ

Нежелательное явление.

Variance(Statistical) - Отклонение(статистическое)

Разброс в выборке и оценка стандартного отклонения в генеральной совокупности.

Want - Желаемое

Результат, который под влиянием некоторых установок считается необходимым для удовлетворения потребности.

Work Breakdown Structure (WBS) - Иерархическая структура работ (ИСР)

Дерево, отображающее декомпозицию проекта на несколько уровней детализации. Самый низший уровень — пакеты работ.

Об авторе

Лоуренс Лич — президент компании Advanced Projects Inc. (API), оказывающей услуги в области управленческого консультирования. Специализацией компании является управление проектами, в том числе по методу критической цепи (ССРМ). Лоуренс Лич помогает внедрять ССРМ в крупных и небольших организациях для управления самыми разнообразными проектами в таких сферах, как НИР, фармацевтика, ИТ, ремонт и техподдержка, строительство и пр. Он успешно управлял программами самых разных проектов в нескольких компаниях списка Fortune 500. До этого в его карьере числится успешная реализация десятков проектов с бюджетом до миллиарда долларов.

Лич имеет степени магистра естественных наук в области машиностроения (Коннектикутский университет) и MBA (Университет Айдахо). Во время учебы в бакалавриате Технологического института Стивенса Лоуренс был удостоен звания члена почетного научно-технического общества «Тау Бета Пи». Лич является членом PMI и имеет сертификат РМР. Опубликовал множество статей по вопросам управления проектами, в том числе работу о критической цепи в выпуске PMI Journal за июнь 1999 и 2003 годов, ряд статей в PM Networks весной 2001 года. Ведет семинары PMI Seminars, а также участвует в организации курсов МВА Университета Феникса.

1

Концепция ССРМ описана в руководстве PMBOK™ редакции 2004 года в разделе 6.5.2.6 «Разработка расписания: инструменты и методы. Метод критической цепи». — Прим. пер.

(обратно)

2

A Guide to the Project Management Body of Knowledge, в дальнейшем РМВОК. (Здесь и далее — примечания редакции «Альпина Бизнес Букс».)

(обратно)

3

Метод критической цепи описан в руководстве PMBOK редакции 2004 года в разделе 6.5.2 «Разработка расписания: инструменты и методы», пункт 6.

(обратно)

4

Обзор дается автором на основании руководства РМВОК редакции 2000 года. В действующей на момент перевода книги редакции 2004 года состав и распределение процессов претерпели ряд изменений, которые тем не менее не являются существенными для понимания концепции критической цепи.

(обратно)

5

При работе над русскоязычной версией книги использован перевод терминов РМВОК из «Руководства к своду знаний по управлению проектами» в редакции 2004 года, выпущенного PMI на русском языке.

(обратно)

6

Распространенная в Великобритании методология управления проектами Projects in Controlled Environments.

(обратно)

7

Простой и строго структурированный подход цикличной разработки ПО, предложенный в 1986 году специалистами Hirotaka Takeuchi и Ikujiro Nonaka в журнале Harvard Business Review.

(обратно)

8

MBNQA (Malcolm Baldrige National Quality Award) — основная премия для организаций за достижения в области качества в США.

(обратно)

9

Любой процесс может быть представлен в виде математической модели, где основными параметрами результата процесса выступают среднее значение и стандартное отклонение. Параметр «среднее значение» отвечает на вопрос, как работает процесс в среднем, и обозначается символом ц (мю). Стандартное отклонение показывает степень вариабельности результата процесса и обозначается символом с (сигма).

(обратно)

10

Правило суммирования отклонений говорит, что квадрат общего стандартного отклонения равен

•-> 2 2 2 2 2

(обратно)

11

сумме квадратов отдельных стандартных отклонений: s²= s2+ s2+ s| + ...+ s2.

(обратно)

12

(1² + 1² + 1² + 1²)^1/2.

(обратно)

13

Речь идет о системе предупредительных сигналов, которые оповещают исполнителя об изменении приоритетов либо статуса работ.

(обратно)

14

Сноска дана на страницу РМВОК 2000 в оригинале.

(обратно)

15

Имеется в виду математическая дисперсия распределения.

(обратно)

16

Популярные в США комиксы про жизнь офисных служащих.

(обратно)

17

Имеется в виду — на момент написания книги, еще до выхода РМВОК 2000.

(обратно)

18

Имеется в виду так называемый «Супербоул» — технический индикатор тенденций развития фондового рынка США, соотносящий состояние рынка с результатами чемпионата по американскому футболу: победа в финале чемпионата команды, которая до 1970 года входила в старую Американскую футбольную лигу, якобы означает падение рынка в текущем году, а победа команды, входившей до 1990 года в Национальную футбольную лигу, — подъем рынка; любопытно, что данный индикатор обычно верно предсказывает конъюнктуру рынка.

(обратно)

Оглавление

Предисловие

Благодарности

Глава 1. Начнем с начала

Глава 2. ТОС, РМВОК, бережливое производство и шесть сигм

Глава 3. Выбираем подход к решению

Глава 4. Комплексное решение для отдельного проекта

Глава 5. Запуск нового проекта

Глава 6. Создание плана отдельного проекта по методу критической цепи

Глава 7. Создание сводного плана нескольких проектов методом критической цепи

Глава 8. Оценка и контроль выполнения плана

Глава 9. Как внедрить метод ССРМ

Глава 10. Управление рисками в проекте

Глава 11. Логические инструменты ТОС в управлении проектами

Словарь ключевых понятий и сокращений

Об авторе

Fueled by Johannes Gensfleisch zur Laden zum Gutenberg

Наш сайт является помещением библиотеки. На основании Федерального закона Российской федерации "Об авторском и смежных правах" (в ред. Федеральных законов от 19.07.1995 N 110-ФЗ, от 20.07.2004 N 72-ФЗ) копирование, сохранение на жестком диске или иной способ сохранения произведений размещенных на данной библиотеке категорически запрешен. Все материалы представлены исключительно в ознакомительных целях.

Copyright © читать книги бесплатно