Стейкхолдер проекта – Применение теории стейкхолдеров при продвижении проектов в интернете

Содержание

Zillion — Управление проектами — Стейкхолдер-менеджмент. Как идентифицировать, анализировать и вовлекать стейкхолдеров в проект

 

Слабая коммуникация со стейкхолдерами – путь к провалу проекта, а наоборот – наоборот. По данным исследований PMI, 55% пиэмов считают, что коммуникация – это критически важный фактор. Другой рисерч показал, что хорошие коммуникаторы в 5 раз эффективнее, чем слабые. Коммуникация считается краеугольным камнем проджект-менеджмента, а управление коммуникацией и стейкхолдер-менеджмент – двумя основными занятиями пиэма и областями его внимания. Согласно PMBOK, он тратит 90% времени на коммуникацию и 50% этого времени – на общение с командой. Соответственно, около 40% времени – на остальных стейкхолдеров.

 

Кто такие эти холдеры стейков?

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

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

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

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

 

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

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

  1. Детализация объема работ.
  2. Планирование и оценка.
  3. Разработка проектного графика.
  4. Планирование бюджета.
  5. Финализация плана и согласование.
  6. Мониторинг работ и контроль апдейтов.

 

Ступени стейкхолдер-менеджмента на протяжении проекта:

  1. Идентификация (в самом начале).
  2. Классификация (чтобы создать стратегию влияния).
  3. Коммуникация (чтобы на основе выбранной стратегии управлять взаимодействием, влиять и оценивать).

 

Для того чтобы понять стратегию и тактику коммуникации со стейкхолдерами, пиэму нужен стейкхолдер-маппинг (Stakeholder Mapping). Этот документ по разным причинам будет апдейтиться. Круг стейкхолдеров, вероятнее всего, изменится / увеличится по ходу планирования и реализации.

Матрица для идентификации стейкхолдеров, анализа и стратегирования

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

  1. Имя.
  2. Организация.
  3. Должность.
  4. Контакты.
  5. Уровень импакта (влияния). Отмечается в ячейках буквами H, L, M (high – высокий, medium – средний, low – низкий). Тут пиэм отвечает на вопросы: «Как сильно проект повлияет на стейкхолдера? Насколько проект значим для него?»
  6. Уровень вовлеченности. H, L, M (высокий, средний, низкий). Насколько сильно этот стейкхолдер может повлиять на проект? Дополнительно: каким может быть его вклад – что это за ресурсы или действия? Как много и часто он может вложить свои ресурсы в проект?
  7. Потребности/требования. Что важно и нужно этому стейкхолдеру? Например: акционеру – прибыль; спонсору – паблисити; потребителю – какая-то специфическая черта продукта; медиа – классный материал и т. д.
  8. Ожидания. Каких конкретных результатов ожидает стейкхолдер? Чего он ожидает по коммуникации и действиям? Что конкретно пиэм ожидает по действиям стейкхолдера и как этого достичь?
  9. Уровень и качество заинтересованности. К какому кругу относится стейкхолдер? 1. Союзники. 2. Поддерживающие. 3. Нейтральные. 4. Неохотно участвующие. 5. Оппоненты. По какому плану конвертировать или нейтрализовать 4 и 5?
  10. Влияние пиэма на стейкхолдера. Каков уровень влияния самого пиэма на этого стейкхолдера? 1. Если это внутренние стейкхолдеры, то уровень влияния обычно средний или высокий; пиэму доступны действия для прямого влияния. 2. Если это внешние стейкхолдеры, то уровень влияния обычно низкий или средний; такие стейкхолдеры могут решать вопросы, прыгая выше через пиэма).
  11. Возможные проблемы. При каких обстоятельствах и как именно этот стейкхолдер может заблокировать проект? Что пиэму доступно предпринять, чтобы предотвратить это? Как разблокировать, если это произойдет?
  12. Стратегия вовлечения в проект. Индивидуальна для каждого стейкхолдера.
  13. Коммуникация. Сколько раз и в какой период пиэм и стейкхолдер коммуницируют? Какие форматы оптимальны в данном случае? В каком виде дается фидбэк? В ячейках таблицы это может быть сформулировано так: «дискуссия 1 раз в месяц», «обмен информацией и фидбэком 1 раз в 6 месяцев» и т. д.

 

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

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

 

 

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

 

Как вовлечь стейкхолдеров в проект?

Вот тут все хорошо объяснено, посмотрите на Zillion экспресс-курс Анны Гроссман

.

 

 

Экспресс-курс:

Как вовлечь стейкхолдеров в проект. 6 шагов

zillion.net

Как подружиться со стейкхолдерами проекта

Энтони Мерсино, «Эмоциональный интеллект для менеджеров проектов. Практическое руководство». – М.: «Манн, Иванов и Фербер», 2018.

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

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

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

1) Определение стейкхолдеров нашего проекта.

2) Сбор и анализ информации о стейкхолдерах.

3) Развитие стратегий отношений.

4) Управление постоянными отношениями со стейкхолдерами.

Давайте рассмотрим каждый этап по порядку.

Определение стейкхолдеров проекта

Большинство проектных менеджеров знакомы со стейкхолдерами проекта и понимают их значимость. Для тех, кто незнаком с термином «стейкхолдер»: субъект, на который проект оказывает воздействие и который может помочь проекту или разрушить его. В этой области PMBOK® Guide (руководство, признанное в качестве стандарта управления проектами – Executive.ru) предлагает следующие рекомендации.

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

В PMBOK® Guide определены и описаны следующие группы стейкхолдеров, представленные в каждом проекте:

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

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

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

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

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

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

Стейкхолдеры проекта

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

<…>

Шаги действий по развитию отношений

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

1. Регулярные индивидуальные встречи

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

2. Адаптированные краткие отчеты по проекту

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

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

3. Встречи после работы

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

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

4. Регулярно вести рабочий журнал

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

5. Встречи за ланчем

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

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

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

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

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

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

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

Существует ряд параллелей между управлением отношениями со стейкхолдерами и управлением отношениями с клиентами (CRM). На сегодняшний день существует целая категория CRM-инструментов для управления клиентскими отношениями. В проектной среде каждого стейкхолдера можно рассматривать как клиента. Так же как компании адаптировали применение CRM в области управления клиентскими отношениями, проектным менеджерам следует относиться к отношениям со стейкхолдерами с должным вниманием.

Управление отношениями со стейкхолдерами

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

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

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

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

Вице-президент подразделения

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

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

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

Консалтинговая фирма

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

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

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

Вендор технологий

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

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

Концентрироваться только на проектной группе — досадная ошибка

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

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

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

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

Фото: vimeo.com

www.e-xecutive.ru

Стейкхолдер — Википедия. Что такое Стейкхолдер

Стейкхо́лдер (англ. stákeholder), заинтересованная сторона, причастная сторона — физическое лицо или организация, имеющая права, долю, требования или интересы относительно системы или её свойств, удовлетворяющих их потребностям и ожиданиям (ISO/IEC 15288:2008,[1]:4 ISO/IEC 29148:2011[2]:6).

Другие определения:

  • Физическое лицо, команда, организация или их классы, имеющие интерес в системе (ISO/IEC 42010:2011)[3]:2.
  • Физическое лицо, группа лиц или организация, которые могут влиять на систему или на которых может повлиять система (OMG Essence)[4]:5.
  • Лицо, группа или организация, которая может влиять, на которую могут повлиять или которая может воспринимать себя подвергнутой влиянию решения, операции или результата проекта (PMBoK)[5]:30.
  • Лицо или организация, которые могут воздействовать на осуществление деятельности или принятие решения, быть подверженными их воздействию или воспринимать себя в качестве последних (ISO 9000:2015)[6].

Стейкхолдеры обеспечивают возможности для системы и являются источником требований для системы.[4]:14

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

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

Взаимосвязь стейкхолдеров с другими сущностями инженерного проекта

Альфы инженерного проекта (OMG Essense)[4]

На рисунке показано взаимодействие основных сущностей и объектов, встречающихся в проекте. Объекты сгруппированы между собой в области интересов. Таким образом, стейкхолдер относится к области интересов клиента (англ. client), так как эта область содержит все, что касается использования и эксплуатации системы.[4]:13-14

Типы (группы) стейкхолдеров

Исчерпывающего списка типов (групп) стейкхолдеров не существует, так как для различных целевых систем они могут значительно отличаться. Можно привести примеры наиболее распространённых типов (групп) стейкхолдеров, которые упоминаются в стандартах (ГОСТ Р ИСО/МЭК 15288:2005, ISO/IEC 29148:2011, ГОСТ Р ИСО/МЭК 12207:2010, OMG Essence), Своде знаний по системной инженерии (SEBoK) и учебниках по системной инженерии[8]:

  • Приобретающая сторона, или покупатель (англ. acquirer) — организация или физическое лицо, которое приобретает или получает (англ. procures) продукт или услугу от поставщика.[2]:3[1]:2[9]:177 Приобретающей стороной может быть: покупатель, заказчик, владелец, оптовый покупатель.[10]
  • Заказчик, или клиент (англ. customer) — организация или физическое лицо, получающее продукт или услугу.[2]:4
  • Разработчик (англ. developer) — организация или физическое лицо, которое выполняет задачи разработки, включая анализ требований, проектирование, тестирование в течение всего жизненного цикла.[2]:4[10]
  • Поставщик (англ. supplier) — организация или физическое лицо, которое вступает в соглашение с приобретающей стороной на поставку продукта или услуги.[1]:4[10]
  • Пользователь (англ. user) — лицо или группа лиц, извлекающих пользу в процессе применения системы.[1]:4[10]
  • Производитель (англ.  producer) — представитель, ответственный за выполнение работы[4]:227; лицо, ответственное за выравнивание расписания, бюджета и ограниченность ресурсов, чтобы удовлетворить клиентам.[9]:743
  • Сопровождающая сторона (англ. maintainer) — организация или физическое лицо, выполняющее поддержку системы на одном или нескольких этапах жизненного цикла[1]; организация, которая осуществляет деятельность по сопровождению.[10]
  • Ликвидатор (англ. disposer) — организация или физическое лицо, выполняющее ликвидацию (изъятие и списание) рассматриваемой системы и связанных с нею эксплуатационных и поддерживающих служб.[1]
  • Аккредитор, или инспектор (англ. accreditor) — организация или физическое лицо, выполняющее проверку системы на соответствие требованиям в процессе сдачи системы в эксплуатацию.[8]
  • Регулирующий орган (англ. regulatory bodies) — организация или физическое лицо, проверяющее систему на соответствие требованиям в процессе эксплуатации.[8]
  • Остальные — персонал поддержки (англ. supporters), инструкторы (англ. trainers), операторы (англ. operators) и другие.

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

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

Таблица 1. Определение стейкхолдеров в соответствии со стадиями жизненного цикла системы[9]:262
Стадии жизненного циклаПримеры стейкхолдеров
Инженерия (проектирование, анализ)Приобретающая сторона, потенциальные пользователи, отдел маркетинга, отдел разработки, орган по стандартизации, поставщики, отдел тестирования (верификация и валидация), система производства и др.
РазработкаПриобретающая сторона, поставщики, проектировщики, команда по интеграции и др.
Передача в производство или в использованиеОтдел по контролю качества, система производства, операторы и др.
Логистика и сопровождениеВспомогательные сервисы, инструкторы, участники цепочек поставок и др.
ЭксплуатацияОбычные пользователи, случайные пользователи и др.
ЛиквидацияОператоры, подтверждающий орган и др.

Степень учёта и вовлечения стейкхолдеров

Согласно предложениям OMG выделяются 6 состояний, в которых может находиться проект с точки зрения учёта, вовлечения и удовлетворённости стейкхолдеров[4]:20-21:

  • Признаны (англ. Recognized) — стейкхолдеры были определены.
  • Представлены (англ. Represented) — согласованы методы привлечения стейкхолдеров и назначены представители от каждой группы стейкхолдеров.
  • Вовлечены (англ. Involved) — представители групп стейкхолдеров принимают активное участие в работе и выполняют свои обязанности.
  • В согласии (англ. In agreement) — представители стейкхолдеров находятся в согласии.
  • Удовлетворены для развёртывания (внедрения) (англ. Satisfied for deployment) — минимальные ожидания представителей стейкхолдеров были достигнуты.
  • Удовлетворены использованием (англ. Satisfied in use) — система удовлетворяет или превышает минимальные ожидания стейкхолдеров.

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

Таблица 2. Контрольные списки для стейкхолдеров[4]:22-23
СостояниеКонтрольный список
Признаны

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

Представлены

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

Вовлечены

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

В согласии

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

Удовлетворены для развёртывания (внедрения)

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

Удовлетворены использованием

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

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

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

Роль стейкхолдеров в управлении портфелем проектов

В стандарте ГОСТ Р ИСО/МЭК 12207:2010 (ISO/IEC 12207:2008) отмечено, что в механизме управления изменениями контракта необходимо отразить роли и ответственность руководства, уровень формализации заявок на предложенные изменения и дополнительных переговоров по контракту, а также связи со стейкхолдерами.[10]

В результате успешного управления портфелем проектов:

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

Роль стейкхолдеров в управлении качеством

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

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

Роль стейкхолдеров в управлении рисками

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

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

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

Роль стейкхолдеров в технических процессах

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

Роль стейкхолдеров в процессе определения требований

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

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

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

Процесс идентификации стейкхолдеров можно сформулировать как: идентификацию стейкхолдеров или классов стейкхолдеров, имеющих интерес к системе в процессе её жизненного цикла. Если непосредственная коммуникация невозможна, выбираются представители стейкхолдеров.[10]

Процесс идентификации требований состоит из решения следующих задач:

  1. Необходимо определить требования стейкхолдеров проекта. Требования стейкхолдеров могут проявляться в виде потребностей, пожеланий, требований, ожиданий или ограничений. В стандартах по качеству программных продуктов описывается модель качества продукции и требования к качеству, которые играют большую роль в определении требований стейкхолдеров.[11][12] Приобретающая сторона, а также возможности пользователей могут накладывать некоторые ограничения на систему, которые должны быть учтены в требованиях стейкхолдеров наряду с потребностями и пожеланиями. Для измерения и оценки требований ключевых стейкхолдеров рекомендуется устанавливать показатели результативности.
  2. Вследствие существующих организационных и технических решений возникают ограничения для системы. В проекте необходимо определить ограничения системы.
  3. Последовательность видов деятельности, бизнес-процессы определяются для установления рабочих сценариев и сценариев поддержки в условиях применения системы. Это необходимо для идентификации не выявленных требований, то есть требований, формально незаданных стейкхолдерами. При помощи рабочих сценариев и сценариев поддержки анализируются условия использования системы, необходимые для последующего проектирования.
  4. На этапе реализации необходимо учесть возможности и способности пользователей системы, а, следовательно, и накладываемые ограничения.
  5. В проекте необходимо учесть возможные неблагоприятные воздействия использования системы на здоровье и безопасность человека. Для этого устанавливаются определенные требования к здоровью, безопасности, окружающим условиям, защищенности и другим свойствам.[10]

Базовая линия

Спецификация или продукт (версия системы), которые были официально рассмотрены и согласованы с тем, чтобы впоследствии служить основой для дальнейшего развития, и которые могут быть изменены только посредством официальных и контролируемых процедур изменения.[3]:2 Часто употребляется как «базис», «утвержденная версия», «сданная в архив версия».

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

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

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

Примечания

  1. 1 2 3 4 5 6 7 ГОСТ Р ИСО/МЭК 15288, 2005.
  2. 1 2 3 4 ISO/IEC 29148, 2011.
  3. 1 2 ISO/IEC 42010, 2011.
  4. 1 2 3 4 5 6 7 OMG Essence, 2014.
  5. ↑ PMBoK, 2013.
  6. ↑ ГОСТ Р ИСО 9000, 2015.
  7. ↑ Tom Gilb. The Ten Most Powerful Systems Engineering Heuristics
  8. 1 2 3 4 Systems Engineering Principles and Practice, 2011.
  9. 1 2 3 SEBoK, 2012.
  10. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 ГОСТ Р ИСО/МЭК 12207, 2010.
  11. ↑ ИСО/МЭК 9126-1, 2001.
  12. ↑ ИСО/МЭК 25030, 2007.

Литература

  • Kossiakoff A., Sweet W. N., Seymour S. J., Biemer S. M. Systems Engineering Principles and Practice. — 2-е изд. — Hoboken, New Jersey: A John Wiley & Sons, 2011. — 599 с. — ISBN 978-0-470-40548-2.
  • Pyster, A., D. Olwell, N. Hutchison, S. Enck, J. Anthony, D. Henry, and A. Squires (eds). Guide to the Systems Engineering Body of Knowledge (SEBoK) version 1.0. — The Trustees of the Stevens Institute of Technology, 2012.
  • Руководство к Cводу знаний по управлению проектами (Руководство PMBOK). — 5-е изд. — Pennsylvania: Project Management Institute, Inc., 2013. — 614 с. — ISBN 978-1-62825-008-4.
  • ГОСТ Р ИСО 9000:2015. Системы менеджмента качества. Основные положения и словарь (см. ISO 9000:2015 «Quality management systems — Fundamentals and vocabulary»)
  • ГОСТ Р ИСО/МЭК 15288-2005 Информационная технология. Системная инженерия. Процессы жизненного цикла систем (см. ISO/IEC 15288:2008)
  • ГОСТ Р ИСО/МЭК 9126-1 Программная инженерия — Качество программного продукта — Часть 1: Модель качества (см. ISO/IEC 9126-1:2001 Software Engineering — Product quality — Part 1: Quality model)
  • ГОСТ Р ИСО/МЭК 25030 Программная инженерия — Требования и оценка качества программных продуктов — Требования к качеству (см. ISO/IEC 25030:2007 Software Engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Quality Requirements)
  • ГОСТ Р ИСО/МЭК 12207-2010 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств (см. ISO/IEC 12207:2008)
  • ISO/IEC 29148:2011 Systems and software engineering — Life cycle processes — Requirements engineering
  • ISO/IEC 42010:2011 System and software engineering — Architecture description
  • Object Management Group. Essence — Kernel and Language for Software Engineering Methods, Version 1.0, Beta 2. — 2014.

Ссылки

wiki.sc

это что такое? Виды стейкхолдеров :: BusinessMan.ru

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

Кто такие стейкхолдеры

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

• собственники, инвесторы, акционеры, клиенты и работники компании;
• партнеры по бизнесу.

Вторичный стейкхолдер – это дальний круг, оказывающий неявное влияние на бизнес:

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

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

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

Акционеры и инвесторы

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

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

Топ-менеджемент и сотрудники фирмы

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

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

Потребители, дилеры и партнеры

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

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

Поставщики и финансовые корпорации

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

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

Властные структуры и общественные группы

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

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

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

businessman.ru

Стейкхолдер — Википедия

Стейкхо́лдер (англ. stákeholder), заинтересованная сторона, причастная сторона — физическое лицо или организация, имеющая права, долю, требования или интересы относительно системы или её свойств, удовлетворяющих их потребностям и ожиданиям (ISO/IEC 15288:2008,[1]:4 ISO/IEC 29148:2011[2]:6).

Другие определения:

  • Физическое лицо, команда, организация или их классы, имеющие интерес в системе (ISO/IEC 42010:2011)[3]:2.
  • Физическое лицо, группа лиц или организация, которые могут влиять на систему или на которых может повлиять система (OMG Essence)[4]:5.
  • Лицо, группа или организация, которая может влиять, на которую могут повлиять или которая может воспринимать себя подвергнутой влиянию решения, операции или результата проекта (PMBoK)[5]:30.
  • Лицо или организация, которые могут воздействовать на осуществление деятельности или принятие решения, быть подверженными их воздействию или воспринимать себя в качестве последних (ISO 9000:2015)[6].

Стейкхолдеры обеспечивают возможности для системы и являются источником требований для системы.[4]:14

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

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

Взаимосвязь стейкхолдеров с другими сущностями инженерного проекта

Альфы инженерного проекта (OMG Essense)[4]

На рисунке показано взаимодействие основных сущностей и объектов, встречающихся в проекте. Объекты сгруппированы между собой в области интересов. Таким образом, стейкхолдер относится к области интересов клиента (англ. client), так как эта область содержит все, что касается использования и эксплуатации системы.[4]:13-14

Видео по теме

Типы (группы) стейкхолдеров

Исчерпывающего списка типов (групп) стейкхолдеров не существует, так как для различных целевых систем они могут значительно отличаться. Можно привести примеры наиболее распространённых типов (групп) стейкхолдеров, которые упоминаются в стандартах (ГОСТ Р ИСО/МЭК 15288:2005, ISO/IEC 29148:2011, ГОСТ Р ИСО/МЭК 12207:2010, OMG Essence), Своде знаний по системной инженерии (SEBoK) и учебниках по системной инженерии[8]:

  • Приобретающая сторона, или покупатель (англ. acquirer) — организация или физическое лицо, которое приобретает или получает (англ. procures) продукт или услугу от поставщика.[2]:3[1]:2[9]:177 Приобретающей стороной может быть: покупатель, заказчик, владелец, оптовый покупатель.[10]
  • Заказчик, или клиент (англ. customer) — организация или физическое лицо, получающее продукт или услугу.[2]:4
  • Разработчик (англ. developer) — организация или физическое лицо, которое выполняет задачи разработки, включая анализ требований, проектирование, тестирование в течение всего жизненного цикла.[2]:4[10]
  • Поставщик (англ. supplier) — организация или физическое лицо, которое вступает в соглашение с приобретающей стороной на поставку продукта или услуги.[1]:4[10]
  • Пользователь (англ. user) — лицо или группа лиц, извлекающих пользу в процессе применения системы.[1]:4[10]
  • Производитель (англ.  producer) — представитель, ответственный за выполнение работы[4]:227; лицо, ответственное за выравнивание расписания, бюджета и ограниченность ресурсов, чтобы удовлетворить клиентам.[9]:743
  • Сопровождающая сторона (англ. maintainer) — организация или физическое лицо, выполняющее поддержку системы на одном или нескольких этапах жизненного цикла[1]; организация, которая осуществляет деятельность по сопровождению.[10]
  • Ликвидатор (англ. disposer) — организация или физическое лицо, выполняющее ликвидацию (изъятие и списание) рассматриваемой системы и связанных с нею эксплуатационных и поддерживающих служб.[1]
  • Аккредитор, или инспектор (англ. accreditor) — организация или физическое лицо, выполняющее проверку системы на соответствие требованиям в процессе сдачи системы в эксплуатацию.[8]
  • Регулирующий орган (англ. regulatory bodies) — организация или физическое лицо, проверяющее систему на соответствие требованиям в процессе эксплуатации.[8]
  • Остальные — персонал поддержки (англ. supporters), инструкторы (англ. trainers), операторы (англ. operators) и другие.

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

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

Таблица 1. Определение стейкхолдеров в соответствии со стадиями жизненного цикла системы[9]:262
Стадии жизненного циклаПримеры стейкхолдеров
Инженерия (проектирование, анализ)Приобретающая сторона, потенциальные пользователи, отдел маркетинга, отдел разработки, орган по стандартизации, поставщики, отдел тестирования (верификация и валидация), система производства и др.
РазработкаПриобретающая сторона, поставщики, проектировщики, команда по интеграции и др.
Передача в производство или в использованиеОтдел по контролю качества, система производства, операторы и др.
Логистика и сопровождениеВспомогательные сервисы, инструкторы, участники цепочек поставок и др.
ЭксплуатацияОбычные пользователи, случайные пользователи и др.
ЛиквидацияОператоры, подтверждающий орган и др.

Степень учёта и вовлечения стейкхолдеров

Согласно предложениям OMG выделяются 6 состояний, в которых может находиться проект с точки зрения учёта, вовлечения и удовлетворённости стейкхолдеров[4]:20-21:

  • Признаны (англ. Recognized) — стейкхолдеры были определены.
  • Представлены (англ. Represented) — согласованы методы привлечения стейкхолдеров и назначены представители от каждой группы стейкхолдеров.
  • Вовлечены (англ. Involved) — представители групп стейкхолдеров принимают активное участие в работе и выполняют свои обязанности.
  • В согласии (англ. In agreement) — представители стейкхолдеров находятся в согласии.
  • Удовлетворены для развёртывания (внедрения) (англ. Satisfied for deployment) — минимальные ожидания представителей стейкхолдеров были достигнуты.
  • Удовлетворены использованием (англ. Satisfied in use) — система удовлетворяет или превышает минимальные ожидания стейкхолдеров.

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

Таблица 2. Контрольные списки для стейкхолдеров[4]:22-23
СостояниеКонтрольный список
Признаны

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

Представлены

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

Вовлечены

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

В согласии

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

Удовлетворены для развёртывания (внедрения)

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

Удовлетворены использованием

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

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

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

Роль стейкхолдеров в управлении портфелем проектов

В стандарте ГОСТ Р ИСО/МЭК 12207:2010 (ISO/IEC 12207:2008) отмечено, что в механизме управления изменениями контракта необходимо отразить роли и ответственность руководства, уровень формализации заявок на предложенные изменения и дополнительных переговоров по контракту, а также связи со стейкхолдерами.[10]

В результате успешного управления портфелем проектов:

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

Роль стейкхолдеров в управлении качеством

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

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

Роль стейкхолдеров в управлении рисками

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

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

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

Роль стейкхолдеров в технических процессах

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

Роль стейкхолдеров в процессе определения требований

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

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

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

Процесс идентификации стейкхолдеров можно сформулировать как: идентификацию стейкхолдеров или классов стейкхолдеров, имеющих интерес к системе в процессе её жизненного цикла. Если непосредственная коммуникация невозможна, выбираются представители стейкхолдеров.[10]

Процесс идентификации требований состоит из решения следующих задач:

  1. Необходимо определить требования стейкхолдеров проекта. Требования стейкхолдеров могут проявляться в виде потребностей, пожеланий, требований, ожиданий или ограничений. В стандартах по качеству программных продуктов описывается модель качества продукции и требования к качеству, которые играют большую роль в определении требований стейкхолдеров.[11][12] Приобретающая сторона, а также возможности пользователей могут накладывать некоторые ограничения на систему, которые должны быть учтены в требованиях стейкхолдеров наряду с потребностями и пожеланиями. Для измерения и оценки требований ключевых стейкхолдеров рекомендуется устанавливать показатели результативности.
  2. Вследствие существующих организационных и технических решений возникают ограничения для системы. В проекте необходимо определить ограничения системы.
  3. Последовательность видов деятельности, бизнес-процессы определяются для установления рабочих сценариев и сценариев поддержки в условиях применения системы. Это необходимо для идентификации не выявленных требований, то есть требований, формально незаданных стейкхолдерами. При помощи рабочих сценариев и сценариев поддержки анализируются условия использования системы, необходимые для последующего проектирования.
  4. На этапе реализации необходимо учесть возможности и способности пользователей системы, а, следовательно, и накладываемые ограничения.
  5. В проекте необходимо учесть возможные неблагоприятные воздействия использования системы на здоровье и безопасность человека. Для этого устанавливаются определенные требования к здоровью, безопасности, окружающим условиям, защищенности и другим свойствам.[10]

Базовая линия

Спецификация или продукт (версия системы), которые были официально рассмотрены и согласованы с тем, чтобы впоследствии служить основой для дальнейшего развития, и которые могут быть изменены только посредством официальных и контролируемых процедур изменения.[3]:2 Часто употребляется как «базис», «утвержденная версия», «сданная в архив версия».

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

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

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

Примечания

  1. 1 2 3 4 5 6 7 ГОСТ Р ИСО/МЭК 15288, 2005.
  2. 1 2 3 4 ISO/IEC 29148, 2011.
  3. 1 2 ISO/IEC 42010, 2011.
  4. 1 2 3 4 5 6 7 OMG Essence, 2014.
  5. ↑ PMBoK, 2013.
  6. ↑ ГОСТ Р ИСО 9000, 2015.
  7. ↑ Tom Gilb. The Ten Most Powerful Systems Engineering Heuristics
  8. 1 2 3 4 Systems Engineering Principles and Practice, 2011.
  9. 1 2 3 SEBoK, 2012.
  10. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 ГОСТ Р ИСО/МЭК 12207, 2010.
  11. ↑ ИСО/МЭК 9126-1, 2001.
  12. ↑ ИСО/МЭК 25030, 2007.

Литература

  • Kossiakoff A., Sweet W. N., Seymour S. J., Biemer S. M. Systems Engineering Principles and Practice. — 2-е изд. — Hoboken, New Jersey: A John Wiley & Sons, 2011. — 599 с. — ISBN 978-0-470-40548-2.
  • Pyster, A., D. Olwell, N. Hutchison, S. Enck, J. Anthony, D. Henry, and A. Squires (eds). Guide to the Systems Engineering Body of Knowledge (SEBoK) version 1.0. — The Trustees of the Stevens Institute of Technology, 2012.
  • Руководство к Cводу знаний по управлению проектами (Руководство PMBOK). — 5-е изд. — Pennsylvania: Project Management Institute, Inc., 2013. — 614 с. — ISBN 978-1-62825-008-4.
  • ГОСТ Р ИСО 9000:2015. Системы менеджмента качества. Основные положения и словарь (см. ISO 9000:2015 «Quality management systems — Fundamentals and vocabulary»)
  • ГОСТ Р ИСО/МЭК 15288-2005 Информационная технология. Системная инженерия. Процессы жизненного цикла систем (см. ISO/IEC 15288:2008)
  • ГОСТ Р ИСО/МЭК 9126-1 Программная инженерия — Качество программного продукта — Часть 1: Модель качества (см. ISO/IEC 9126-1:2001 Software Engineering — Product quality — Part 1: Quality model)
  • ГОСТ Р ИСО/МЭК 25030 Программная инженерия — Требования и оценка качества программных продуктов — Требования к качеству (см. ISO/IEC 25030:2007 Software Engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Quality Requirements)
  • ГОСТ Р ИСО/МЭК 12207-2010 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств (см. ISO/IEC 12207:2008)
  • ISO/IEC 29148:2011 Systems and software engineering — Life cycle processes — Requirements engineering
  • ISO/IEC 42010:2011 System and software engineering — Architecture description
  • Object Management Group. Essence — Kernel and Language for Software Engineering Methods, Version 1.0, Beta 2. — 2014.

Ссылки

wiki2.red

Стейкхолдер Википедия

Стейкхо́лдер (англ. stákeholder), заинтересованная сторона, причастная сторона — физическое лицо или организация, имеющая права, долю, требования или интересы относительно системы или её свойств, удовлетворяющих их потребностям и ожиданиям (ISO/IEC 15288:2008,[1]:4 ISO/IEC 29148:2011[2]:6).

Другие определения:

  • Физическое лицо, команда, организация или их классы, имеющие интерес в системе (ISO/IEC 42010:2011)[3]:2.
  • Физическое лицо, группа лиц или организация, которые могут влиять на систему или на которых может повлиять система (OMG Essence)[4]:5.
  • Лицо, группа или организация, которая может влиять, на которую могут повлиять или которая может воспринимать себя подвергнутой влиянию решения, операции или результата проекта (PMBoK)[5]:30.
  • Лицо или организация, которые могут воздействовать на осуществление деятельности или принятие решения, быть подверженными их воздействию или воспринимать себя в качестве последних (ISO 9000:2015)[6].

Стейкхолдеры обеспечивают возможности для системы и являются источником требований для системы.[4]:14

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

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

Взаимосвязь стейкхолдеров с другими сущностями инженерного проекта

Альфы инженерного проекта (OMG Essense)[4]

На рисунке показано взаимодействие основных сущностей и объектов, встречающихся в проекте. Объекты сгруппированы между собой в области интересов. Таким образом, стейкхолдер относится к области интересов клиента (англ. client), так как эта область содержит все, что касается использования и эксплуатации системы.[4]:13-14

Типы (группы) стейкхолдеров

Исчерпывающего списка типов (групп) стейкхолдеров не существует, так как для различных целевых систем они могут значительно отличаться. Можно привести примеры наиболее распространённых типов (групп) стейкхолдеров, которые упоминаются в стандартах (ГОСТ Р ИСО/МЭК 15288:2005, ISO/IEC 29148:2011, ГОСТ Р ИСО/МЭК 12207:2010, OMG Essence), Своде знаний по системной инженерии (SEBoK) и учебниках по системной инженерии[8]:

  • Приобретающая сторона, или покупатель (англ. acquirer) — организация или физическое лицо, которое приобретает или получает (англ. procures) продукт или услугу от поставщика.[2]:3[1]:2[9]:177 Приобретающей стороной может быть: покупатель, заказчик, владелец, оптовый покупатель.[10]
  • Заказчик, или клиент (англ. customer) — организация или физическое лицо, получающее продукт или услугу.[2]:4
  • Разработчик (англ. developer) — организация или физическое лицо, которое выполняет задачи разработки, включая анализ требований, проектирование, тестирование в течение всего жизненного цикла.[2]:4[10]
  • Поставщик (англ. supplier) — организация или физическое лицо, которое вступает в соглашение с приобретающей стороной на поставку продукта или услуги.[1]:4[10]
  • Пользователь (англ. user) — лицо или группа лиц, извлекающих пользу в процессе применения системы.[1]:4[10]
  • Производитель (англ.  producer) — представитель, ответственный за выполнение работы[4]:227; лицо, ответственное за выравнивание расписания, бюджета и ограниченность ресурсов, чтобы удовлетворить клиентам.[9]:743
  • Сопровождающая сторона (англ. maintainer) — организация или физическое лицо, выполняющее поддержку системы на одном или нескольких этапах жизненного цикла[1]; организация, которая осуществляет деятельность по сопровождению.[10]
  • Ликвидатор (англ. disposer) — организация или физическое лицо, выполняющее ликвидацию (изъятие и списание) рассматриваемой системы и связанных с нею эксплуатационных и поддерживающих служб.[1]
  • Аккредитор, или инспектор (англ. accreditor) — организация или физическое лицо, выполняющее проверку системы на соответствие требованиям в процессе сдачи системы в эксплуатацию.[8]
  • Регулирующий орган (англ. regulatory bodies) — организация или физическое лицо, проверяющее систему на соответствие требованиям в процессе эксплуатации.[8]
  • Остальные — персонал поддержки (англ. supporters), инструкторы (англ. trainers), операторы (англ. operators) и другие.

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

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

Таблица 1. Определение стейкхолдеров в соответствии со стадиями жизненного цикла системы[9]:262
Стадии жизненного циклаПримеры стейкхолдеров
Инженерия (проектирование, анализ)Приобретающая сторона, потенциальные пользователи, отдел маркетинга, отдел разработки, орган по стандартизации, поставщики, отдел тестирования (верификация и валидация), система производства и др.
РазработкаПриобретающая сторона, поставщики, проектировщики, команда по интеграции и др.
Передача в производство или в использованиеОтдел по контролю качества, система производства, операторы и др.
Логистика и сопровождениеВспомогательные сервисы, инструкторы, участники цепочек поставок и др.
ЭксплуатацияОбычные пользователи, случайные пользователи и др.
ЛиквидацияОператоры, подтверждающий орган и др.

Степень учёта и вовлечения стейкхолдеров

Согласно предложениям OMG выделяются 6 состояний, в которых может находиться проект с точки зрения учёта, вовлечения и удовлетворённости стейкхолдеров[4]:20-21:

  • Признаны (англ. Recognized) — стейкхолдеры были определены.
  • Представлены (англ. Represented) — согласованы методы привлечения стейкхолдеров и назначены представители от каждой группы стейкхолдеров.
  • Вовлечены (англ. Involved) — представители групп стейкхолдеров принимают активное участие в работе и выполняют свои обязанности.
  • В согласии (англ. In agreement) — представители стейкхолдеров находятся в согласии.
  • Удовлетворены для развёртывания (внедрения) (англ. Satisfied for deployment) — минимальные ожидания представителей стейкхолдеров были достигнуты.
  • Удовлетворены использованием (англ. Satisfied in use) — система удовлетворяет или превышает минимальные ожидания стейкхолдеров.

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

Таблица 2. Контрольные списки для стейкхолдеров[4]:22-23
СостояниеКонтрольный список
Признаны

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

Представлены

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

Вовлечены

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

В согласии

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

Удовлетворены для развёртывания (внедрения)

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

Удовлетворены использованием

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

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

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

Роль стейкхолдеров в управлении портфелем проектов

В стандарте ГОСТ Р ИСО/МЭК 12207:2010 (ISO/IEC 12207:2008) отмечено, что в механизме управления изменениями контракта необходимо отразить роли и ответственность руководства, уровень формализации заявок на предложенные изменения и дополнительных переговоров по контракту, а также связи со стейкхолдерами.[10]

В результате успешного управления портфелем проектов:

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

Роль стейкхолдеров в управлении качеством

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

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

Роль стейкхолдеров в управлении рисками

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

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

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

Роль стейкхолдеров в технических процессах

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

Роль стейкхолдеров в процессе определения требований

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

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

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

Процесс идентификации стейкхолдеров можно сформулировать как: идентификацию стейкхолдеров или классов стейкхолдеров, имеющих интерес к системе в процессе её жизненного цикла. Если непосредственная коммуникация невозможна, выбираются представители стейкхолдеров.[10]

Процесс идентификации требований состоит из решения следующих задач:

  1. Необходимо определить требования стейкхолдеров проекта. Требования стейкхолдеров могут проявляться в виде потребностей, пожеланий, требований, ожиданий или ограничений. В стандартах по качеству программных продуктов описывается модель качества продукции и требования к качеству, которые играют большую роль в определении требований стейкхолдеров.[11][12] Приобретающая сторона, а также возможности пользователей могут накладывать некоторые ограничения на систему, которые должны быть учтены в требованиях стейкхолдеров наряду с потребностями и пожеланиями. Для измерения и оценки требований ключевых стейкхолдеров рекомендуется устанавливать показатели результативности.
  2. Вследствие существующих организационных и технических решений возникают ограничения для системы. В проекте необходимо определить ограничения системы.
  3. Последовательность видов деятельности, бизнес-процессы определяются для установления рабочих сценариев и сценариев поддержки в условиях применения системы. Это необходимо для идентификации не выявленных требований, то есть требований, формально незаданных стейкхолдерами. При помощи рабочих сценариев и сценариев поддержки анализируются условия использования системы, необходимые для последующего проектирования.
  4. На этапе реализации необходимо учесть возможности и способности пользователей системы, а, следовательно, и накладываемые ограничения.
  5. В проекте необходимо учесть возможные неблагоприятные воздействия использования системы на здоровье и безопасность человека. Для этого устанавливаются определенные требования к здоровью, безопасности, окружающим условиям, защищенности и другим свойствам.[10]

Базовая линия

Спецификация или продукт (версия системы), которые были официально рассмотрены и согласованы с тем, чтобы впоследствии служить основой для дальнейшего развития, и которые могут быть изменены только посредством официальных и контролируемых процедур изменения.[3]:2 Часто употребляется как «базис», «утвержденная версия», «сданная в архив версия».

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

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

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

Примечания

  1. 1 2 3 4 5 6 7 ГОСТ Р ИСО/МЭК 15288, 2005.
  2. 1 2 3 4 ISO/IEC 29148, 2011.
  3. 1 2 ISO/IEC 42010, 2011.
  4. 1 2 3 4 5 6 7 OMG Essence, 2014.
  5. ↑ PMBoK, 2013.
  6. ↑ ГОСТ Р ИСО 9000, 2015.
  7. ↑ Tom Gilb. The Ten Most Powerful Systems Engineering Heuristics
  8. 1 2 3 4 Systems Engineering Principles and Practice, 2011.
  9. 1 2 3 SEBoK, 2012.
  10. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 ГОСТ Р ИСО/МЭК 12207, 2010.
  11. ↑ ИСО/МЭК 9126-1, 2001.
  12. ↑ ИСО/МЭК 25030, 2007.

Литература

  • Kossiakoff A., Sweet W. N., Seymour S. J., Biemer S. M. Systems Engineering Principles and Practice. — 2-е изд. — Hoboken, New Jersey: A John Wiley & Sons, 2011. — 599 с. — ISBN 978-0-470-40548-2.
  • Pyster, A., D. Olwell, N. Hutchison, S. Enck, J. Anthony, D. Henry, and A. Squires (eds). Guide to the Systems Engineering Body of Knowledge (SEBoK) version 1.0. — The Trustees of the Stevens Institute of Technology, 2012.
  • Руководство к Cводу знаний по управлению проектами (Руководство PMBOK). — 5-е изд. — Pennsylvania: Project Management Institute, Inc., 2013. — 614 с. — ISBN 978-1-62825-008-4.
  • ГОСТ Р ИСО 9000:2015. Системы менеджмента качества. Основные положения и словарь (см. ISO 9000:2015 «Quality management systems — Fundamentals and vocabulary»)
  • ГОСТ Р ИСО/МЭК 15288-2005 Информационная технология. Системная инженерия. Процессы жизненного цикла систем (см. ISO/IEC 15288:2008)
  • ГОСТ Р ИСО/МЭК 9126-1 Программная инженерия — Качество программного продукта — Часть 1: Модель качества (см. ISO/IEC 9126-1:2001 Software Engineering — Product quality — Part 1: Quality model)
  • ГОСТ Р ИСО/МЭК 25030 Программная инженерия — Требования и оценка качества программных продуктов — Требования к качеству (см. ISO/IEC 25030:2007 Software Engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Quality Requirements)
  • ГОСТ Р ИСО/МЭК 12207-2010 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств (см. ISO/IEC 12207:2008)
  • ISO/IEC 29148:2011 Systems and software engineering — Life cycle processes — Requirements engineering
  • ISO/IEC 42010:2011 System and software engineering — Architecture description
  • Object Management Group. Essence — Kernel and Language for Software Engineering Methods, Version 1.0, Beta 2. — 2014.

См. также

Теория стейкхолдеров

Ссылки

wikiredia.ru

Анализ заинтересованных сторон проекта: концепция и управление

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

Понятие заинтересованных лиц в проекте

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

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

  • PM;
  • команда проекта;
  • инвесторы;
  • общественные организации;
  • органы власти;
  • партнеры по бизнесу;
  • потребители;
  • конкуренты;
  • заказчик.

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

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

Состав stakeholders проекта и взаимосвязи с внешним и внутренним аспектом

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

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

Содержание концепции ЗС

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

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

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

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

У теории заинтересованных сторон большое число разработчиков, но основателем считается Р. Фриман (R. E. Freeman, Мичиганский университет, 1984 год). Концепция рассматривает взаимоотношения проекта как объекта управления с людьми, группами людей и организациями, интересы которых определяются самим проектным событием, его реалиями как таковыми. Сам проект и управление им превращается в особое абстрактное явление, некой совокупностью взаимодействий его stakeholders.

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

Модель идентификации значимости заинтересованных сторон

Процедуры первичного анализа ЗС

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

Основные заинтересованные лица проекта и их интересы

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

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

Анализ ЗС по модели Г. Саважа

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

Анализ проектного окружения на основе карты ЗС

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

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

Карта заинтересованных лиц и групп. Первый этап

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

Подводя промежуточный итог, стоит отметить, что первичная диагностика stakeholders, отмеченная на карте, позволяет установить степень влияния PM на заинтересованные стороны. Уровень влияния выражается числом линий связи. Вместе с тем, помимо влияния лидера проекта на ЗС, имеет место встречное влияние заинтересованных лиц на результаты проекта. И их также следует проанализировать и оценить.

Особого внимания заслуживают еще два вида экспертной оценки, реализуемой на втором этапе работы с картой. Ответственность за результаты также лежит на менеджере проекта. В первом случае оценивается в пределах от -5 до +5 сила поддержки или противодействия stakeholders проекту (параметр X). Во втором – уровень влияния стейкхолдера (параметр Y). Понимая, что и руководитель проекта сам является ключевым заинтересованным лицом, ему также дают аналогичную оценку. Как же изменится на втором этапе карта ЗС?

Карта заинтересованных лиц и групп. Второй этап

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

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

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

projectimo.ru

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *