Тема 4. Структуризация проекта

4.1. Суть и цели проведения структуризации проектов

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

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

Из сказанного видно, что каждый элемент проектируемой системы должен:

–быть (или поддаваться) управляемым;

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

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

–иметь закрепленных за собой ответственных исполнителей;

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

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

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

39

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

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

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

5.Деление на элементы структуры проекта не является постоянным. В зависимости от обстоятельств оно может быть изменено, изменения могут быть весьма существенными, вплоть до досрочного прекращения работ по отдельно выделенному элементу. Это положение имеет глубокий смысл. Не исключено, что достижения, полученные при разработке одного элемента проекта (или появление новых технологий), могут привести к «ненужности» работ по другому элементу этого проекта. Иначе говоря, каждый проектируемый элемент будущей структуры должен «всплывать» не из «прежнего опыта», а ориентироваться на «будущие передовые научно-технические достижения» с учетом времени окончания проектных работ. (Отсюда вытекает важность экспертных исследований и анализа изменений требований заказчика).

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

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

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

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

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

Структуризация проекта проводится в следующей последовательности [4, 5, 20, 26, 27]:

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

40

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

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

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

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

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

Дляструктуризациипроектовнашлиширокоеприменениеследующиемодели:

–построение деревьев работ (графов), целей, решений;

–построение матричных структур.

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

Представление в виде дерева (графа) – это способ представления, показы-

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

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

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

41

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

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

2.Декомпозиция (вид «дерева»), проведенная разными экспертами одной

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

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

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

5.Все модели, по существу, субъективны и отражают взгляд конкретного человека на проблему. В зависимости от внешних обстоятельств мнение человека может изменяться, в результате чего исходная модель может трансформироваться, «вес», значимость и степень «необходимой» детализации отдельных элементов может претерпевать изменения. Например, проектируется платная стоянка автомобилей. Что включить в проект? Только охрану, охрану и мойку (на чем и как?), охрану и техобслуживание (что предполагается делать?), охрану и предоставление других услуг (каких?) и т.д. Очевидно, что количество и содержание отдельных автономных блоков отличается друг от друга. Без доказательства ясно

42

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

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

Какие же признаки желательно брать за основу при структуризации проекта? Они очень разнообразны. Приведем некоторые из них [1-5] (табл. 2.2.2).

						Таблица 2.2.2
	Признаки, используемые для структуризации проекта
		Функциональные	Структурные элементы			Связь и потоки
		элементы
Аналити-	1.	Функции (действия)	1.	Состав элементов	1. Ответственность
ческие		внешней среды.		структуры.		исполнителей.
этапы	2.	Функции (действия)	2.	Состав работ.	2. Форма связи.
		участников проекта.	3.	Стоимость отдельных	3. Нормативы, инст-
	3.	Цели.		работ.		рукции.
	4.	Критерии оценки.	4.	Ценовая политика	4. Передача инфор-
	5.	Классификация рисков.		(продажная цена)		мации
	6.	Составы участников
Фазы	1.	Взаимное подчинение	1. Разработка оператив-		1.	Структуры обрат-
проекти-		внутри коллектива.	ных планов:			ных связей (ОС).
рования	2.	Система отчетности.	- контроль качества;		2.	Распределение
	3.	Спецификация выход-	- контроль состояния ра-			информационных
		ной продукции.	бот;			потоков.
	4.	Заключение контрактов.	- контроль оплаты труда;		3.	Критерии служеб-
	5.	Способы контроля	- контроль за системами			ного роста и по-
			обслуживания			вышение квалифи-
						кации
Заверше-	1.	План изменений	1. План передачи отчет-		1.	Оценка персонала.
ние про-	2.	Необходимость и целе-		ной документации	2.	Оценка выполнен-
екта		сообразность переоцен-	2. План передачи собст-			ной работы окру-
		ки целей		венности		жением

Основные причины сложности построения «деревьев»:

–недостаток квалификации специалистов в области прогнозных исследо-

ваний;

–недостаток информации;

–часто большая размерность «дерева» и отсутствие опыта комплексной увязки отдельных задач в виде слабосвязанных автономных блоков.

43