Системы управления предприятием. ГЛАВА 1. УПРАВЛЕНИЕ ПРОЕКТАМИ (Ю. А. Зубарев, 2010)

1.1.1. Введение в проектный менеджмент

Проект

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

1. они направлены на достижение конкретных целей;

2. они включают в себя координированное выполнение взаимосвязанных действий;

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

4. все они в определенной степени неповторимы и уникальны.

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

Направленность на достижение целей

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

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

Координированное выполнение взаимосвязанных действий

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

Ограниченная протяженность во времени

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

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

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

Уникальность

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

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

Управление проектом

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

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

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

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

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

Немного истории …

В основе методов управления проектами лежат методики сетевого планирования, разработанные в конце 50-х годов в США. В 1956 г. М.Уолкер из фирмы "Дюпон", исследуя возможности более эффективного использования принадлежащей фирме вычислительной машины Univac, объединил свои усилия с Д. Келли из группы планирования капитального строительства фирмы "Ремингтон Рэнд". Они попытались использовать ЭВМ для составления планов-графиков крупных комплексов работ по модернизации заводов фирмы "Дюпон". В результате был создан рациональный и простой метод описания проекта с использованием ЭВМ. Первоначально он был назван методом Уолкера-Келли, а позже получил название Метода Критического Пути – МКП (или CPM – Critical Path Method). Параллельно и независимо в военно-морских силах США был создан метод анализа и оценки программ PERT (Program Evaluation and Review Technique). Данный метод был разработан корпорацией "Локхид" и консалтинговой фирмой "Буз, Аллен энд Гамильтон" для реализации проекта разработки ракетной системы "Поларис", объединяющего около 3800 основных подрядчиков и состоящего из 60 тыс. операций. Использование метода PERT позволило руководству программы точно знать, что требуется делать в каждый момент времени и кто именно должен это делать, а также вероятность своевременного завершения отдельных операций. Руководство программой оказалось настолько успешным, что проект удалось завершить на два года раньше запланированного срока. Благодаря такому успешному началу данный метод управления вскоре стал использоваться для планирования проектов во всех вооруженных силах США. Методика отлично себя зарекомендовала при координации работ, выполняемых различными подрядчиками в рамках крупных проектов по разработке новых видов вооружения.

Крупные промышленные корпорации начали применение подобной методики управления практически одновременно с военными для разработки новых видов продукции и модернизации производства. Широкое применение методика планирования работ на основе проекта получила в строительстве. Например, для управления проектом сооружения гидроэлектростанции на реке Черчилль в Ньюфаундленде (полуостров Лабрадор). Стоимость проекта составила 950 млн. долларов. Гидроэлектростанция строилась с 1967 по 1976 г. Этот проект включал более 100 строительных контрактов, причем стоимость некоторых из них достигала 76 млн. долларов. В 1974 году ход работ по проекту опережал расписание на 18 месяцев и укладывался в плановую оценку затрат. Заказчиком проекта была корпорация Churchill Falls Labrador Corp., которая для разработки проекта и управления строительством наняла фирму Acress Canadian Betchel.

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

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

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

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

В настоящее время в США уже сложились глубокие традиции использования систем управления проектами во многих областях жизнедеятельности. Причем, основную долю среди планируемых проектов составляют небольшие по размерам проекты. Например, исследования, проведенные еженедельником InfoWorld , показали, что пятидесяти процентам пользователей в США требуются системы, позволяющие поддерживать планы, состоящие из 500 – 1,000 работ и только 28 процентов пользователей разрабатывают расписания, содержащие более 1,000 работ. Что касается ресурсов, то 38 процентам пользователей приходится управлять 50 – 100 видами ресурсов в рамках проекта, и только 28 процентам пользователей требуется контролировать более чем 100 видов ресурсов. В результате исследований были определены также средние размеры расписаний проектов: для малых проектов – 81 работа и 14 видов ресурсов, для средних – 417 работ и 47 видов ресурсов, для крупных проектов – 1,198 работ и 165 видов ресурсов. Данные цифры могут служить отправной точкой для менеджера, обдумывающего полезность перехода на проектную форму управления деятельностью собственной организации. Как видим, применение системы управления проектами на практике может быть эффективным и для очень небольших проектов.

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

Жизненный цикл проекта

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

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

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

Определяющим показателем здесь является альтернативная стоимость инвестиций. Иными словами, выбирая проект "А", а не проект "В", организация отказывается от выгод, которые мог бы принести проект "В".

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

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

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

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

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

1.1.2. Финансовое управление по проектам

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

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

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

Личный опыт

Свейн Оге Ольсен, главный финансовый директор ОАО «Аптечная сеть 36,6» (Москва). В процессе стратегического развития компании мы выделили два типа проектной деятельности – программы и проекты. К программам относятся направления, представляющие собой совокупности повторяющихся типовых проектов, к примеру, программа открытия аптек, внутри которой существуют типовые проекты открытия торговых точек. В отдельные проекты выделяются разовые начинания, такие как введение в ассортимент новых товарных категорий (например, оптики), изменение стандарта оформления аптек, внедрение IT-систем и т. д.

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

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

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

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

Пример 1

В компании существует типовая задача открытия нового магазина. Ранее на ее решение уходило четыре месяца, а после начала использования проектного подхода и при жестком соблюдении сроков – три. В этом случае компания получит дополнительную прибыль от более раннего запуска магазина. При рентабельности в 10 % и планируемом объеме продаж в первом месяце в 500 тыс. руб. дополнительная прибыль от сокращения сроков запуска магазина на один месяц составит 50 тыс. руб.

Аналогичная ситуация и с бюджетами проектов и качеством исполнения работ. Здесь возможны две ошибки: недооценка будущих расходов и прямые потери, связанные с ошибочными действиями. Средняя стоимость подобных ошибок обычно составляет 10-20 % от бюджета проекта. К основным качественным преимуществам использования СУП в рамках компании относятся:

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

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

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

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

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

Эффективность внедрения

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

Личный опыт

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

Рис. 1.1.1. Эффективность использования СУП

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

Место проектной деятельности в работе компании

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

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

Рис. 1.1.2. Варианты присутствия проектной деятельности в деятельности компании

Этапы внедрения СУП

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

Этап 1. Изменение оргструктуры

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

К функциям проектного офиса относят:

• ведение электронных моделей проектов;

• ведение архивов проектов;

• контроль реализации проектов;

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

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

• ведение баз данных характеристик типовых работ и их фрагментов по проектам и потребностей в ресурсах;

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

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

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

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

Личный опыт

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

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

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

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

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

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

Этап 2. Разработка нормативной документации

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

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

• классификация проектов и критерии выделения отдельных начинаний в проект;

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

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

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

• развитию ассортимента;

• развитию каналов сбыта;

• развитию производства;

• развитию обеспечивающих подразделений;

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

• диверсификации бизнеса.

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

• развитие ассортимента;

• развитие сбытовой сети;

• развитие способов продвижения;

• развитие логистики; б) производственные:

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

• создание новых производственных площадок;

• улучшение производственного процесса; в) обеспечивающие:

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

• реорганизация бизнес-процессов;

• повышение эффективности работы вспомогательных подразделений.

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

Следующим шагом является описание бизнес-процесса прохождения проекта в компании. Пример схематичного представления бизнес-процесса приведен на рис. 1.1.3.

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

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

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

• в разработке;

• к запуску;

• запущенный;

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

• завершенный;

• отклоненный;

• отложенный.

Рис. 5.1.3.. Упрощенный пример описания бизнес-процесса прохождения проекта

Изменение статуса проекта происходит после рассмотрения его на инвестиционном комитете на основании принятых в компании граничных условий. Например, к исполнению принимается проект, срок окупаемости которого не менее трех лет, значение IRR – не ниже 25 % и т. д. Если показатели проекта значительно превосходят указанные, то ему присваивается статус «к запуску», если они близки к граничным или меньше их, то статус – «отложенный», если проект был отклонен, то он передается в архив со статусом «отклоненный», а в случае отправки проекта на доработку статус не меняется.

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

Этап 3. Автоматизация

Несмотря на то, что выбору программного продукта для автоматизации СУП посвящено огромное количество статей, на практике следует руководствоваться реальными потребностями компании. Так для крупной строительной организации, которой необходим полноценный учет материалов, посменная работа и т. п., нужна система профессионального уровня (Primavera Enterprise, Spider Project). Для компании поменьше подойдут Microsoft Project и OpenPlan Pro. Они обладают богатыми возможностями групповой работы: создание единого пула ресурсов, доступ к проектам через web-интерфейс, интеграция с почтовыми и учетными программами. В России также существуют системы, реализующие функции бюджетирования и управленческого учета по проектам и автоматизирующие документооборот (ТУ «Управление проектами» на базе «1С:Пред-приятие 8.0»). Однако они не являются полноценной заменой автоматизированной СУП, так как не предназначены для оптимизации расписаний проектов и управления ресурсами по проектам.

Минимальные требования, которым должна удовлетворять автоматизированная система управления проектами (включая адаптированный для этой цели MS Excel), следующие:

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

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

• оптимизация полученного плана-графика работ с учетом и без учета ограничений по ресурсам;

• оценка рисков изменения плана-графика работ;

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

• подготовка отчетов на основе планов и фактов работ.

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

Изменения в управлении финансами

Для финансового директора при постановке СУП наиболее важным вопросом будет описание порядка управления стоимостью и денежными потоками проекта. Введение этих процедур подразумевает изменение существующих правил бюджетирования и проведения платежей. Чаще всего совокупность проектов компании выделяется в отдельный ЦФУ «Инвестиционная деятельность» или «Проектный центр». Бюджеты ЦФУ консолидируются в бюджет всей компании, как если бы это было отдельное подразделение. Внутри ЦФУ для каждого проекта также ведется полный набор бюджетов.

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

Однако выделить в отдельный проект только дополнительный объем продукции проблематично. Поэтому с начала реализации проекта весь цех переводится из основной деятельности в инвестиционную, а оценка стоимости цеха производится так, как если бы это было отдельное предприятие. По ЦФУ, к которому раньше относился цех, начисляется доход в размере стоимости цеха, по ЦФУ «Инвестиционная деятельность» – расход в размере той же суммы. После реализации проекта производится обратная операция. При этом сумма добавочной стоимости, создаваемой цехом, может оставаться в ЦФУ «Инвестиционная деятельность», а может и перейти в первоначальный ЦФУ.

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

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

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

Пример 2

Предположим, что на месяц было запланировано десять работ с бюджетом 12 тыс. долл. США. По итогам месяца оказалось, что освоенный бюджет составил 5 тыс. долл. США. Однако после проведения факторного анализа выяснилось, что четыре работы с бюджетом 8 тыс. долл. США были отложены до следующего месяца и появилась новая работа стоимостью 300 долл. США. Видно, что по изначально запланированным работам бюджет составлял 4 тыс. долл. США (12 тыс. минус 8 тыс.), а с учетом новой работы сумма составит 4,3 тыс. долл. США. Таким образом, превышение бюджета за счет удорожания составило 700 долл. США. Общее отклонение бюджета в 7 тыс. долл. США раскладывается на отклонение по стоимости плюс 0,7 тыс. долл. США, и отклонение по составу работ минус 7,7 тыс. долл. США (8 тыс. минус 0,3 тыс.). Еще одной сложностью является то, что план-график работ по проекту подвержен постоянным корректировкам, а это приводит к смещению сроков платежей и оплат, относимых в бюджете к единичному месяцу. Поэтому, если в рамках месячного бюджета еще можно добиться приемлемой точности планирования, то годовой бюджет будет устаревать через два-три месяца. В этой ситуации стоит подумать о введении в компании скользящего бюджета, пересматриваемого с определенной периодичностью.

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

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

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

Мнение консультанта

Григорий Ципес, главный консультант по управлению проектами компании IBS.

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

Сопротивление персонала

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

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

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

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

Мнение консультанта

Мы видим три основных пути преодоления сопротивления персонала при внедрении системы управления проектами – агитация, принуждение и мотивация.

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

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

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

1.1.3. Классические камни преткновения при осуществлении управления

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

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

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

Третьим камнем преткновения являются сроки исполнения. Хотя в начале работы кажется, будто все время мира в вашем распоряжении и что некоторые задержки легко наверстываются. Это однако часто удается лишь к концу проекта, с существенно большими затратами, или проект на какое-то время вообще полностью выходит за свои временные рамки. Это объясняется различными причинами: во-первых, не достаточно ясно сформулированные цели являются плохой основой для оценки трудовых и временных затрат. Отрицательно сказывается также и отсутствие анализа рисков. Во-вторых, большая часть сотрудников исходит из того, что для исполнения проекта предусмотрены достаточные временные ресурсы, "поскольку нельзя же самому себе без особой нужды осложнять жизнь". Поэтому цели проекта по началу воспринимаются многими скорее как игровой азарт, а не серьезная рабочая задача. Эта вера в достаточный запас времени в сочетании с убежденностью в собственной способности "как-то удержать ситуацию под контролем" часто приводят к значительным просчётам и роковым последствиям для сроков исполнения проекта. В-третьих, руководители проектов часто неосознанно способствуют этому фактору, измеряя возможности сотрудников мерой собственной производительности. Поскольку же они часто за меньшее время в состоянии сделать больше, чем сотрудники, это приводит к просчетам в планировании затрат времени и укрепляет сотрудников в их переоценке собственных возможностей.

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

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

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

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

В конце 50-х годов в США для осуществления программы исследовательских и конструкторских работ по созданию ракеты “Поларис” впервые был использован метод планирования и управления, основанный на идее определения, оценки вероятных сроков и контроля так называемого “критического пути” всего комплекса работ. Результаты превзошли все ожидания: во-первых, заметно уменьшилось число сбоев в работе из-за несогласованности используемых ресурсов, резко сократилась общая продолжительность выполнения всего комплекса работ, получен огромный эффект из-за снижения суммарной потребности в ресурсах и, соответственно, уменьшения общей стоимости программы. Вскоре после того, как результаты выполнения программы “Поларис” стали достоянием общественности, весь мир заговорил о методе PERT (Project Evaluation and Review Technique) как о новом подходе к организации управления.

За прошедшее с тех пор время метод “критического пути” не только получил широкое применение в повседневной практике управления, но и обусловил появление специальной научно-прикладной дисциплины – управление проектами. В центре внимания этой дисциплины находятся вопросы планирования, организации, контроля и регулирования хода выполнения проектов, организации материально-технического, финансового и кадрового обеспечения проектов, оценки инвестиционной привлекательности различных вариантов реализации проектов.

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

1.2.1. Объект проектного управления

Термин проект, как известно, происходит от латинского слова projectus, что в буквальном переводе означает “брошенный вперед”. Таким образом, сразу становится ясно, объект управления, который можно представить в виде проекта, отличает возможность его перспективного развертывания, т.е. возможность предусмотреть его состояния в будущем. Хотя различные официальные источники трактуют понятие проекта поразному2 , во всех определениях четко просматриваются особенности проекта как объекта управления, обусловленные комплексностью задач и работ, четкой ориентацией этого комплекса на достижение определенных целей и ограничениями по времени, бюджету, материальным и трудовым ресурсам.

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

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

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

• достижение целей деятельности связано с последовательно- параллельным выполнением всех элементов этой деятельности;

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

• продолжительность и стоимость деятельности явно зависит от организации всего комплекса работ.

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

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

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

1.2.2. Теоретические основы проектного управления

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

В сетевой модели роль вершин графа могут играть события, определяющие начало и окончание отдельных работ, а дуги в этом случае будут соответствовать работам. Такую сетевую модель принято называть сетевой моделью с работами на дугах (Activities on Arrows, AoA). В то же время, возможно, что в сетевой модели роль вершин графа играют работы, а дуги отображают соответствие между окончанием одной работы и началом другой. Такую сетевую модель принято называть сетевой моделью с работами в узлах (Activities on Nodes, AoN).

Пусть множество A={a1, a2, a3, … an} – комплекс работ, выполнение которых требуется для решения определенной задачи, например, строительства дома. Тогда, если множество V={v1, v2, v3, … vm} будет представлять комплекс событий, возникающих в процессе выполнения комплекса работ, то сетевая модель будет задаваться ориентированным графом G=(V, A), в котором элементы множества V играют роль вершин, а элементы множества A – роль дуг, соединяющих вершины, причем каждой дуге ai можно поставить в однозначное соответствие пару вершин (vsi, vfi), первая из которых будет определять момент начала работы аi, а вторая – момент окончания этой работы. Такая сетевая модель будет сетевой моделью с работами на дугах.

Теперь пусть множество A={a1, a2, a3, … an} – по-прежнему будет рассматриваться как комплекс работ, выполнение которых требуется для решения определенной задачи, например, строительства дома. Тогда, если множество V={v1, v2, v3, … vm} будет представлять комплекс отношений предшествования-следования работ в процессе их выполнения, то сетевая модель будет задаваться ориентированным графом G=(A, V), в котором элементы множества A играют роль вершин, а элементы множества V – роль дуг, соединяющих вершины, причем каждой дуге vi можно поставить в однозначное соответствие пару вершин (asi, afi), первая из которых будет непосредственно предшествующей работой в данной паре, а вторая – непосредственно следующей. Такая сетевая модель будет сетевой моделью с работами в узлах.

Сетевая модель может быть представлена: 1) сетевым графиком, 2) в табличной форме, 3) в матричной форме, 4) в форме диаграммы на шкале времени. Как будет показано ниже, переход от одной формы представления к другой не составляет большого труда.

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

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

Сетевым графиком называется полное графическое отображение структуры сетевой модели на плоскости.

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

• событий – моментов времени, когда происходит начало или окончание выполнения какой-либо работы (работ);

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

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

Графически события изображаются кружками, разделенными на три равных сегмента (радиусами под углом в 120°); работы изображаются сплошными линиями со стрелками на конце, ориентированными слева направо; фиктивные работы изображаются пунктирными линиями со стрелками на конце, ориентированными слева направо. Пример сетевого графика модели АоА представлен ниже на рис. 1.2.1.

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

Рис. 1.2.1. Пример сетевого графика модели AoA

Если сетевым графиком отображается модель типа AoN, то избыточности структуры удается избежать. Здесь нет необходимости вводить в качестве дополнительного структурного элемента фиктивные работы, поскольку отсутствуют те структурные элементы, которые они призваны обслуживать, а именно – события. В сетевом графике модели типа AoN есть только узлы (или вершины), которые обозначают работы и дуги (сплошные линии со стрелками, ориентированными слева направо), которые обозначают отношения предшествования-следования работ. Никаких событий и никаких фиктивных работ! Заметим, что в наиболее известной программе по проектному управлению Microsoft Project реализуется этот тип модели.

Здесь узлы сети, соответствующие работам, принято изображать прямоугольниками, поделенными на 5 секторов. В центральном секторе проставляется индекс (или записывается наименование работы). Заполнение остальных секторов рассматривается ниже. Пример сетевого графика для модели типа AoN представлен ниже на рис. 1.2.2.

Рис. 1.2.2.Пример сетевого графика модели типа АоN.

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

Таблица 1.2.1. Табличная форма сетевой модели

Матричная форма описания сетевой модели задается в виде отношения между событиями (ei, ej), которое равно 1, если между этими событиями есть работа (либо реальная, либо фиктивная) и 0 – в противном случае. Матричная форма для описания сетевой модели из рассматриваемого выше примера приведена ниже в табл. 1.2.2.

Таблица 1.2.2. Матричная форма сетевой модели

Описание сетевой модели в форме временной диаграммы (или графика Ганта) предполагает размещение работ в координатной системе, где по оси абсцисс (X) откладывается время (t), а по оси ординат (Y) – работы. Точкой начала отсчета любой из работ будет момент окончания всех ее предшествующих работ. Если работе не предшествует ничто, то она откладывается от начала временной шкалы, т.е. с самого левого края диаграммы. На рис. 1.2.3 представлен график Ганта для сетевой модели по данным табл. 1.2.1 с добавлением информации о продолжительности выполнения работ.

Рис. 1.2.3. Диаграмма Ганта

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

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

Различаются следующие разновидности событий сетевого графика модели АоА:

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

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

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

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

• конечное событие – событие, непосредственно следующее за данной работой.

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

Различают следующие временные параметры:

• продолжительность работ;

• раннее время начала работы;

• раннее время окончания работы;

• позднее время начала работы;

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

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

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

• продолжительность критического пути;

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

• полный резерв времени выполнения работы;

• свободный резерв времени выполнения работы;

• независимый резерв времени выполнения работы.

Продолжительность работы (ti) – календарное время, которое занимает выполнение работы.

Раннее время начала работы (ESTi) – наиболее ранний из возможных сроков начала выполнения работы.

Раннее время окончания работы (EFTi) – равно раннему времени начала работы плюс ее продолжительность.

Позднее время окончания работы (LFTi) – наиболее поздний из допустимых сроков окончания работы.

Позднее время начала работы (LSTi) – равно позднему времени окончания работы минус ее продолжительность.

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

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

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

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

Работы, лежащие на критическом пути, называются критическими работами, а события – критическими событиями.

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

Резерв времени наступления события – это разница между поздним и ранним сроками наступления этого события.

Полный резерв времени выполнения работы (TFi) – это максимально возможный запас времени для выполнения данной работы сверх продолжительности самой работы при условии, что в результате такой задержки конечное для данной работы событие наступит не позднее, чем в свой поздний срок.

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

Независимый резерв времени выполнения работы (IFi) – это запас времени, на который можно отложить начало выполнения работы без риска повлиять на какие бы то ни было сроки наступления каких-либо событий в модели вообще.

Параметры раннего и позднего времени наступления события используются в маркировке вершин сетевого графика модели типа АоА. В левый сегмент записывается раннее время наступления соответствующего события (ЕETj), а в правый – позднее (LETj), что показано на рис 1.2.4.

Рис. 1.2.4.Пример маркировки времени наступления событий

В маркировке вершин сетевого графика модели типа AoN помимо индекса работ используются параметры (см. Рис. 1.2.5):

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

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

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

• полный резерв времени выполнения работы (TFi) – который записывается в правый нижний сектор прямоугольника, маркирующего вершину работы.

Рис.1.2.5. Пример маркировки вершин сетевого графика модели типа АоN

1.2.3. Методы расчета временных параметров и критического пути сетевой модели проекта

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

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

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

Рис. 1.2.6. Пример сетевого графика для иллюстрации методов расчета временных параметров

Конец ознакомительного фрагмента.