7. КОРПОРАТИВНОЕ УПРАВЛЕНИЕ ПРОЕКТАМИ: ПРИНЦИПЫ РАЗРАБРТКИ И ВНЕДРЕНИЯ

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

7.1. Основы технологии проектного менеджмента

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

Основной проблемой внедрения методов проектного менеджмента на предприятиях заключается в недоверии руководства компаний к новым методам управления. Осознание необходимости внедрения инновационных технологий управления (в частности проектного менеджмента), как и внедрение всего нового и передового» в различных сферах деятельности общества, подчиняется эволюционному закону развития. С другой стороны, по данным Международной ассоциации управления проектами (IPMA) известно [8], что методы проектного менеджмента при использовании их в компаниях и в организациях более эффективны и менее затратные по сравнению с другими современными методами управления предприятиями.

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

73

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

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

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

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

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

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

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

II – выполнение; осуществление общего мониторинга и контроля с целью оперативного управления;

III – завершение, подготовка к передаче созданногопродукта Заказчику. Все действия, необходимые на создание продукта проекта, и управ-

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

74

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

Окружающая среда проекта. Осуществление проекта происходит

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

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

Предметную область проекта определяют цели, результаты и состав работ. В процессе исполнения и завершения проекта все элементы предметной области изменяются: цели, результаты. объемы работ.

Управление предметной областью проекта необходимо осуществлять на протяжении его ЖЦ.

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

впроекте достаточно велик.

Для выполнения проекта нужны специалисты различной квалификации. На разных этапах ЖЦ проекта нужны свои эксперты/специалисты: эксперты по экономическим вопросам, специалисты по построению организационных систем и управления производственными процессами, менеджеры по управлению персоналом, опытные исполнители по финансово-экономическим, техническим и другим вопросам.

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

7.2. Организация управления проектом

Успешное выполнение проектных действий измеряется критериями "производительности", "эффективности" и "надлежащего выполнения".

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

75

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

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

Современные критерии к выполнению проектных действий побуждают менеджеров проектов к непрерывному профессиональному совершенствованию своих способностей:

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

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

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

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

В целом управленческие действия по проекту разделяют на две категории:

1)те, которые направлены на создание продукта проекта;

2)те, которые направлены на выполнение проекта. Вся совокупность действий, направленных на создание промежуточных результатов проекта,

витоге приводит к полному достижению целей.

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

76

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

7.3. Формирование подходов к эффективному управлению требованиями в проектах

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

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

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

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

Новые применяемые методы расширяют концепцию моделирования, например, такие как объектно-ориентированные методы моделирования.

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

77

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

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

Процессы, которые необходимо реализовать для разработки требований к системам и продуктов определяет Международный стандарт ISO/IEC 29148. Стандарт содержит руководство по применению процессов, связанных с требованиями, определяет необходимое информационное обеспечение для реализации процессов. Подход к разработке требований в стандарте основывается на учете окружений проекта:

-внешний мир (соглашения с ним + регулирование)

-бизнес/менеджмент

-проекты/"операции"

-техническая сущность продукта/услуги.

Стандарт определяет характеристики отдельных требований: «Необходимость», «Абстрактность», «Недвусмысленность», «Согласованность с другими требованиями», «Полнота», «Четкость», «Краткость», «Выполнимость», «Осуществимость», «Трассируемость», «Проверяемость», так и характеристики групп требований: «Полнота», «Согласованность с другими группами», «Выполнимость (в рамках бюджета, сроков)», «Ограниченность».

Инженерия требований предусматривает широкий спектр различных действий, относящихся к требований, таких как анализ требований или, например, управление требованиями (requirementsmanagement) и разработка требований (requirements development).

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

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

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

78

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

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

Синонимами термина «требования» (requirements) определены следующие понятия: намерения, замыслы (aims), стремления (aspirations), способности, возможности (capabilities), критерии (criteria), ограничения

(constraints), директивы (directives), доктрины (doctrines), обязанности (duties), ожидания, предположения (expectations), особенности (feature),

функции (functions), цели (goals), назначение (mission), потребности (needs), обязательства (obligations), целевые установки, задачи (objectives), инструкции (orders), нормы, предписания (regulations), правила (rules) и т.д.

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

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

Важным (и законным) источником требований являются заинтересованные стороны. Понятие “Заинтересованная сторона” (Stakeholder) – определяется как физическое лицо, группа лиц, организация или иная структура, имеющая прямые или косвенные интересы (или права) относительно системы (или её свойств).

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

79

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

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

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

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

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

Как правило, человек должен оценивать результат прошлых действий

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

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

Таким образом, модель не является каким-то отражением, а является целевым отображением.

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

80

которые могут быть использованы для разработки требований, посвящена значительная часть в работе Э. Халла. Наиболее универсальными с точки зрения формирования баз данных и разработки системных требований, на наш взгляд, являются диаграммы потоков данных, пригодные для описания потоков любого типа и объектно-ориентированные методы, которые описывают поведение объектов и их взаимодействие между собой. Однако диаграммы потоков не всегда обеспечивают точность и однозначность связей и не позволяют корректно отображать ограничения. К объектно-ориентированным методам относятся такие как метод ООА (object-oriented analysis), разработанный Кодом (Coad) и Иордоном (Yourdon) и Метод Буча (Booch). Метод ООА разделяет разработку на три слоя. В первом слое осуществляется определение объектов и достигается понимание проблемной области. Второй слой называется слоем атрибутов. На этом этапе определяются атрибуты (элементы данных), связанные с объектами из предметной области. Третий слой – сервисный слой, определяющий сервисы (или операции), предоставляемые каждым объектом. Метод Буча более подробно рассматривает фазу анализа и чаще используется при проектировании объектно-ориентированных систем. Метод предусматривается постепенное и многократное уточнение архитектуры системы при ее логическом и физическом представлении.

Метод предусматривается фазу анализа проблемной области для выявления классов и объектов, а также связей между ними.

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

Существующая практика выделяет следующие модели системы:

1.“Черный ящик”.

2.Модель состава системы.

3.Модель структуры системы.

4."Белый ящик", или структурная схема системы.

Название "черный ящик" определенно подчеркивает полное отсутствие знаний о внутренних составляющих "ящика". В этой модели задаются только исходящие и входящие связи системы со средой.

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

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

81

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

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

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

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

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

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

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

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

82

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

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

Имитационное моделирование для решения сложных задач целесообразно использовать при следующих условиях:

1)отсутствие аналитических методов решения задач;

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

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

Имитационная модель – это комплексная математическая и алгоритмическая модель исследуемой системы.

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

−Языки, которые ориентированы на поиск ближайшего события

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

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

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

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

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

83

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

Для решения задач структурирования, исключения дублирования и пропуска требований, взаимосвязи (трассировки) между требованиями разных иерархических уровней, обеспечения покрытия (coverage) – степени полноты требований целесообразно использовать методологию имитационного моделирования с разработкой подходов и путей к определению содержания и развертывания модели. Условиям обеспечения полноты требований, их трансформации с учетом взаимосвязей на уровне системного управления наиболее отвечают объектно-ориентированные методы имитационного моделирования, в частности метод ООА (object-oriented analysis), который был выбран для исследований.

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

Базой для разработки модели был принят подход, при котороможидаемое значение вероятности достижения результата Е(х) является средневзвешенным всех возможных значений:

Е(х) = р1 Х1 + р2 Х2 + …рn Хn

где p1, p2 – вероятность достижения соответствующего результата, X1, X2 – значения возможных результатов.

Результат управления требованиями может быть представлен функцией от выбранных компонентов (объектов) управления и уровня их детализации:

В= F (В1, В2, ….Вn ).

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

Необходимыми и достаточными объектами с учетом этого подхода для большинства проектов могут быть:

– бизнес требования (требования верхнего уровня) В1 – формулируются руководством компании-заказчика на стадии разработки проектного решения для выбранной̆системы;

84

–требований потребителей В2 – отражают их пожелания к функциям

ихарактеристикам продукта и создаваемой̆системы;

–требования существующих стандартов и регламентов (международных,

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

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

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

–система индикации данных и информации по работе с требованиями

В6 – для отслеживания результатов по управлению требованиями и принятия решений;

–внутренняя база знаний по работе с требованиями В7 – формируется

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

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

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

Рис. 7.1 – Обобщенная схема связей объектов модели

85

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

Впрессе преобразования осуществляется корректировка, систематизация

иоценка важности требований с формированием формализованного перечня, который далее будет использоваться для принятия решений по проекту и его продукту. Такой перечень может быть представлен в виде матрицы согласно методологии QFD и, например, для IТ-проекта определен требованиями с учетом рейтинга их важности (табл.7.1). На основе формализованного и систематизированного перечня разрабатывается перечень проектных решений (инженерных характеристик продукта проекта), что является базовым документом для разработки техзадания проекта.

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

метры СММ (Capability Maturity Model), ISO 12207, 15504, ITIL (IT Infrastructure Library), MSF (Microsoft Solutions Framework), RUP (IBM Rational Unified Process).

Сформированный на основе этих стандартов перечень требований также представляется в виде матрицы собозначением ранга важности (табл.7.2).

86

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

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

Предложенный подход к моделированию системы позволяет:

−минимизировать общее количество требований;

−систематизировать большой объем информации;

−выявить наборы требований, относящихся к конкретному проекту;

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

−выявить недостатки и дублирования;

−исключить противоречия между требованиями;

−управлять этапами реализации требований;

−отклонять малоинформативные требования;

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

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

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

87

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

Предложенный метод формирования целевого пространства проектноориентированных организаций позволяет рассматривать их движение к цели в ходе реализации портфеля проектов.

7.4. Принятие проектных решений с использованием методологии структурирования функции качества

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

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

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

Методология структурирования функций качества (Quality Function Deployment – QFD) базируется на учете требований и пожеланий заказчиков (потребителей) путем их постоянного уточнения [9]. Обычно заказчик (потребитель) высказывает свои пожелания, четко не формализуя свойства конечного продукта. Для успешной реализации воли заказчика исполнителям этого описания недостаточно, им необходимо четко знать характеристики, размеры, материалы, параметры, требования к обработке, требования к программному обеспечению и так далее. Задача исполнителя (изготовителя) заключается в том, чтобы с помощью различных методов превратить (интерпретировать) требования потребителя в характеристики продукта. В результате такой работы требования потребителя могут быть развернуты в технические требования к продукту, а затем в его конкретные показатели (характеристики). Только после этого исполнитель может ответить на вопрос, что нужно сделать, чтобы удовлетворить ожидания потребителя.

Методология QFD впервые начала использоваться в 70-х годах Японскими компаниями с целью укрепления связей с потребителями и постоянного учета их потребностей и пожеланий. В 90-е годы методология

88

стала широко применяться в американских компаниях, а с 2000-х годов методы QFD внедряются в различных отраслях экономики: авто производство, энергетическая, IT и космическая отрасли.

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

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

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

Основные этапы развертывания функции качества в нефтегазовых

проектах.

1) Определение требований потребителей (заказчиков).

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

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

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

2) Обработка и формализация требований.

Перечень решаемых задач:

-оценка и отбор требований (анализ Парето), ранжирование фактов по значимости;

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

89

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

3)Разработка характеристик и параметров проекта.

Перечень решаемых задач:

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

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

-определение рейтинга параметров проекта с использованием количественных методов принятия решений и метода FMEA, который направлен на определение потенциальных несоответствий и их исключения.

4)Определение зависимости от требований заказчиков и параметров проекта с построением матрицы.

Перечень решаемых задач:

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

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

-отклонение слабых (ненужных) параметров проекта на основе Паретоанализа для составления фактов по значимости;

-построение матрицы зависимостей (построение матриц в программе EXCEL для упорядочения данных).

5)Определение взаимосвязи характеристик и параметров проекта

спостроением матрицы.

Перечень решаемых задач:

-определение критериев оценки взаимосвязи на основе метода критериального анализа для определения критериев и ограничений;

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

-определение противоречивых параметров проекта (применяется эвристический метод принятия решений, основанный на аналитических способностях и интуиции экспертов);

-построение матрицы взаимосвязей (построение матриц в программе EXCEL для упорядочения данных).

6)Определение значимости и рейтингов параметров проекта.

Перечень решаемых задач:

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

90

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

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

7) Экспертная оценка реализуемости параметров проекта.

Перечень решаемых задач:

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

-проведение экспертной оценки с количественной оценкой параметров проекта с применением метода предоставления преимуществ для получения количественных оценок;

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

8) Оценивание рынка и потенциальных конкурентов.

Перечень решаемых задач:

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

-определение рыночной доли конкурентов на основе методов ранжирования для получения информации и оценивания;

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

9) Разработка технического задания и принятия решения об инициировании проекта.

Перечень решаемых задач:

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

-оценка параметров проекта относительно достижений конкурентов на основе методов попарных сопоставлений для оценки и упорядочения данных;

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

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

91

7.5. Внедрение корпоративного управления проектами

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

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

Всем проектам независимо от сферы их применения, свойственны определенные характеристики, позволяющие относить тот или иной вид деятельности к проектам. Такими характеристиками являются:

−уникальность и/или улучшает характер;

−ограничения во времени;

−последовательность разработки.

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

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

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

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

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

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

92

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

Особая роль в корпоративном управлении проектами уделяется использованию современных программных средств и технологий. Определяющая роль отводится корпоративным системам управления проектами (КСУП).

Корпоративная система управления проектами как основной элемент проектного управления. КСУП - специализированный комплекс

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

Составляющими элементами корпоративной системы управления явля-

ются:

−локальные нормативные документы, регламентирующие управление проектной деятельностью (например, корпоративные стандарты);

−организационные структуры, с помощью которых осуществляется управление и координация проектной деятельности компании;

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

−система обучения и аттестации участников проекта. Пользователями КСУП является широкий круг стейкхолдеров корпо-

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

исубъект воздействия.

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

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

Использование КСУП обеспечивает выполнение проектов по объемам

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

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

93