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

Глава 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)

Данный текст является ознакомительным фрагментом.