Стейкхолдеры обеспечивают возможности для системы и являются источником требований для системы. [4] :14
Стейкхолдеров всегда на одного больше, чем вы знаете, а те, которых вы знаете, имеют минимум на одну потребность больше, чем вам сейчас известно.
В системной инженерии стейкхолдеры рассматриваются в контексте процесса принятия решений как люди или организации, зависящие от результатов принимаемых решений. Понимание того, кто является стейкхолдером по отношению к принимаемым решениям, должно быть установлено заранее. Очень часто этого не происходит — стейкхолдеры не определяются до принятия решений. Однако, как только решение будет объявлено или реализовано, все, кто хоть как-то был затронут этим решением, выскажут своё мнение. [8] :258
Содержание
Взаимосвязь стейкхолдеров с другими сущностями инженерного проекта [ | ]
На рисунке показано взаимодействие основных сущностей и объектов, встречающихся в проекте. Объекты сгруппированы между собой в области интересов. Таким образом, стейкхолдер относится к области интересов клиента (англ. client ), так как эта область содержит все, что касается использования и эксплуатации системы. [4] :13-14
Типы (группы) стейкхолдеров [ | ]
Исчерпывающего списка типов (групп) стейкхолдеров не существует, так как для различных целевых систем они могут значительно отличаться. Можно привести примеры наиболее распространённых типов (групп) стейкхолдеров, которые упоминаются в стандартах (ГОСТ Р ИСО/МЭК 15288:2005, ISO/IEC 29148:2011, ГОСТ Р ИСО/МЭК 12207:2010, OMG Essence), Своде знаний по системной инженерии (SEBoK) и учебниках по системной инженерии [8] :
Идентификация стейкхолдеров по стадиям жизненного цикла [ | ]
Каждая система имеет свои собственные стадии жизненного цикла, например, концептуальное проектирование, разработку, производство, внедрение, эксплуатацию и ликвидацию. Для каждой стадии определяется список всех стейкхолдеров, имеющих интерес (отношение) к будущей системе. Целью этого действия является рассмотрение точки зрения каждого стейкхолдера на всех стадиях жизненного цикла системы для утверждения полного набора потребностей стейкхолдеров, которые могут быть приоритизированы и преобразованы в требования стейкхолдеров. Примеры связи стейкхолдеров со стадиями жизненного цикла представлены в таблице 1.
Таблица 1. Определение стейкхолдеров в соответствии со стадиями жизненного цикла системы [10] :262
Стадии жизненного цикла
Примеры стейкхолдеров
Инженерия (проектирование, анализ)
Приобретающая сторона, потенциальные пользователи, отдел маркетинга, отдел разработки, орган по стандартизации, поставщики, отдел тестирования (верификация и валидация), система производства и др.
Разработка
Приобретающая сторона, поставщики, проектировщики, команда по интеграции и др.
Передача в производство или в использование
Отдел по контролю качества, система производства, операторы и др.
Логистика и сопровождение
Вспомогательные сервисы, инструкторы, участники цепочек поставок и др.
Эксплуатация
Обычные пользователи, случайные пользователи и др.
Ликвидация
Операторы, подтверждающий орган и др.
Степень учёта и вовлечения стейкхолдеров [ | ]
Согласно предложениям OMG выделяются 6 состояний, в которых может находиться проект с точки зрения учёта, вовлечения и удовлетворённости стейкхолдеров [4] :20-21 :
Для оценки текущего состояния проекта с точки зрения учёта, вовлечения и удовлетворённости стейкхолдеров предлагаются следующие контрольные списки:
Таблица 2. Контрольные списки для стейкхолдеров [4] :22-23
Состояние
Контрольный список
Определены
□ Идентифицированы все группы стейкхолдеров, которые на данный момент или в будущем будут затронуты разработкой и функционированием системы. □ Есть соглашение, какие группы стейкхолдеров должны быть представлены. Как минимум, учтены группы стейкхолдеров, которые финансируют, используют, поддерживают и обслуживают систему. □ Определены ответственности представителей стейкхолдеров.
□ Представители стейкхолдеров согласились выполнять свои обязанности. □ Представители стейкхолдеров уполномочены выполнять свои обязанности. □ Согласован подход к обеспечению сотрудничества среди представителей стейкхолдеров. □ Представители стейкхолдеров поддерживают и уважают технологию работы команды.
□ Представители стейкхолдеров помогают команде в соответствии со своими обязанностями. □ Представители стейкхолдеров обеспечивают обратную связь и принимают участие в принятии решений своевременно. □ Представители стейкхолдеров быстро сообщают изменения, которые имеют значение для их групп стейкхолдеров.
□ Представители стейкхолдеров пришли к согласию по минимальным ожиданиям от предстоящего внедрения новой системы. □ Представители стейкхолдеров довольны своим участием в работе. □ Представители стейкхолдеров согласны, что команда ценит и уважает их вклад в работу. □ Члены команды согласны, что представители стейкхолдеров ценят и уважают их вклад в работу. □ Представители стейкхолдеров согласны с тем, как их приоритеты и точки зрения уравновешаны, чтобы дать ясные указания для команды.
□ Представители стейкхолдеров обеспечивают обратную связь с точки зрения их групп стейкхолдеров. □ Представители стейкхолдеров подтверждают, что система готова для развёртывания (внедрения).
□ Стейкхолдеры используют новую систему и предоставляют обратную связь об их опыте. □ Стейкхолдеры подтверждают, что новая система соответствует их ожиданиям.
Роль стейкхолдеров в процессах организационного обеспечения проектов [ | ]
Организационное обеспечение проекта состоит из управления возможностями организаций поставлять и приобретать продукты и услуги через поддержку, инициализацию и управление проектами. Это обеспечение поставляет ресурсы и инфраструктуру необходимые для содействия проектам и гарантирует исполнение организационных целей и действующих соглашений. Оно не претендует на звание совокупности деловых процессов, составляющих управление деловой деятельностью организации. [11]
Роль стейкхолдеров в управлении портфелем проектов [ | ]
В стандарте ГОСТ Р ИСО/МЭК 12207:2010 (ISO/IEC 12207:2008) отмечено, что в механизме управления изменениями контракта необходимо отразить роли и ответственность руководства, уровень формализации заявок на предложенные изменения и дополнительных переговоров по контракту, а также связи со стейкхолдерами. [11]
В результате успешного управления портфелем проектов:
Роль стейкхолдеров в управлении качеством [ | ]
Организации необходимо выполнять периодические ревизии планов обеспечения качества проектов. Для каждого проекта устанавливаются различные цели в области качества, которые в свою очередь основываются на требованиях стейкхолдеров. [11]
Назначение ревизии заключается в поддержке общего со стейкхолдерами понимания развития относительно целей соглашения и того, что именно требуется сделать для помощи в обеспечении разработки продукта, удовлетворяющего стейкхолдеров. Ревизии применяются как в процессе управления проектом, так и на техническом уровне и проводятся в течение всей жизни проекта. [11]
Роль стейкхолдеров в управлении рисками [ | ]
Все части процесса управления рисками должны быть формализованы и документированы. Формализация и документирование процесса управления рисками содержат описание категорий риска, перспектив стейкхолдеров и описание (возможно посредством ссылки) технических и управленческих задач, допущений и ограничений. Необходимо устанавливать и поддерживать профиль рисков, каждая запись которого должна содержать важность риска. Важность определяется критериями риска, предоставленными стейкхолдерами.
Сущность соответствующего профиля рисков должна периодически сообщаться стейкхолдерам в зависимости от их потребностей, так как профиль рисков может изменяться в случае обновления отдельного состояния риска.
Стейкхолдерам необходимо предоставлять рекомендованные альтернативы обработки риска в требованиях на действия по отношению к риску. Если стейкхолдеры решают, что следует предпринять действия для того, чтобы сделать риск оптимальным, то должна быть реализована альтернатива обработки риска. Если стейкхолдеры принимают риск, который превышает максимальное значение, то этот риск должен рассматриваться как высоко приоритетный и постоянно контролироваться для определения необходимых будущих действий по его обработке. [11]
Роль стейкхолдеров в технических процессах [ | ]
Технические процессы используются для формулирования требований к системе, модификации этих требований в эффективный продукт, позволяющий осуществлять, при необходимости, устойчивое повторное производство этого продукта, использовать его для обеспечения требуемых услуг, поддерживать обеспечение этими услугами и ликвидировать продукт, когда он изымается из обращения. [1] :19 Технические процессы определяют содержание работ, которые позволяют в рамках задач предприятия и проекта увеличить прибыли и минимизировать риски, возникающие в процессе принятия технических решений и осуществления соответствующих действий.
Роль стейкхолдеров в процессе определения требований [ | ]
В стандарте о процессах жизненного цикла программных систем задача определения требований стейкхолдеров формулируется, как: определение требований к системе, выполнение которых может обеспечивать предоставление услуг, необходимых пользователям и другим стейкхолдерам в заданной среде применения. Этот процесс позволяет определять стейкхолдеров или классы стейкхолдеров, связанных с системой на протяжении всего её жизненного цикла. Кроме того выделяются их потребности и пожелания. В процессе потребности и пожелания анализируются и модифицируются в общую совокупность требований стейкхолдеров, описывающих желаемое поведение системы в процессе взаимодействия со средой применения. Относительно этой совокупности каждая предоставляемая услуга подвергается валидации для подтверждения того, что система полностью удовлетворяет заявленным требованиям. [11]
Результатами успешного осуществления процесса определения требований стейкхолдеров является:
Процесс идентификации стейкхолдеров можно сформулировать как: идентификацию стейкхолдеров или классов стейкхолдеров, имеющих интерес к системе в процессе её жизненного цикла. Если непосредственная коммуникация невозможна, выбираются представители стейкхолдеров. [11]
Процесс идентификации требований состоит из решения следующих задач:
Спецификация или продукт (версия системы), которые были официально рассмотрены и согласованы с тем, чтобы впоследствии служить основой для дальнейшего развития, и которые могут быть изменены только посредством официальных и контролируемых процедур изменения. [3] :2 Часто употребляется как «базис», «утвержденная версия», «сданная в архив версия».
В проекте необходимо совместно со стейкхолдерами определять корректность выражения их требований. Для этого необходимо обеспечить обратную связь от разработчиков к стейкхолдерам, чтобы гарантировать правильное понимание устанавливаемых требований. Также необходимо обсуждать и достигать согласия по противоречивым и неосуществимым требованиям стейкхолдеров. В проекте должны регистрироваться требования стейкхолдеров в форме, приемлемой для управления требованиями в течение жизненного цикла и за его пределами. Эти записи устанавливают базовую линию требований стейкхолдеров и сохраняют информацию об изменениях в потребностях и их происхождении в течение жизненного цикла системы.
В проекте должен прослеживаться источник возникновения потребностей от требований стейкхолдеров. Требования стейкхолдеров проверяются в моменты принятия ключевых решений в процессе жизненного цикла для гарантии того, что учитываются любые изменения потребностей. [11] Ограничения в системе могут возникать в результате:
причастная сторона Любой индивидуум, группа или организация, которые могут воздействовать на риск, подвергаться воздействию или ощущать себя подверженными воздействию риска. Примечания 1. Лицо, принимающее решение, также является причастной стороной. 2. Причастная сторона включает в себя заинтересованную сторону, но имеет более широкое значение, чем заинтересованная сторона. [ ГОСТ Р 51897-2002]
Тематики
Обобщающие термины
3.19 причастная сторона (stakeholder): Любой индивидуум, группа или организация, которые могут воздействовать на риск, подвергаться воздействию или ощущать себя подверженными воздействию риска.
1 Лицо, принимающее решение, также является причастной стороной.
2 Причастная сторона включает в себя заинтересованную сторону, но имеет более широкое значение, чем заинтересованная сторона
[ИСО/МЭК Руководство 73:2002, пункт 3.2.1]
2.11 причастная сторона (stakeholder): Сторона (лицо или организация), имеющая право, долю, интерес или притязания на систему или на владение ее характеристиками, удовлетворяющими потребности и ожидания этой стороны.
2.38 причастная сторона (stakeholder): Любой индивидуум, группа или организация, которые могут воздействовать на риск, подвергаться воздействию или ощущать себя подверженными воздействию риска.
1 Лицо, принимающее решение, также является причастной стороной.
2 Причастная сторона включает в себя заинтересованную сторону, но имеет более широкое значение, чем заинтересованная сторона.
2.32 причастная сторона (stakeholder): Любой индивидуум, группа или организация, которые могут воздействовать на риск, подвергаться воздействию или ощущать себя подверженными воздействию риска.
1. Лицо, принимающее решение, также является причастной стороной.
2. Причастная сторона включает в себя заинтересованную сторону, но имеет более широкое значение, чем заинтересованная сторона
[ИСО/МЭК Руководство 73:2009].
3.27 причастная сторона (stakeholder): Любой индивидуум, группа или организация, которые могут воздействовать на риск, подвергаться воздействию или ощущать себя подверженными воздействию риска.
3.3 причастная сторона (stakeholder): Любой индивидуум, группа или организация, которые могут воздействовать на риск, подвергаться воздействию или ощущать себя подверженными воздействию риска.
2 причастная сторона
причастная сторона Любой индивидуум, группа или организация, которые могут воздействовать на риск, подвергаться воздействию или ощущать себя подверженными воздействию риска. Примечания 1. Лицо, принимающее решение, также является причастной стороной. 2. Причастная сторона включает в себя заинтересованную сторону, но имеет более широкое значение, чем заинтересованная сторона. [ ГОСТ Р 51897-2002]
Тематики
Обобщающие термины
3 причастная сторона
См. также в других словарях:
причастная сторона — Любой индивидуум, группа или организация, которые могут воздействовать на риск, подвергаться воздействию или ощущать себя подверженными воздействию риска. Примечания 1. Лицо, принимающее решение, также является причастной стороной. 2. Причастная… … Справочник технического переводчика
причастная сторона — 3.19 причастная сторона (stakeholder): Любой индивидуум, группа или организация, которые могут воздействовать на риск, подвергаться воздействию или ощущать себя подверженными воздействию риска. Примечания 1 Лицо, принимающее решение, также… … Словарь-справочник терминов нормативно-технической документации
причастная сторона 1) (заинтересованная сторона) — 3.45 причастная сторона1) (заинтересованная сторона) (stakeholder (interested party)): Лицо или группа лиц, заинтересованных в деятельности или достижениях организации. Примечание Причастной стороной являются потребители, партнеры, персонал,… … Словарь-справочник терминов нормативно-технической документации
ГОСТ Р 51897-2002: Менеджмент риска. Термины и определения — Терминология ГОСТ Р 51897 2002: Менеджмент риска. Термины и определения оригинал документа: 3.3.2 анализ риска: Систематическое использование информации для определения источников и количественной оценки риска. Определения термина из разных… … Словарь-справочник терминов нормативно-технической документации
ГОСТ Р ИСО/МЭК 16085-2007: Менеджмент риска. Применение в процессах жизненного цикла систем и программного обеспечения — Терминология ГОСТ Р ИСО/МЭК 16085 2007: Менеджмент риска. Применение в процессах жизненного цикла систем и программного обеспечения оригинал документа: 3.3 вероятность (probability): Мера того, что событие может произойти. Примечания 1 ИСО 3534 1 … Словарь-справочник терминов нормативно-технической документации
ГОСТ Р 53647.2-2009: Менеджмент непрерывности бизнеса. Часть 2. Требования — Терминология ГОСТ Р 53647.2 2009: Менеджмент непрерывности бизнеса. Часть 2. Требования оригинал документа: 2.12 анализ воздействия на бизнес (business impact analysis): Процесс исследования функционирования бизнеса и последствий воздействия на… … Словарь-справочник терминов нормативно-технической документации
ГОСТ Р 53647.1-2009: Менеджмент непрерывности бизнеса. Часть 1. Практическое руководство — Терминология ГОСТ Р 53647.1 2009: Менеджмент непрерывности бизнеса. Часть 1. Практическое руководство оригинал документа: 2.8 анализ воздействия на бизнес (business impact analysis): Процесс исследования функционирования бизнеса и последствий… … Словарь-справочник терминов нормативно-технической документации
ГОСТ Р 53647.4-2011: Менеджмент непрерывности бизнеса. Руководящие указания по обеспечению готовности к инцидентам и непрерывности деятельности — Терминология ГОСТ Р 53647.4 2011: Менеджмент непрерывности бизнеса. Руководящие указания по обеспечению готовности к инцидентам и непрерывности деятельности оригинал документа: 3.6 авария2) (emergency): Внезапное, экстренное, обычно неожиданное… … Словарь-справочник терминов нормативно-технической документации
Р 50.1.070-2009: Менеджмент риска. Рекомендации по внедрению. Часть 3. Обмен информацией и консультации — Терминология Р 50.1.070 2009: Менеджмент риска. Рекомендации по внедрению. Часть 3. Обмен информацией и консультации: 3.4 заинтересованная сторона (interested party): Лицо или группа лиц, заинтересованные в деятельности или успехе организации.… … Словарь-справочник терминов нормативно-технической документации
ГОСТ Р ИСО 9241-210-2012: Эргономика взаимодействия человек-система. Часть 210. Человеко-ориентированное проектирование интерактивных систем — Терминология ГОСТ Р ИСО 9241 210 2012: Эргономика взаимодействия человек система. Часть 210. Человеко ориентированное проектирование интерактивных систем оригинал документа: 2.17 валидация (validation): Подтверждение посредством предоставления… … Словарь-справочник терминов нормативно-технической документации
Р 50.1.068-2009: Менеджмент риска. Рекомендации по внедрению. Часть 1. Определение области применения — Терминология Р 50.1.068 2009: Менеджмент риска. Рекомендации по внедрению. Часть 1. Определение области применения: 3.13 анализ риска (risk analysis): Систематическое использование информации для определения источников и количественной оценки… … Словарь-справочник терминов нормативно-технической документации
Р 50.1.068-2009: Менеджмент риска. Рекомендации по внедрению. Часть 1. Определение области применения
Терминология Р 50.1.068-2009: Менеджмент риска. Рекомендации по внедрению. Часть 1. Определение области применения:
3.13 анализ риска (risk analysis): Систематическое использование информации для определения источников и количественной оценки риска.
1 Анализ риска обеспечивает основу для проведения оценки риска и принятия решений об обработке риска.
2 Информация может включать в себя исторические данные, результаты теоретического анализа, информированное мнение и касаться причастных сторон.
3.3 вероятность (probability): Действительное число в интервале от 0 до 1, относящееся к случайному событию.
1 Число может отражать относительную частоту в серии наблюдений или степень уверенности в том, что некоторое событие произойдет. Для высокой степени уверенности вероятность близка к единице.
2 Вероятность события А обозначают Рr(А) или Р(А).
3.14 идентификация риска (risk identification): Процесс определения риска, составления перечня риска и описания каждого из элементов риска.
3.15 количественная оценка риска (risk estimation): Процесс присвоения значений вероятности и последствий риска.
3.8 критерии риска (risk criteria): Правила оценки значимости риска (3.1).
3.9 менеджмент риска (risk management): Скоординированные действия по руководству и управлению организацией в отношении риска, которые направлены на реализацию потенциальных возможностей организации и снижение негативных последствий опасных событий.
3.25 мониторинг (monitor): Проверка, наблюдение, критический обзор или измерение процесса деятельности, действий или системы через запланированные интервалы времени, направленные на идентификацию отличий между наблюдаемым и требуемым или ожидаемым уровнем выполнения деятельности.
3.17 обработка риска (risk treatment): Процесс выбора и осуществления мер по модификации или сокращению риска (3.1).
1 Термин «обработка риска» иногда используют для обозначения самих мер.
2 Меры по обработке риска могут включать в себя сокращение, разделение или сохранение риска.
3.6 опасность (hazard): Потенциальный источник возникновения ущерба.
3.26 организация (organization): Группа работников и необходимых средств с распределением ответственности, полномочий и взаимоотношений.
1 Распределение обычно бывает упорядоченным.
2 Организация может быть государственной или частной.
3 Настоящее определение действует применительно к стандартам на системы менеджмента качества. Термин «организация» определен по-другому в руководстве ИСО/МЭК 2 [1].
3.23 остаточный риск (residual risk): Риск (3.1), остающийся после обработки риска (3.19).
3.12 оценка риска (risk assessment): Общий процесс идентификации (3.14), анализа риска (3.13) и проведения сравнительной оценки риска (3.16).
3.24 оценка управления (control assessment): Систематический анализ процессов управления, направленный на обеспечение их эффективности и результативности соответствия используемых средств управления риском (3.18).
3.2 последствие (consequence): Результат события (3.4).
1 Результатом события может быть одно или более последствий.
2 Последствия могут быть как позитивными, так и негативными.
3 Последствия могут быть выражены качественно или количественно.
4 Последствия рассматривают относительно достижения поставленных целей.
3.7 потери (loss): Любое негативное финансовое последствие (3.1).
3.20 предотвращение риска (risk avoidance): Решение не быть вовлеченным в ситуацию, связанную с риском, или действие, предупреждающее вовлечение в нее.
3.27 причастная сторона (stakeholder): Любой индивидуум, группа или организация, которые могут воздействовать на риск, подвергаться воздействию или ощущать себя подверженными воздействию риска.
3.11 процесс менеджмента риска (risk management process): Систематические действия по управлению политикой, процедурами и методами, направленными на обмен информацией, установление целей применения, идентификацию, оценку, обработку, мониторинг и анализ риска (3.1).
3.21 разделение риска (risk sharing): Разделение с другой стороной количественно определенных потерь или получения преимуществ от конкретного вида риска (3.1).
1 Законодательные и обязательные требования могут ограничить, запретить или передать под особый контроль разделение небольшого количества рисков.
2 Разделение риска может быть выполнено через страхование или другие соглашения.
3 Разделение риска может создать новый риск или изменить существующий.
3.1 риск (risk): Сочетание вероятности события и его последствий.
1 Термин «риск» используют обычно тогда, когда существует возможность негативных последствий.
2 В некоторых ситуациях риск обусловлен возможностью отклонения от ожидаемого результата или события.
3 Применительно к безопасности см. ГОСТ Р 51898.
3.10 система менеджмента риска (risk management system): Набор элементов системы менеджмента организации в отношении менеджмента риска (3.9).
1 Элементы системы менеджмента риска могут включать в себя стратегическое планирование, принятие решений и другие стратегии, процессы и методы, затрагивающие риск.
2 Культура организации обычно отражается в ее системе менеджмента риска.
3.19 снижение риска (risk reduction): Действия, предпринятые для уменьшения вероятности (3.3), негативных последствий (3.2) или того и другого вместе, связанных с риском (3.1).
3.4 событие (event): Возникновение специфического набора обстоятельств, при которых происходит явление.
1 Событие может быть определенным или неопределенным.
2 Событие может быть единичным или многократным.
3 Вероятность, связанная с событием, может быть оценена для данного интервала времени.
3.22 сохранение риска (risk retention): Принятие бремени потерь или выгод от конкретного риска (3.1).
1 Сохранение риска включает в себя принятие рисков, которые не были идентифицированы.
2 Уровень сохраненного риска может зависеть от критериев риска (3.8).
3.16 сравнительная оценка риска (risk evaluation): Процесс сравнения количественной оценки риска с установленными критериями риска для определения значимости риска.
1 Сравнительная оценка риска может быть использована для содействия решениям по принятию или обработке риска.
2 Применительно к безопасности см. ГОСТ Р 51898.
3.18 управление риском (risk control): Существующий процесс, политика, практика или другие виды деятельности, направленные на минимизацию отрицательных последствий риска или увеличение положительных возможностей организации.
3.5 частота (frequency): Число наступлений события данного типа или число наблюдений, попавших в данный класс.
