Международный экономический форум 2012

Каренов Р.С.

Задачи и методы структуризации проектов

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

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

Структура проекта призвана определить продукцию, которую необходимо разработать или произвести, и связывает элементы работы,
которые предстоит выполнить, — как между собой, так и с конечной
целью проекта [1; 98].

Суть структуризации проекта (WBS – Work Breakdown Structure) состоит в следующем: проект делится на поддающиеся управлению элементы работ, для которых легко определить затра­ты и построить графики исполнения. Должным образом подготов­ленная и составленная структура проекта должна удовлетворять требованиям менеджера проекта и заказчика. Структуризация про­екта помогает менеджеру наделить участников проекта ответствен­ностью за выполнение конкретных технических заданий. Она также позволяет создать простую систему отслеживания хода реа­лизации проекта [2; 56].

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

Основные задачи структуризации проекта

Применительно к реальным проектам структура разбивки проекта (рис. 1) должна сочетать разделение на: компоненты продукции; этапы жизненного цикла проекта; элементы организационной структуры.


Рисунок 1 – Структура разбивки применительно к реальным проектам

(Примечание – данные работы [2; 58])

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

Основными задачами структуризации проекта являются следующие [1; 98]:

– разбивка проекта на поддающиеся управлению блоки;

– распределение ответственности за различные элементы проекта и увязка работ со структурой организации (ресурсами);

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

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

– увязка работ по проекту с системой ведения бухгалтерских счетов в компании;

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

– определение комплексов работ/подрядов.

При структуризации проектов часто допускаются разнооб­разные ошибки. Наиболее типичными являются следующие ошибки [2; 59]:

– пропуск «неосязаемых» конечных продуктов, таких как услу­ги, информационное или программное обеспечение;

– такой вариант структуризации проекта, результаты которого
невозможно обработать на компьютере;

– излишняя или недостаточная детализация разрабатываемых структур;

– отсутствие интеграции структуры проекта с системой веде­ния бухгалтерских счетов;

– повторение одних и тех же элементов структуры;

– непонимание того, что структура проекта должна охваты­вать весь его жизненный цикл (как правило, пропуск на­чальной и конечной фаз проекта);

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

– пропуск стадии структуризации проекта и попытки непосредственного перехода к анализу и решению проблем реали­зации проекта.

Стандартные шаги при структуризации проекта

Процесс структуризации проекта может быть представлен в виде последовательности действий, осуществляемых поэтапно. Эта последовательность имеет следующий вид [2; 65 - 68]:

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

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

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

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

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

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

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

4. Построение единой структуры проекта. Единая структура проекта объединяет в себе структуру процесса, организационную структуру и план бухгалтерских счетов.

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

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

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

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

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

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

) разработка системы наряд-заданий. Система наряд-заданий вытекает из предварительной структуры разбивки проекта и матрицы распределения ответственности. На этом этапе задания должны быть абсолютно конкретны во времени и ресурсах;

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

Методы структуризации проекта

Методы структуризации проекта принципиально сводятся к двум основным типам [1; 100]:

) метод «сверху-вниз»  –  определяются общие задачи,  на основе которых далее осуществляется детализация уровней проекта;

) метод «снизу-вверх» – определяются частные задачи, а за­тем происходит их обобщение.

Для структуризации проекта используют ряд специальных моделей, как-то:

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

2. Дерево задач – разработка структурной модели проекта по декомпозиции задач проекта на составные части. Состав задач проекта определяется из целей проекта, конечного результата и предпроектного состояния предметной составляющей проекта – продукта, биз­нес-функции или услуги. Системный подход в определении задач проекта аналогичен подходу в определении целей, используя техно­логии иерархических декомпозиций в виде дерева. В вершине «дере­ва» располагается сверхзадача проекта, в основании – элементарные задачи (работы, мероприятия) нижнего уровня. Такие методики – разбиение проекта на более мелкие задачи – позволяют представить его в виде вполне управляемых компонентов [4; 168 - 169].

3. Дерево работ. На каждой стадии планирования необходимо разделить работы по проекту на части. Например, на стадии технического проектирования основные части проекта, как правило, очевидны. В дальнейшем, когда станет известно больше деталей, эти части могут быть расчленены на соответствующие разделы. Наконец, могут быть определены подразделы и отдель­ные группы («пакеты») работ. Эта процедура, как указывалось выше,  известна как со­ставление дерева работ проекта (WBS – Work Breakdown Structure). Такое дерево является средством расчленения боль­шого, сложного проекта на его компоненты или хозяйственной программы на составляющие проекта.

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

Пакет работ является также самостоятельной финансовой единицей. Он должен иметь отдельную смету, бюджет и отчет о расходах. Вычленение пакетов работ представляет большое удоб­ство при разработке сетевого графика проекта. Гораздо легче пла­нировать отдельные пакеты и затем собирать сетевой график проекта из фрагментов, нежели разрабатывать сетевой график в целом без дерева работ проекта [2; 69].

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

Структурная модель проекта по фазам

жизненного цикла

Основные подходы к построению структурной модели проекта таковы [4; 169 - 170]:

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

Для обеспечения эффективного управления проектом при разработке проекта необходимо:

) учесть в плане все разделы, этапы и работы проекта;

) учесть в плане все организации, участвующие в проекте;

) обеспечить действенность управления путем распределения ответственности.

Первое требование может быть удовлетворено разбивкой проекта на пакеты работ с помощью WBS. Для выполнения по­следних двух требований плановик должен указать, какая орга­низация ответственна за каждый пакет или уровень дерева работ. Другими словами, он должен четко определить уровни и объемы ответственности в организационной структуре. Это мо­жет быть сделано с помощью схемы организационной структуры проекта (OBS – Organisation Breakdown Structure).

В этой схеме руководитель проекта находится на ее верхнем уровне, а на более низких уровнях последовательно располагают­ся отделы, требуемые для функционального управления работа­ми. Эти уровни иногда соответствуют уровням WBS. Например, отдел главного энергетика будет ответственным за пакет работ «Линии электропередачи».

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

2. Матрица ответственности связывает пакеты работ с организациями-исполнителями на основе WBS и OBS. В матрице ответ­ственности определяются основные исполнители по пакетам работ.

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

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

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

5. Структура затрат. Методика структуризации затрат аналогична используемой в процессе разработки структуры потребляемых ресур­сов.

6. Структурная декомпозиция контрактов по работам проекта.

7. Дерево распределения рисков проектов.

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

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

Литература:

1. Шеремет В.В., Павлюченко В.М., Шапиро В.Д. и др. Управление инвестициями: В 2 – х томах. Том 1. – М.: Высшая школа, 1998. – 416 с.

2.  Проектный менеджмент: Учебно-консультационный курс. – М.: ГУ «МИВТ - Центр»; Лаборатория Базовых Знаний, 2007. – 287 с.

3. Мазур И.И., Шапиро В.Д., Ольдерогге Н.Г. Управление проектами: Учебное пособие. – М.: Омега – Л, 2005. – 664 с.

4. Информационный менеджмент / Под научной редакцией Н.М. Абдикеева. – М.: ИНФРА-М, 2009. – 400 с.