CC BY
34
Посилання на статтю_
Аль Атум Мохаммад Фаиз Ахмад Концептуальная модель планирования содержания мягкого проекта на основе сервисной модели / Аль Атум Мохаммад Фаиз Ахмад // Управлшня проектами та розвиток виробництва: Зб.наук.пр. -Луганськ: вид-во СНУ iм. В.Даля, 2014 - №1(49). - С. 172-180. - Режим доступу -http://pmdp.org.ua_
УДК 005.8:005.216:005.12
Аль Атум Мохаммад Фаиз Ахмад
КОНЦЕПТУАЛЬНАЯ МОДЕЛЬ ПЛАНИРОВАНИЯ
СОДЕРЖАНИЯ МЯГКОГО ПРОЕКТА НА ОСНОВЕ СЕРВИСНОЙ МОДЕЛИ
Планирование содержания проекта формализовано на основе сервисной модели, которая учитывает особенности мягкого проекта через категории «ценность» и «компетентность». Рис. 3, дж. 16.
Ключевые слова: проект, содержание проекта, мягкий проект, личность, компетентность, ценность, сервисная модель проекта, схематическая модель проекта.
Аль Атум Мохаммад Фаз Ахмад
КОНЦЕПТУАЛЬНА МОДЕЛЬ ПЛАНУВАННЯ ЗМ1СТУ М'ЯКОГО ПРОЕКТУ НА ОСНОВ1 СЕРВ1СНО1 МОДЕЛ1
Планування змюту проекту формалiзовано на основi сервюно'Т модели яка враховуе особливост м'якого проекту через категорп «цЫнють» i «компетентнють». Рис. 3, дж. 16.
Al Atum Mohammad Faiz Ahmad
CONCEPTUAL MODEL OF THE SOFT PROJECT SCOPE PLANNING BASING ON THE SERVICE MODEL
Planning of the project scope is formalized on the basis of service model that takes into account features of the soft project due to categories "value" and "competence" at once.
JEL O22
ВВЕДЕНИЕ
Постановка проблемы в общем виде и ее связь с важными научными или практическими задачами. Постепенное становление экономики знаний привело к появлению нового типа мягких проектов. Этот факт отмечен уже достаточно давно [1, 2, с.193-195].
Основная отличительная черта мягких проектов связана с необходимостью изменения компетентности личности как необходимого условия успешной эксплуатации их продуктов. Так, например, внедрение систем управления знаниями в организации не дадут существенных результатов до тех пор, пока ее сотрудники не пересмотрят своего отношения к таким вопросам, как роль знаний в процессах развития, или роль знаний как фактора производства, необходимости постоянного генерирования новых знаний, интеграция "УправлЫня проектами та розвиток виробництва", 2014, № 1(49) 1
собственных новых знаний со знаниями организации и др. В работе [2] отмечается, что продукт мягких проектов трудно однозначно описать как по содержанию, так и во времени. Его характеристики сильно зависят как от целевого, так и от других контекстов проекта.
Сегодня мягкие проекты уже составляют львиную долю всех реализуемых проектов. В ответ на это современные версии профессиональных стандартов в сфере управления проектами тоже заметно «смягчились». В них все большее значение стало уделяться мягким компонентам проектов - личностям, их поведению и взаимодействию, восприятию качества, риска и неопределенности, успешности, оценкам ситуаций в моменты принятия решений и др. Это актуализировало задачу целостного видения проектов и программ (методология Р2М [3]) и выдвинуло в ряд центральных такие категории, как «ценности», «среда деятельности и взаимодействия», «инновация», «сложность проблемы», «сопротивление среды», «знания».
Оперирование такими категориями требует изменения традиционных методов и инструментов управления проектами, которые прежде ориентировались только на время - качество - ресурсы. Статистика же провалов проектов и их причин позволяет утверждать, что для управления мягкими проектами, как правило, используются традиционные инструменты, которые не позволяют учитывать их особенности. В частности, это касается планирования содержания проектов. Например, второе издание стандарта по разработке иерархической структуры работ проекта [4] не менялось с 2006 г., при том, что базовые стандарты по управлению программами [5], портфелями [6], стандарт РМВОК [7] и некоторые другие претерпели изменения относительно недавно (начало 2013 г.).
Анализ исследований и публикаций и выделение нерешенных ранее частей общей проблемы. Результат планирования содержания проекта закладывает основы для его успешного выполнения и управления этим процессом. Согласно РМВОК [7], его главная задача - потребности заинтересованных сторон трансформировать в формальные требования к продукту проекта и пониманию того, что нужно сделать для получения такого продукта. Однако еще более важно при этом ориентироваться на ценности, которые заинтересованные стороны - потребители - могут получить на этапе эксплуатации продукта проекта. Сегодня это возможно достичь в рамках целостного подхода к управлению проектами на основе сервисной модели. Ключевые положения такого подхода заложены в Руководстве Р2М [3] и развиты нами в работе [8].
Тем не менее, согласно данным статистики, до 80% проектов сегодня проваливаются на этапе эксплуатации продукта. Это подтверждает необходимость разработки специфического инструментария для планирования содержания мягких проектов на принципиально новой «сервисной» основе.
Цель статьи - сформировать целостное видение сущности планирования содержания мягкого проекта на основе сервисной модели.
ОСНОВНЫЕ РЕЗУЛЬТАТЫ
Методы и методики исследования. В исследовании использованы методы графического моделирования, общенаучные методы анализа-синтеза. В качестве ключевых мировоззренческих позиций выступают категория «целое» [9] и его триадная сущность [10].
Изложение основного материала исследования с полным обоснованием полученных результатов. Для формирования целостного видения планирования содержания мягкого проекта на основе сервисной модели обратимся сначала к сущности этого процесса. Он описан в Руководстве
2
"УправлЫня проектами та розвиток виробництва", 2014, № 1(49)
РМВОК в рамках области знаний по управлению содержанием проекта [7, с.105-140].
Общая схема управления содержанием включает шесть ключевых процессов: планирование управления содержанием, сбор требований, определение содержания, создание иерархической структуры работ (ИСР), подтверждение содержания, контроль содержания. Их взаимодействие направлено на то, чтобы обеспечить, чтобы проект содержал все и только те работы, которые требуются для успешного выполнения проекта.
Исходя из сущности каждого процесса, в Руководстве представлены потоки данных для каждого из них. В основу потоков положена логика «входы -выходы». При этом отсутствует целостное представление взаимосвязи между всеми процессами одновременно. Общая схема управления содержанием проекта в виде иерархической структуры такую взаимосвязь, к сожалению, не демонстрирует.
Анализ концептуальных моделей показал, что для задачи целостного представления деятельности по планированию содержания наиболее близка модель процесса. Она характеризуется четкой логикой ее элементов (деятельность/процесс, вход, выход, управляющее воздействие, ресурсы -более детально описаны в [11]). Использование процессной модели как основы анализа сущности процессов, продуктов и потоков данных в рамках управления содержанием проекта позволило разработать модель управления содержанием проекта, представленную на рис. 1.
Как видно из модели на рис. 1, процессы сбора требований, определения содержания, создания ИСР, подтверждения содержания объединены в рамках более общего процесса - «планирование содержания проекта». В Руководстве данный процесс и его описание отсутствует. В рамках планирования содержания все перечисленные процессы взаимосвязаны последовательно, когда выход одного процесса является входом для другого. Подобное группирование процессов позволило четко установить отношения между ними. Следуя логике процессной модели, продукт процесса планирования управления содержанием проекта в виде соответствующего плана выступает в качестве управляющего воздействия по отношению к группе процессов планирования содержания. Это не противоречит пониманию планирования управления содержанием как процесса «создания плана управления содержанием, документирующего, каким образом содержание проекта будет разрабатываться, определяться, подтверждаться, отслеживаться, контролироваться и проверяться» [7, с.108].
"УправлЫня проектами та розвиток виробництва", 2014, № 1(49)
3
1 - сбор требований; 2 - определение содержания; 3 - создание ИСР;
4 - подтверждение содержания;
ПМ - проектный менеджер, ЗС - заинтересованные стороны
Рис. 1. Представление управления содержанием проекта на основе процессной модели
При этом процесс контроля содержания проекта «вынесен за скобки» и представлен как «фоновый» для процессов планирования управления содержанием и планирования содержания. И это соответствует одному из положений Руководства. В частности, в разделе 3.1 отмечено, что «процессы мониторинга и контроля осуществляются в то же самое время, что и процессы, входящие в другие группы процессов», и этого «требует интегративный характер управления проектом». На этом основании процесс мониторинга и контроля изображен как «фоновая» группа процессов для других четырех групп -инициации, планирования, исполнения, закрытия [7, с.49, рис. 3-1].
Модель конкретизирует продукт планирования содержания проекта. Он представлен в виде подтвержденного базового плана проекта по содержанию, который состоит из описания содержания проекта, ИСР и словаря ИСР. Описание содержания проекта включает описание продукта проекта и требования к нему (собственно, содержание продукта), а также работы, которые необходимо выполнить для получения продукта (собственно, содержание проекта). Тем самым, содержание проекта четко очерчивает границы проекта -что в него включено, а что исключено.
Дальнейший анализ сущности процессов планирования содержания проекта позволяет представить его как череду последовательных трансформаций относительно «размытых» потребностей и ожиданий заинтересованных сторон в количественно и качественно определенные требования к продукту проекта, далее в упорядоченную совокупность работ, которые необходимо выполнить в проекте. Результат такой трансформации становится в дальнейшем основой для планирования расписания, стоимости, качества, закупок и других областей деятельности по проекту.
4
"УправлЫня проектами та розвиток виробництва", 2014, № 1(49)
Важно, что подобная трансформация предполагает тесное взаимодействие заинтересованных сторон и проектного менеджера на начальном и завершающем этапе. При этом каждый из них действует в своей области компетенции: менеджер в рамках управленческой деятельности, заинтересованные стороны - продуктной (классификация деятельности в проекте на управленческую и продуктно-технологическую описана в работах [2, 12]). При этом традиционно речь идет о выявлении потребностей, функций и характеристик продуктов. Для проектов, использующих гибкие методы адИе [13] (обычно ИТ-проекты), уже оперируют понятиями «цель и польза» для заинтересованной стороны как основы для выявления и описания требуемой функциональности продукта. Однако для любых проектов неоспоримо одно -«до включения в базовый план требования должны стать однозначными (измеримыми и проверяемыми), отслеживаемыми, полными, непротиворечивыми и приемлемыми для всех заинтересованных сторон» [7, с.117].
Предложенная модель на рис. 1 позволила целостно представить известные знания о планировании содержании проекта. Это есть необходимым условием для дальнейшей интерпретации данного процесса на основе сервисной модели.
«Сервисная модель» - уже устоявшееся на сегодня словосочетание. Оно появилось в сфере ИТ и подразумевает скорее подход, принцип к ведению деятельности, нежели как целевое графическое отображение действительности (например, [14, 15]). Это касается и управления проектами. Понятие сервисной модели впервые появилось в рамках методологии управления инновационными программами и проектами Р2М [3]. Там сервисная модель представлена как одна из трех стандартных моделей проекта (две другие - схематическая и системная). Выделим наиболее важные для данного исследования положения, связанные с сервисной моделью проекта.
Прежде всего, применение сервисной модели требует перенести акцент с категорий «потребность», «цель», «польза» на категорию «ценность». Именно ценности заинтересованных сторон, выявленные и учтенные уже на стадии планирования проекта, позволяют конкретизировать функции и характеристики продукта проекта и обеспечить его успешную эксплуатацию, даже в изменяющихся условиях. Переход на «ценность» позволяет формировать целостное видение проекта. При этом сопутствующими категориями выступают «инновация», «сложность проблемы», «сопротивление среды». Они приходят на смену привычным «времени», «деньгам» и «качеству».
Ранее в работе [8] нами было показано, что сервисная модель проекта - это одна из трех метрик, которые позволяют рассматривать его как целое. Остальные две метрики представлены схематической и системной моделями проекта. Причем, каждая из метрик (моделей), в свою очередь, описывается такой же триадой компонентов: схема - система - сервис. Такой подход к структурированию проекта позволил доказать необходимость совместной разработки схематической и сервисной моделей проекта. Выгода, которая при этом достигается - возможность реализовать одно из основных требований к схематической модели - «гибкую адаптацию путем модификации оценки в ответ на требования изменений от пользователя, возникающие по причине изменений во внешней среде» [3, с.124]. В терминах методологии Р2М, именно комбинация моделей проекта позволяет генерировать добавленную ценность проекта и является источником инновации и креативности [3, с.125].
Схематическая модель проекта применяется для создания предварительной концепции проекта и базового плана. Именно на стадии ее
"УправлЫня проектами та розвиток виробництва", 2014, № 1(49)
5
разработки формируется концептуальная, инновационная ценность проекта. А это напрямую связано с задачей планирования содержания проекта. Это позволяет считать, что планирование содержания проекта на основе сервисной модели принимает вид, представленный на рис. 2.
Согласно описанному в работе [8] подходу, компоненты схематической и сервисной моделей проекта разрабатываются одновременно, реализуя интерактивное видение. При этом происходит взаимное дополнение одного типа компонента первой модели другим типом компонента другой модели в выделенных областях А-В-С.
Так, в области «А» одновременно реализуется процесс выявления потенциальных ценностей потребителя как основание для формализации проблемы - отправной точки деятельности проектного менеджера. Благодаря этому будущий потребитель (клиент) имеет наибольшее влияние на будущий продукт проекта, через четкое формулирование специфических условий будущей его эксплуатации, и ожидаемых ценностей от этой эксплуатации. Именно в этой области необходимо использовать инновации, которые максимально увеличат возможность получения ценности потребителем от эксплуатации будущего продукта проекта.
В области «В» одновременно разрабатываются системные компоненты схематической и сервисной моделей. Это значит, что разработка базовых концептуальных документов по проекту непосредственно связана со знанием будущих функций продукта проекта, которые рассматриваются потребителем как ценные. В области «С» основные инновационные идеи, касающиеся функциональности, должны закладываться в план проекта. А реализация плана должна обеспечить получение необходимого продукта.
6
"УправлЫня проектами та розвиток виробництва", 2014, № 1(49)
1 - область описания содержания продукта проекта;
2 - область описания содержания проекта
Рис. 2. Представление планирования содержания проекта на основе сервисной модели
Представление планирования содержания на основе сервисной модели позволяет выделить следующие особенности.
В области сервисной модели реализуется череда последовательных трансформаций потенциальных ценностей потребителя в конкретные очертания продукта проекта. То есть, область сервисной модели является областью, в которой осуществляется описание содержания продукта проекта. Тогда как в области схематической модели происходит описание содержание проекта. Эти две области предполагают использование соответствующих терминов и интерактивно взаимодействуют.
В области «А» происходит сбор требований, в области «В» - определение границ содержания, а в области «С» - описание содержания проекта как основы базового плана.
Интерактивное взаимодействие происходит в областях А-В-С между соответствующими элементами «схема-сервис» в области «А», «система-система» в области «В», «сервис-схема» в области «С». Отправной точкой для интерактивного взаимодействия областей выступают ценности потребителя. Это задает траекторию интерактивного взаимодействия областей: от элемента «сервис» к элементу «схема» в области «А», далее от элемента «система» схематической модели к элементу «система» сервисной модели в области «В», и, наконец, от элемента «схема» к элементу «сервис» в области «С».
"УправлЫня проектами та розвиток виробництва", 2014, № 1(49)
7
ОБСУЖДЕНИЕ
Анализ и обобщение полученных результатов. Обобщение полученных на данном этапе результатов позволяет выполнить последнюю итерацию целостного представления планирования содержания мягких проектов на основе сервисной модели. Основой для этого выступает категория «компетентность».
Как было отмечено выше, продуктом мягкого проекта всегда является измененная компетентность (-и) ее носителя - личности.
На сегодня существует множество интерпретаций данного термина. В нашем исследовании будем использовать определение, обоснованное в работе [16, с.5]. «Компетентность - деятельность в рамках компетенции, успешно проявленная в ситуациях, которые ранее не встречались и не изучались, обычно со слабо структурированным контекстом. Компетенция - круг деятельности, который определяет права, обязанности и функции, а также возможные ситуации, в которых личность должна проявить активность с учетом известного контекста».
Такая интерпретация компетентности позволяет говорить о степени ее изменения как классификационном признаке для мягких проектов. Чем больше степень изменения компетентности личности (как продукт проекта) - тем выше степень мягкости проекта.
Интерпретация элементов планирования содержания проекта на основе сервисной модели с позиции категории «компетентность» представлена на рис. 3.
Рис. 3. Представление планирования содержания мягкого проекта на основе сервисной
модели
Как видим, сбор требований в области «А» реализуется путем формализации потенциальных ценностей, которые личность ожидает получить в случае изменения компетентностей. Для этого необходимо описать видение комфортной жизнедеятельности в терминах личности. Это позволит проектному менеджеру более четко формализовать модель жизнедеятельности личности в 8 "УправлЫня проектами та розвиток виробництва", 2014, № 1(49)
далее «перейти» в термины спецификаций компетентностей. Зачем? Для того, чтобы получить некую эталонную модель, по отношению к которой можно было бы замерять фактические компетентности личности. Разница между ними (компетентностный дисбаланс) и покажет границы содержания продукта проекта. При этом представлена она будет в виде четких спецификаций. Это позволит перейти к описанию содержания проекта как части базового плана проекта. Выводы
1. В качестве базовых категорий планирования содержания мягких проектов на основе сервисной модели выступают «ценности» и «компетентность». Первая категория определяет механизм планирования как последовательность взаимосвязанных действий, а вторая - задает сущность действий.
2. Разработанная концептуальная модель формирует целостное видение планирования содержания мягких проектов на основе сервисной модели с позиции двух названных категорий одновременно.
Перспективы дальнейших исследований в данном направлении. Полученные результаты моделирования дают возможность провести дальнейший анализ и выявить конкретные методы и инструменты, которые нужны для планирования содержания мягкого проекта на основе сервисной модели.
ЛИТЕРАТУРА
1. Рач, В.А. Мягкие проекты: отличительные черты, классификация, масштабность применения розвитку [Текст] / В.А. Рач // Управлшня проектами у розвитку сусптьства. Прискорення розвитку оргаызацп на основi проектного управлшня: тез. доп. VI мiж. конф. 21-22 травня. - К.: КНУБА, 2009. - С.156-158.
2. Рач, В.А. Управлшня проектами: практичн аспекти реалiзацií стратепй репонального розвитку [Текст]: навч. поаб. / Рач В.А., Россошанська О.В., Медведева О.М.; за ред. В.А. Рача. - К.: «К.1.С.», 2010. - 276 с.
3. Руководство по управлению инновационными проектами и программами организаций [Текст]: монография; пер. на русс. яз. под ред. д.е.н., проф. Ярошенко Ф.А. - К, 2011. -Т.1, Версия 1.2. - 209 с.
4. Practice Standard for Work Breakdown Structure. Second edition. - Project Management Institute, Inc., Pennsylvania USA, 2006. - 111 p.
5. The Standart for Program Management. Third edition. - Project Management Institute, Inc., Pennsylvania USA, 2013. - 176 р.
6. Project Management Institute. Standard for Portfolio Management. The 5th edition. - PMI, 2013. - 189 р.
7. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) [ТехЦ. Fifth Edition. - Project Management Institute, Inc., 2013. - 189 р
8. Рач, В.А. Структуризация схематической, системной и сервисной моделей проекта с позиций базовых положений триадной парадигмы управления проектами [Текст] /
B.А. Рач, Альатум Мохаммад // Управлшня проектами та розвиток виробництва: Зб. наук. праць. - Луганськ: вид-во СНУ iм. В.Даля, 2011. - №3(39). - С. 136-145.
9. Рач, В.А. Экономическая безопасность и пространство проекта организации в аспекте целостной системности [Текст] / Рач В.А., Россошанская О.В., Медведева Е.М. // Управлшня проектами та розвиток виробництва: Зб. наук. праць. - Луганськ: вид-во СНУ iм. В.Даля, 2010. - №4(36). - С. 62-74.
10. Баранцев, Р.Г. Тринитарный критерий целостности [Электронный ресурс] / Р.Г. Баранцев // Академия Тринитаризма. - М., Эл. №77-6567, публ.11751. -05.01.2005. - Режим доступа: www.trinitas.ru/rus/doc/0226/002a/02260063/htm.
11. Бержер, С. Графическое описание процессов. Методика и технические средства /
C. Бержер, С. Гийар. [Науч. ред. А.В.Глазунов, В.Б.Михейкин]. - Нижний Новгород: ОО СМЦ «Приоритет», 2003. - 250 с.
12. Рач, В.А. Стан та тенденци розвитку трiадноí методологи управлшня проектами [Текст] / Рач В.А., Россошанська О.В., Медведева О.М. // Управлшня розвитком складних систем. - 2010. - Вип. 3. - С.118-122.
"Управлшня проектами та розвиток виробництва", 2014, № 1(49)
9
13. Agile Project Management [Electronic resiouce]. - Available at: http://www.ccpace.com/resources/documents/agileprojectmanagement.pdf.
14. Голубцов, В. Сервисно-ресурсная модель. От теории к практике [Электронный ресурс] / В. Голубцов, М. Федоренко. - Режим доступа: http://www. osp.ru/itsm/2012/09/13017362. html.
15. Аксенов, Е. Сервисная модель как путь к эффективности ИТ [Электронный ресурс] / Е. Аксенов. - Режим доступа: http://www.computerra.ru/cio/old/blog/index.php?blog=eaks&page=post&post_id=23.
16. Бiрюков, О.В. Контекстна оцшка компетентност команди управлЫня проектом [Текст]: автореф. дис. ... канд. техн. наук: 05.13.22 / О.В. Бiрюков; Кив. нац. ун-т буд-ва i арх^. - К., 2012. - 23 с.
Рецензент статт Стаття надшшла до редакцп
д.т.н., доц. Медведева О.М. 24.02.2014 р.
10
"УправлЫня проектами та розвиток виробництва", 2014, № 1(49)
