Страница:
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 сказано:
ОРМ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, что в переводе означает «сортировать, соблюдать порядок, содержать в чистоте, стандартизировать процедуры, совершенствовать». Первые три понятия относятся к общему поддержанию порядка на рабочем месте. Оставшиеся два — к самоорганизации работника, которая позволит ему придерживаться первых трех, а также к руководству, которое обязано следить за соблюдением перечисленных правил.)
Большинство этих инструментов бережливого производства могут напрямую использоваться в управлении проектами, а ТОС поможет определить, какой из них лучше применить в конкретной системе управления проектами. Детмер также говорит об опасности, которая подстерегает при слиянии подходов ТОС и бережливого производства, связанной с двумя присущими последнему подходу факторами: «В особенности необходимо пересмотреть такие положения бережливого производства, как чрезмерный упор на сокращение расходов и повышение производительности каждого элемента системы, поскольку это приводит к субоптимизации». Предлагаемый в настоящей книге подход ССРМ использует сильные стороны синтеза двух теорий, избегая при этом подобных ловушек.
• командную работу;
• процессы коммуникации;
• эффективное использование ресурсов и устранение потерь;
• непрерывное совершенствование.
Развивая эту тему, Вумек и Джонс фокусируются на проблеме потерь и указывают на необходимость:
• определить, что является ценностью для конечного пользователя;
• выявить поток создания ценности;
• сфокусироваться на движении материалов в процессе производства;
• внедрить «вытягивающую» систему производства;
• стремиться к совершенствованию.
Эти принципы очень хорошо соотносятся с положениями ТОС, если под «ценностью» мы будем понимать цель организации. Они также соответствуют концепции «шесть сигм», однако делают больший упор на системе, фокусируясь на потоке создания ценности и освещая идею «вытягивающего» производства (выпуск продукции производится только по требованию клиента) под иным углом, чем шесть сигм. ВМС США создали некий синтез двух концепций и назвали его «бережливые сигмы» (Lean Sigma).
Бережливое производство, подобно ТОС, не сразу нашло свое применение в сфере управления проектами — вероятно, отчасти по той же самой причине: считалось, что это подход к работе с производственными, а не проектными операциями.
У. Детмер приводит превосходное выражение, описывающее синергию при взаимодействии двух теорий [6]: «На уровне организации ТОС представляет собой своего рода систему наведения, позволяющую направить усилия организации по применению бережливого производства туда, где это будет полезней всего, и предотвратить использование его там, где это только навредит».
Детмер также указывает на преимущества совместного использования ТОС и бережливого производства, включая такие методы последнего, как:
• пока-ёкэ (метод предупреждения ошибок);
• статистическое управление процессами;
• непрерывное совершенствование;
• анализ характера и последствий отказов (FMEA);
• принудительная остановка конвейера;
• организация рабочих ячеек (в данном случае создание рабочих центров там, где естественным образом сложились рабочие группы);
• роли, ответственность и правила работы в команде;
• графическое представление рабочих инструкций;
• визуальный контроль;
• 5s (От японских слов seiri, seiton, seiso, seiketsu, shitsuke, что в переводе означает «сортировать, соблюдать порядок, содержать в чистоте, стандартизировать процедуры, совершенствовать». Первые три понятия относятся к общему поддержанию порядка на рабочем месте. Оставшиеся два — к самоорганизации работника, которая позволит ему придерживаться первых трех, а также к руководству, которое обязано следить за соблюдением перечисленных правил.)
Большинство этих инструментов бережливого производства могут напрямую использоваться в управлении проектами, а ТОС поможет определить, какой из них лучше применить в конкретной системе управления проектами. Детмер также говорит об опасности, которая подстерегает при слиянии подходов ТОС и бережливого производства, связанной с двумя присущими последнему подходу факторами: «В особенности необходимо пересмотреть такие положения бережливого производства, как чрезмерный упор на сокращение расходов и повышение производительности каждого элемента системы, поскольку это приводит к субоптимизации». Предлагаемый в настоящей книге подход ССРМ использует сильные стороны синтеза двух теорий, избегая при этом подобных ловушек.
2.3. Agile, или Облегченные методы управления проектами
Значительной доли внимания удостоились легкие, или гибкие (agile), методы, предлагаемые для решения проблем, характерных для проектов, связанных с информационными технологиями. В Википедии говорится [7]: «Методы Agile возникли в середине 1990-х годов отчасти в противовес чрезвычайно формализованным методам, таким как Rational Unified Process (рациональный унифицированный процесс, RUP), Prince[6], ISO 9000. Процессы, порождаемые данными методами, считались бюрократизированными, медленными, противоречащими стилю командной работы, принятой у инженеров, создающих ПО». Сторонники иногда называют этот подход «бережливое управление проектами» по аналогии с «бережливым производством». Причины, по которым в мире появились гибкие методы, описаны в главе 1: значительное превышение сроков и бюджета, неспособность добиться заявленных характеристик продукта в большинстве ИТ-проектов. Облегченные методы по ИТ-проектам включают:
1. быструю разработку приложений;
2. параллельную разработку приложений;
3. экстремальное программирование;
4. SCRUM[7].
Подробное рассмотрение этих методов не является нашей целью.
Я все же с изрядной долей скептицизма воспринимаю объяснения типа «традиционное управление проектами не подходит для ИТ-проектов» как причину появления облегченных, или гибких, методов. От людей, по-настоящему, профессионально разбирающихся в управлении проектами (имеющих сертификат РМР), я подобных заявлений не слышал. Так, Дэвид Андерсон [8, с. 55] пишет:
Приведу несколько соображений насчет «гибкого» управления в ситуации, когда требования определены не четко. Во-первых, такие стандарты, как РМВОК и ОРМ3, не требуют досконального соблюдения всех своих предписаний абсолютно во всех проектах в каждой организации. Это некое меню, из которого можно выбирать и которое можно адаптировать к нуждам конкретной компании. Да, люди склонны применять подобные стандарты буквально и целиком, увязая в деталях, но проблема-то при этом не в стандарте, а в его использовании. К счастью, уже в самом начале карьеры я научился легко адаптировать такие стандарты к конкретным проектам, указывая в каждом плане проекта те процедуры, которые применимы в данном случае. Я понял, как использовать проверочные списки, чтобы быстро отбирать самое необходимое для конкретного проекта. В небольших, краткосрочных и малобюджетных проектах особые формальности не нужны и требуются очень простые приемы планирования и коммуникации. Проекты крупные, длительные, дорогие, с вовлечением большого количества подразделений и организаций должны быть более формализованы, тщательнее спланированы и строже контролируемы.
Во-вторых, бывают проекты, задачу которых при запуске невозможно сформулировать целиком и полностью. К ним относятся многие проекты в сфере информационных технологий. Во многих случаях детали того, что предстоит сделать, в самом начале неясны, например при ремонте, техобслуживании или разработке нового лекарства. В таких проектах результаты первых шагов могут изменить последовательность дальнейших действий, и к подобным ситуациям наилучшим образом подходит планирование методом «набегающей волны». Вы детально планируете лишь то, что можете окинуть взором в данный момент с имеющейся у вас информацией и при существующих исходных установках, и уже в самом плане предусматриваете действия по его пересмотру при поступлении новых данных. Некоторые компании применяют данный подход при создании планов долгосрочных программ, когда не известны подробности более поздних этапов и нет четких прогнозов относительно финальных стадий программы. В самой программе запланирован ряд проектов по внесению существенных изменений в общий план. Это пример работы тезиса бережливого производства об устранении потерь, в данном случае — потерь времени на ненужное предварительное планирование.
Для контроля за происходящими переменами, в том числе для уточнения исходных условий во всех проектах должен существовать эффективный процесс управления изменениями. Управление изменениями — ключевая составляющая гибкого управления проектами. Управлению изменениями посвящены особые разделы РМВОК. Менеджеры ИТ-проектов часто жалуются на непрерывные неконтролируемые корректировки проектного задания — на «сдвиг содержания» (scope creep). Я им объясняю, что в моих проектах все корректировки задания контролируются и что, на мой взгляд, потеря контроля — это проблема, которая связана с неопытностью самого менеджера, не использующего эффективные методы управления изменениями. Многие сами признают это, объясняя бесконтрольность сложившейся ситуации тем, что при запуске проекта не были определены должным образом исходные установки и границы содержания или со всеми вовлеченными сторонами не были оговорены соответствующие важные процедуры. В дальнейшем, начав контролировать изменения, менеджеры замечают, что проекты, к их удивлению, становятся более управляемыми и появляется возможность успешно завершать их в срок.
И наконец, выполнение проектов в максимально короткие сроки сокращает общие потери, в частности потери, вызываемые происшедшими изменениями, которые воздействуют не только на планы, но и на ранее достигнутые результаты. ССРМ способствует большей гибкости проектных организаций в их реакции на изменяющиеся потребности и служит дополнением ко всем гибким методологиям.
1. быструю разработку приложений;
2. параллельную разработку приложений;
3. экстремальное программирование;
4. SCRUM[7].
Подробное рассмотрение этих методов не является нашей целью.
Я все же с изрядной долей скептицизма воспринимаю объяснения типа «традиционное управление проектами не подходит для ИТ-проектов» как причину появления облегченных, или гибких, методов. От людей, по-настоящему, профессионально разбирающихся в управлении проектами (имеющих сертификат РМР), я подобных заявлений не слышал. Так, Дэвид Андерсон [8, с. 55] пишет:
«В традиционном подходе при запуске проекта главная задача — четко определиться с содержанием, зафиксировать бюджет (включая людей и ресурсы) и дату окончания работ. На этом основании стоит классическая модель управления проектами PMI, поддерживаемая тяжеловесными методами контроля качества ISO 9000… что создает для менеджеров ИТ-проектов наихудшие условия при разработке софта… Существующая модель управления проектами по PMI/ISO 9000 устарела» (с. 60).Несмотря на то, что далее Андерсон демонстрирует искусный подход к внедрению ССРМ в ИТ-проектах, по моим личным наблюдениям за ИТ-компаниями, столкнувшимися с трудностями при реализации проектов, многие из них не понимают традиционной методики, а если и применяют ее, то неправильно. Основные ошибки: неполное исходное определение содержания проекта (например, нет иерархической структуры работ) и использование неэффективного процесса управления изменениями или вообще полное отсутствие такового. Часть методов, которые называют альтернативой тяжеловесным технологиям РМВОК, на самом деле в этом своде знаний описаны. Наиболее яркий пример — подход «ускоренная спиральная разработка прототипов». И хотя гибкие методологии довольно эффективны в работе небольших команд над несложными системами программного обеспечения, я считаю, что в отношении масштабных проектов они играют скорее вспомогательную роль и не заменяют комплексных подходов, описанных в РМВОК и ОРМ3.
Приведу несколько соображений насчет «гибкого» управления в ситуации, когда требования определены не четко. Во-первых, такие стандарты, как РМВОК и ОРМ3, не требуют досконального соблюдения всех своих предписаний абсолютно во всех проектах в каждой организации. Это некое меню, из которого можно выбирать и которое можно адаптировать к нуждам конкретной компании. Да, люди склонны применять подобные стандарты буквально и целиком, увязая в деталях, но проблема-то при этом не в стандарте, а в его использовании. К счастью, уже в самом начале карьеры я научился легко адаптировать такие стандарты к конкретным проектам, указывая в каждом плане проекта те процедуры, которые применимы в данном случае. Я понял, как использовать проверочные списки, чтобы быстро отбирать самое необходимое для конкретного проекта. В небольших, краткосрочных и малобюджетных проектах особые формальности не нужны и требуются очень простые приемы планирования и коммуникации. Проекты крупные, длительные, дорогие, с вовлечением большого количества подразделений и организаций должны быть более формализованы, тщательнее спланированы и строже контролируемы.
Во-вторых, бывают проекты, задачу которых при запуске невозможно сформулировать целиком и полностью. К ним относятся многие проекты в сфере информационных технологий. Во многих случаях детали того, что предстоит сделать, в самом начале неясны, например при ремонте, техобслуживании или разработке нового лекарства. В таких проектах результаты первых шагов могут изменить последовательность дальнейших действий, и к подобным ситуациям наилучшим образом подходит планирование методом «набегающей волны». Вы детально планируете лишь то, что можете окинуть взором в данный момент с имеющейся у вас информацией и при существующих исходных установках, и уже в самом плане предусматриваете действия по его пересмотру при поступлении новых данных. Некоторые компании применяют данный подход при создании планов долгосрочных программ, когда не известны подробности более поздних этапов и нет четких прогнозов относительно финальных стадий программы. В самой программе запланирован ряд проектов по внесению существенных изменений в общий план. Это пример работы тезиса бережливого производства об устранении потерь, в данном случае — потерь времени на ненужное предварительное планирование.
Для контроля за происходящими переменами, в том числе для уточнения исходных условий во всех проектах должен существовать эффективный процесс управления изменениями. Управление изменениями — ключевая составляющая гибкого управления проектами. Управлению изменениями посвящены особые разделы РМВОК. Менеджеры ИТ-проектов часто жалуются на непрерывные неконтролируемые корректировки проектного задания — на «сдвиг содержания» (scope creep). Я им объясняю, что в моих проектах все корректировки задания контролируются и что, на мой взгляд, потеря контроля — это проблема, которая связана с неопытностью самого менеджера, не использующего эффективные методы управления изменениями. Многие сами признают это, объясняя бесконтрольность сложившейся ситуации тем, что при запуске проекта не были определены должным образом исходные установки и границы содержания или со всеми вовлеченными сторонами не были оговорены соответствующие важные процедуры. В дальнейшем, начав контролировать изменения, менеджеры замечают, что проекты, к их удивлению, становятся более управляемыми и появляется возможность успешно завершать их в срок.
И наконец, выполнение проектов в максимально короткие сроки сокращает общие потери, в частности потери, вызываемые происшедшими изменениями, которые воздействуют не только на планы, но и на ранее достигнутые результаты. ССРМ способствует большей гибкости проектных организаций в их реакции на изменяющиеся потребности и служит дополнением ко всем гибким методологиям.
2.4. Шесть сигм
Существует несколько подходов к управлению качеством.
Концепция шести сигм была разработана в компании Motorola, но приобрела известность благодаря General Electric. Она дополняет принципы всеобщего управления на основе качества TQM.
Премия Малкольма Болдриджа в США[8] — признание высочайших достижений в бизнесе. Изначально она базировалась на TQM, но сейчас границы ее расширяются.
ISO 9000 — международный стандарт качества, внедренный многими компаниями. На сайте премии Малкольма Болдриджа [9] приводится сравнение данных подходов:
• концентрируются на измерении качества продукции и совершенствовании проектирования самих процессов;
• призывают к улучшению всех процессов и сокращению расходов.
Сертификация по 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-м вновь наблюдался рост.
Название «шесть сигм»[9] связано с долгосрочной целью компаний радикально сократить количество брака. При подходе «шесть сигм» измеряемая характеристика готовой продукции — среднее значение показателя ± 6 сигм от среднего показателя — должна, по замыслу, полностью укладываться в допуски, определенные требованиями клиента. При соблюдении границ «шести сигм» на миллион единиц готовой продукции будет лишь 3,4 единицы с дефектом (при данном подходе допускается отклонение среднего значения от целевого на ± 1,5 сигмы). Сигма — это статистическая единица стандартного отклонения по процессу. В концепции шести сигм вариабельность — это зло, с которым следует бороться.
Разработчики метода «шести сигм», базируясь на Деминговском цикле PDCA (Plan — планируй, Do — делай, Check — проверяй, Act — внедряй), модернизировали его, получив в итоге цикл DMAIC (Define — определяй, Measure — измеряй, Analyze — проанализируй, Improve — совершенствуй, Control — контролируй). В данном подходе широко применяется теория вариабельности и статистические методы — основное, на чем мы сосредоточимся, говоря о ССРМ. Однако ТОС, также используя статистические приемы, предлагает упрощенные варианты решения для бизнеса, в то время как шесть сигм склонны к полноценному использованию статистических методов. Шесть сигм могут стать хорошим дополнением к ССРМ, если вы будете избегать субоптимизации отдельно взятых процессов и сфокусируетесь на максимальном использовании возможностей ограничения системы.
Концепция шести сигм была разработана в компании Motorola, но приобрела известность благодаря General Electric. Она дополняет принципы всеобщего управления на основе качества TQM.
Премия Малкольма Болдриджа в США[8] — признание высочайших достижений в бизнесе. Изначально она базировалась на 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-м вновь наблюдался рост.
Название «шесть сигм»[9] связано с долгосрочной целью компаний радикально сократить количество брака. При подходе «шесть сигм» измеряемая характеристика готовой продукции — среднее значение показателя ± 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 показаны взаимосвязи четырех элементов. В следующих разделах мы посмотрим, как все это соотносится с системой управления проектом.
Впоследствии все методы, в действенность которых он верил, Деминг собрал воедино и назвал «системой глубинных знаний» [13]. Он определил эту систему как своего рода увеличительное стекло и карту, которые помогут понять и оптимизировать работу организации. Деминг подчеркивал, что глубинные знания представляют собой систему, у которой есть цель и составные части которой взаимосвязаны. Он выделил четыре компонента, отметив, что их нельзя рассматривать изолированно:
1. понимание системы;
2. знания по теории вариабельности;
3. теория познания;
4. психология.
На рис. 2.3 показаны взаимосвязи четырех элементов. В следующих разделах мы посмотрим, как все это соотносится с системой управления проектом.
2.5.1. Понимание системы
У каждой системы должна быть цель или задача. Это предназначение системы, определяющее ее границы. Сама по себе система — это сеть взаимозависимых компонентов, которые взаимодействуют, чтобы достичь цели системы. Цель коммерческих бизнес-систем — делать деньги сейчас и в будущем, вот почему люди инвестируют в такие предприятия. У организаций некоммерческих (или по крайней мере задумывавшихся как некоммерческие) другие цели: например, у учреждений здравоохранения — улучшение здоровья, у некоторых социальных институтов — обеспечение благосостояния семьи. Цель проектов уже была описана ранее: произвести уникальный продукт или услугу, соответствующие пожеланиям клиента, вовремя и в рамках запланированного бюджета. Заказчик при этом может соотносить результаты реализации проекта с более широкими целями организации, которую он представляет.
Система проекта включает в себя материальные объекты, людей, а также нематериальные сущности, такие как политики, знания, взаимоотношения. Все эти составляющие в разной степени взаимосвязаны и могут влиять на работу системы в целом. Процессы планирования и контроля также являются частью системы проекта. И выполнение работ командой проекта — тоже часть этой системы.
На систему могут воздействовать внешние факторы. Бизнес-системы являются открытыми, то есть обмениваются энергией и материальными объектами с внешним миром. То же относится и к системе проекта. Объекты, находящиеся как внутри, так и вне системы, то есть люди, политики, капитал, могут на нее воздействовать. Например, законы и нормативные акты, являющиеся факторами внешними по отношению к проектным и бизнес-системам, могут оказать значительное воздействие на их работу.
В 1950 году в Японии Деминг начертил схемку, подобную приведенной на рис. 2.4. Он в значительной степени связывал последовавший затем успех послевоенной Японии с мыслью, выраженной на данном рисунке. Описание бизнес-системы Деминг начинает с представления возможных товаров или услуг для потребителей. Это помогает спрогнозировать возможный спрос, пожелания и потребности заказчика. Подобные прогнозы обуславливают дизайн товара/услуги и позволяют продумать методы проверки соответствия продукции требованиям заказчиков перед запуском в массовое производство. Реальные отзывы клиентов — ключевой фактор, движущий развитием организации.
Так же работает система проекта. Заказчики сообщают, чего они ждут от проекта. Команда готовит план достижения заданных результатов. По плану различные подразделения компании, закупленное сырье и услуги объединяются, интегрируются в различных комбинациях для производства желаемого продукта. Налаженная система управления проектами может обеспечить выполнение большого числа разнообразных проектов, так же как налаженная производственная система может обеспечить выпуск большого количества разнообразных товаров или услуг. И хотя результат каждого проекта является уникальным, все же запланированное появление этих результатов обусловлено работой одной и той же системы.
Деминг понимал динамическую природу систем. Он заметил, что процесс, изображенный на схеме, требует, чтобы материал и информация, поступающие из различных частей системы, соответствовали тому, что требуется на следующем этапе. Деминг подчеркивал, что определение системы должно включать и формирование будущего самой системы. Он также ссылался на понятия, рассматриваемые далее.
Система проекта включает в себя материальные объекты, людей, а также нематериальные сущности, такие как политики, знания, взаимоотношения. Все эти составляющие в разной степени взаимосвязаны и могут влиять на работу системы в целом. Процессы планирования и контроля также являются частью системы проекта. И выполнение работ командой проекта — тоже часть этой системы.
На систему могут воздействовать внешние факторы. Бизнес-системы являются открытыми, то есть обмениваются энергией и материальными объектами с внешним миром. То же относится и к системе проекта. Объекты, находящиеся как внутри, так и вне системы, то есть люди, политики, капитал, могут на нее воздействовать. Например, законы и нормативные акты, являющиеся факторами внешними по отношению к проектным и бизнес-системам, могут оказать значительное воздействие на их работу.
В 1950 году в Японии Деминг начертил схемку, подобную приведенной на рис. 2.4. Он в значительной степени связывал последовавший затем успех послевоенной Японии с мыслью, выраженной на данном рисунке. Описание бизнес-системы Деминг начинает с представления возможных товаров или услуг для потребителей. Это помогает спрогнозировать возможный спрос, пожелания и потребности заказчика. Подобные прогнозы обуславливают дизайн товара/услуги и позволяют продумать методы проверки соответствия продукции требованиям заказчиков перед запуском в массовое производство. Реальные отзывы клиентов — ключевой фактор, движущий развитием организации.
Так же работает система проекта. Заказчики сообщают, чего они ждут от проекта. Команда готовит план достижения заданных результатов. По плану различные подразделения компании, закупленное сырье и услуги объединяются, интегрируются в различных комбинациях для производства желаемого продукта. Налаженная система управления проектами может обеспечить выполнение большого числа разнообразных проектов, так же как налаженная производственная система может обеспечить выпуск большого количества разнообразных товаров или услуг. И хотя результат каждого проекта является уникальным, все же запланированное появление этих результатов обусловлено работой одной и той же системы.
Деминг понимал динамическую природу систем. Он заметил, что процесс, изображенный на схеме, требует, чтобы материал и информация, поступающие из различных частей системы, соответствовали тому, что требуется на следующем этапе. Деминг подчеркивал, что определение системы должно включать и формирование будущего самой системы. Он также ссылался на понятия, рассматриваемые далее.
2.5.1.1. Системная динамика
Питер Сенге [14] характеризует сущность дисциплины системного мышления через:
• видение сложных взаимосвязей, а не просто линейной причинно-следственной цепочки;
• видение процесса изменений, а не только среза действительности в конкретный момент.
Его «законы пятой дисциплины» суммируют и демонстрируют принципы существования динамических систем (включая проекты).
1. Сегодняшние проблемы рождаются из вчерашних «решений». Руководство было недовольно графиком последнего проекта и сократило длительность отдельных работ. В следующий раз им захочется сократить людей.
2. Чем больше давление на систему, тем больше ее сопротивление. Руководство стремится увеличить производительность тем, что раздает исполнителям сразу множество проектных задач. Наличие нескольких заданий означает увеличение длительности выполнения большинства из них, так как одновременно человек может заниматься лишь чем-то одним (человек не многозадачная машина). Во время решения одной задачи остальные остаются нетронутыми. Время реализации каждого проекта в системе становится все больше, производительность всей системы — все меньше.
• видение сложных взаимосвязей, а не просто линейной причинно-следственной цепочки;
• видение процесса изменений, а не только среза действительности в конкретный момент.
Его «законы пятой дисциплины» суммируют и демонстрируют принципы существования динамических систем (включая проекты).
1. Сегодняшние проблемы рождаются из вчерашних «решений». Руководство было недовольно графиком последнего проекта и сократило длительность отдельных работ. В следующий раз им захочется сократить людей.
2. Чем больше давление на систему, тем больше ее сопротивление. Руководство стремится увеличить производительность тем, что раздает исполнителям сразу множество проектных задач. Наличие нескольких заданий означает увеличение длительности выполнения большинства из них, так как одновременно человек может заниматься лишь чем-то одним (человек не многозадачная машина). Во время решения одной задачи остальные остаются нетронутыми. Время реализации каждого проекта в системе становится все больше, производительность всей системы — все меньше.