Главная

Статьи

Библиотека статей

Организационное проектирование

Как управляют проектами

Станислав Турчин

Помимо предприятий c серийным производством, существуют организации, которые выполняют единичные, как правило, неординарные заказы. Одни изготовляют продукцию (строительство, авиа- и судостроение, разработка ПО и т. д.), другие занимаются оказанием услуг (организация выставок, системная интеграция, внедрение АСУП, проведение рекламных кампаний и пр.). И хотя результаты их деятельности различны, но сам процесс производства имеет много общего: и те и другие реализуют проекты. От серийного производства проект отличается тем, что является однократной, а не циклической деятельностью. Методики планирования ресурсов, используемые в проектах, имеют общие корни с теми, что применяются для серийного производства, но существенно отличаются по форме и содержанию. Это обусловлено именно однократностью и уникальностью проектов.

История развития

История методик управления проектами насчитывает пять тысяч (!!!) лет. Это не шутка. Результаты одних проектов мы с вами видим до сих пор (египетские пирамиды и ирригационные каналы, Великая китайская стена), а о других можем судить лишь по описаниям современников (военные походы Чингиз-хана и Александра Македонского, морские экспедиции Колумба и Магеллана). Сегодня существуют серьезные научные работы, посвященные методам управления проектами, которые применяли древние египтяне при строительстве пирамид и викинги, когда проводили военные операции. Вот, где приходит на ум пословица "Все новое -- это хорошо забытое старое"…
Современные методы управления проектами уходят корнями в 50-е годы текущего столетия. Практически одновременно две проектные группы представили методы управления сложными комплексами работ.
Компании Du Pont и Remington Rand предложили метод, который получил название Метод критического пути (Critical Path Method -- CPM). Он появился в процессе планирования работ по модернизации заводов фирмы Du Pont.
Независимо от них в военно-морских силах США был создан метод для анализа и оценки длительности выполнения работ (Program Evaluation And Review Technique -- PERT). Его разработали корпорация Lockheed Air Craft, консалтинговая компания Booz, Allen & Hamilton и особое проектное бюро ВМС США в процессе создания ракетного комплекса Polaris. Благодаря PERT проект, который состоял из 60 тыс. операций и объединял около 3800 основных подрядчиков, удалось закончить на два года раньше запланированного срока. Его успешное завершение способствовало тому, что вскоре данный метод стал повсеместно применяться для планирования проектов в вооруженных силах США.
Оба метода были основаны на использовании сетевых диаграмм, но CPM оперировал только одной длительностью работы, в то время как PERT учитывал четыре длительности -- оптимистическую, пессимистическую, наиболее вероятную и средневзвешенную. Это обусловлено различными сферами применения методов.

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

За прошедшее время произошла взаимная интеграция методов, и сейчас при планировании в основном используется Метод критического пути.

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

Современные стандарты

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

Данные стандарты представляют собой свод знаний об управлении проектами (Project Management Body of Knowledge -- PMBOK). Но структура и содержание PMBOK в разных странах может отличаться в связи с тем, что многие национальные ассоциации управления проектами имеют неодинаковые точки зрения на то, что именно должно входить в этот документ. Поэтому, чтобы не было разночтений, необходимо определиться с терминологией.

Дальше в тексте структура управления проектами и все английские названия приведены согласно Guide to PMBOK, разработанным Американским институтом управления проектами (Project Management Institute -- PMI). Русские названия даны в соответствии с книгой В. М. Либерзона (директор PMI в России), которая распространяется в виде хелп-файла с демо-версией программы Spider Project. Эти источники выбраны потому, что они доступны бесплатно (оба документа можно загрузить с сайта www.pmi.ru). Кроме того, украинское издание этой книги можно приобрести в Украинской ассоциации управления проектами (uutba@carrier.kiev.ua).

Функциональная структура управления проектами включает в себя девять разделов.

1. Управление координацией (Project Integration Management).
2. Управление целями (Project Scope Management).
3. Управление временем (Project Time Management).
4. Управление стоимостью (Project Cost Management).
5. Управление качеством (Project Quality Management).
6. Управление человеческими ресурсами (Project Human Resource Management).
7. Управление коммуникациями (Project Communication Management).
8. Управление рисками (Project Risk Management).
9. Управление поставками (Project Procurement Management).

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

1. Процессы инициации (Initiating Processes) -- принятие решения о начале проекта или его фазы.
2. Процессы планирования (Planning Processes) -- определение рабочих схем достижения целей проекта.
3. Процессы исполнения (Executing Processes) -- координация людей и других ресурсов во время выполнения проекта.
4. Процессы управления (Controlling Processes) -- наблюдение и измерение результатов выполнения проекта и внесение необходимых коррективов.
5. Процессы завершения (Closing Processes) -- оформление завершения проекта или его фазы.

Рассказать в рамках одной статьи о всех процессах в управлении проектом-- задача не из легких, поэтому мы детально остановимся на самом трудоемком и длительном -- процессе планирования, который по своей сути идентичен MRP II (" Компьютерное Обозрение", # 20, 2000)

От бизнес-плана -- к производственному графику

Структура процесса планирования изображена на рисунке, а ниже представлено содержание этапов.

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

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

Декомпозиция целей (Scope Definition). Последовательное деление основных результатов проекта на более мелкие элементы, вплоть до пакетов работ, хорошо поддающихся управлению. В итоге получается иерархическая структура (дерево) работ проекта (Work Breakdown Structure -- WBS).

Определение операций (Activity Definition). Определение перечня элементарных операций (activity), которые должны быть выполнены для достижения результатов, описанных в WBS.

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

Определение взаимосвязи операций (Activity Sequencing). Определение последовательности проведения работ в проекте с учетом технологических, организационных и других ограничений. Одни работы могут выполняться параллельно, другие же, напротив, могут начаться не раньше, чем завершатся предшествующие. Результатом этого этапа является сетевая диаграмма (project network diagram), которая показывает логическую взаимосвязь между работами в проекте (часто ее некорректно называют PERT-диаграммой).

Оценка длительности операций (Activity Duration Estimating). Определение количества рабочего времени, которое необходимо для выполнения каждой элементарной операции. Расчет времени производится на основании экспертных оценок и моделирования (метод Монте-Карло). Учитываются ресурсные и другие ограничения.

Оценка стоимости (Cost Estimating). Определение стоимости ресурсов, необходимых для выполнения проекта. Рассматриваются различные ценовые альтернативы. В результате разрабатывается план управления стоимостью проекта, для того чтобы она не вышла за рамки ограничений.

Составление расписания (Schedule Development). Определение дат старта и финиша для всех работ проекта. Оцениваются реалистичность расписания (project schedule), загрузка ресурсов и их влияние на срок выполнения проекта.

Разработка бюджета (Cost Budgeting). Определение базисной линии стоимости проекта, называемой S-кривой из-за ее сходства с латинской буквой S. Базисная линия показывает распределение во времени (нарастающим итогом) расходов на проект и служит для сравнения текущих результатов с плановыми.

Разработка плана проекта (Project Plan Development). Создание итогового структурированного документа на основании данных, полученных на предыдущих этапах планирования. Результатом является план проекта, который служит руководством для исполнения и управления им.

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

Информационные системы

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

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

На рынке этот сегмент ПО представлен как специализированными КСП-системами, так и КСП-модулями в составе комплексных АСУП.

По функциональным возможностям все КСП-системы можно условно разделить на две категории: для использования профессиональными менеджерами проектов и теми руководителями, которым приходится планировать проекты время от времени.

Это деление весьма условно. Мощность даже "непрофессиональных" КСП-систем (стоимостью от $300 до $1000) позволяет строить расписания, состоящие из десятков тыс. (!!!) работ, моделировать группы проектов, планировать неограниченное количество ресурсов, да и вообще использовать практически все функции, необходимые для успешного управления проектом. Главные отличия, как всегда, заключаются в нюансах.

Функциональные возможности систем для календарно-сетевого планирования

Давайте постараемся провести границу между системами для подготовки документов. Можно составлять 100-страничный документ в блокноте (NotePad), но в специализированном текстовом редакторе это делать значительно удобнее. Более того, он уже позволяет даже верстать книги, но в специализированной системе для допечатной подготовки это делать существенно проще. Так и профессиональные, так называемые high-end, КСП-системы (стоимостью от 4 тыс. долл.) приходят на помощь тогда, когда речь идет о больших проектах, гибком ресурсном планировании, детальном анализе рисков и т. д.

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

Японский подход к управлению проектами

На Международном симпозиуме по управлению проектами СОВНЕТ’99 представитель компании Chiyoda сделал доклад об использовании систем трехмерного моделирования (3-DMS) в управлении проектами. В принципе, возможности интеграции 3-DMS и КСП-систем уже используются некоторыми фирмами. Так, компания Primavera предлагает интеграцию своей КСП-системы с САПР для более наглядного представления проекта.

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

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

Система позволяет отвечать на такие вопросы, как, например:

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

• Как лучше складировать строительные материалы, чтобы не пересекались транспортные потоки?

• Сможет ли рабочий среднего роста дотянуться до вентиля трубопровода?

Головной офис Chiyoda находится в Японии, а строительные работы она ведет в Саудовской Аравии. Отказ от использования бумажных документов и возможностей, предоставляемых спутниковыми каналами связи, позволили компании организовать непрерывный обмен данными между головным офисом и строительной площадкой. Раньше на пересылку бумажных чертежей уходило более пяти дней…

Неудивительно, что докладчику пришлось выступать дважды -- второй раз "на бис".

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

Версия для печати  |  Пользовательское соглашение