3.1. Понятие «стейкхолдер». Виды стейкхолдеров. Группы стейкхолдеров


3.1. Понятие «стейкхолдер». Виды стейкхолдеров

Лекция 3. Диалог со стейкхолдерами как основной принцип корпоративной социальной ответственности

Вопрос диалога со стейкхолдерами является важным для эффективного развития компаний, однако он недостаточно раскрыт в контексте современного бизнеса при украинских реалиях. Учет интересов заинтересованных сторон (стейкхолдеров) при разработке и внедрении политики социальной ответственности остается в Украине достаточно низким, о чем свидетельствует исследование Центра «Развитие КСО», проведенное в мае в 2010 г. Чаще компании учитывают интересы потребителей (84%) и органов государственной власти (57%), реже - негосударственных организаций (14%) и исследовательских организаций, учебных заведений (20%), организаций бизнеса (21%).

Таблица 3.1.

Распределение ответов «учитывает ли на вопрос ваша компания при разработке и внедрении политики социальной ответственности интересы таких заинтересованных сторон» (N = 600)

Да

Нет

Органов государственной власти

57,0

43,0

Коммерческих организаций/бизнес-организаций

21,4

78,6

Профсоюзов или других объединений работников

29,6

70,4

Потребителей

84,5

15,5

Негосударственных организаций

13,8

86,2

Исследовательских организаций, учебных заведений

19,9

80,1

Основным источником идей для разработки и внедрения программ/мероприятий по социальной ответственности для подавляющего большинства украинских предприятий (71%) есть руководство компании. На каждом четвертом украинском предприятии (27,5%) предложения для разработки и внедрения программ/мероприятий по социальной ответственности выдвигают рабочие компании. Меньше всего украинские предприятия получают предложения или идеи от органов местной власти (18%), общественности (13%) и бизнес партнеров (5%). Для каждого десятого украинского предприятия (10%) источник идей для внедрения социальной ответственности - случайная информация (СМИ).

Распределение ответов на вопрос «С кем вы сотрудничаете, когда разрабатываете ваши программы/мероприятия по социальной ответственности (N=404) »

Разрабатываем и осуществляем самостоятельно 77,4

Местная власть 29,6

Бизнес партнеры 8,0

Средства массовой информации 5,9

PR или рекламные агентства 2,2

Директор детского дома 1,4

Негосударственные (неприбыльные) организации 0,5

Научные (специализированные) заведения 0,4

Международные организации 0,2

Как правило, при разработке и реализации програм\ мероприятий по социальной ответственности организации сотрудничают с теми, кто стал основным источником идей. Подавляющее большинство украинских компаний (77%) самостоятельно разрабатывают и осуществляют программы/мероприятия по социальной ответственности. Почти треть (29,6%) украинских компаний при разработке программ/мероприятий по социальной ответственности сотрудничает с органами местной власти, 8% - с бизнес партнерами. Уровень сотрудничества с другими заинтересованными сторонами - общественным организациями, СМИ, научными (специализированными) заведениями - практически отсутствует.

Впервые понятие «стейкхолдери» было использовано в 1963 году в Стенфордском исследовательском институте. Позже эта теория была развита Эдвардом Фрименом, профессором по бизнес-администрированию университета Вирджиния, в 80-х годах. С того времени, она получила распространение в корпоративной среде, особенно в теориях и практиках стратегического менеджмента, корпоративного управления и корпоративной социальной ответственности. Теперь понятие расширилось [7]. Большинство отношений между компаниями и отмеченными выше группами стейкхолдеров закреплено и регламентировано юридическими документами, соглашениями, законами страны присутствия компании, а также международными документами (Декларация прав человека, Международный пакт об экономических, социальных и культурных правах, конвенциях международной организации труда). В «Зеленой книге» ЕС отмечено, что все заинтересованные стороны имеют право быть услышанным.

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

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

Основные группы заинтересованных сторон для компаний продемонстрированы в таб. 3.2.

Таблица 3.2.

Основные группы заинтересованных сторон

Работники и их обьединения

Клиенты и потребители

Государственные органы

Акционеры, инвесторы, рейтинговые агентства

Финансовое сообщество

Правительственные, профессиональные организации, общественные и международные организации

Инвесторы

Национальное и локальное общество

Гражданское общество

НУО и ассоциации

Поставщики

Медиа, тренинговые агентства, консультационные компании

Вышеприведенный перечень стейкхолдеров не ограничивается лишь отмеченными выше группами. К нему могут входить и другие заинтересованы стороны, которые определяются компанией в зависимости от ее деятельности. Например, компания Coca-Cola в Украине имеет перечень, который состоит из свыше 40 заинтересованных сторон. Компания «Ново Нордиск» (датская фармацевтическая компания с представительством в Украине) определила для себя 12 главных стейкхолдеров.

studfiles.net

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

Глобальное исследование, проведенное в 2006 году компанией Interbrand и журналом Business Week, показало, что стоимость «неосязаемых ценностей» — торговой марки, бренда компании и т. д. может составлять до 70% ее рыночной капитализации. Снижение индекса репутации всего на 1% вызывает падение ее рыночной стоимости на 3%…

Сегодня позиция компании на рынке зависит уже не только от объемов произведенной продукции или торгового оборота, но и от восприятия ее деятельности потребителями, СМИ, представителями государственной и муниципальной власти, акционерами, сотрудниками и др. С каждым годом необходимость коммуникации с этими группами осознается бизнесом как все более важная управленческая задача. Эти изменения нашли отражение в новом понятии «стейкхолдер-менеджмент» (Stakeholder Management) — управление отношениями с заинтересованными группами.

Основное определение нового понятия дал Р. Е. Фриман (R. E. Freeman) в 1984 году: «Стейкхолдер — это группа (индивидуум), которая может оказать влияние на достижение организацией своих целей или на работу организации в целом».

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

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

Рис. 1. Заинтересованные группы корпорации

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

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

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

Рис. 2. Связь между отношениями внутренних стейкхолдеров и получением преимущества перед конкурентами

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

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

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

Рис. 3. Важность управления доверием заинтересованных групп

Особый интерес к проблемам, связанным с репутацией, проявляют финансовые структуры, компании, работающие в сфере услуг и крупные финансово-промышленные группы. В Украине пока очень мало специалистов в этой области, поэтому пример компании TNS, которая с 1990 года накопила большой опыт в этой области, будет интересен для отечественного бизнеса.

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

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

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

Во многих странах используют разработанную компанией TNS систему оценки репутации TRI*M. Среди ее инструментов, например, есть репутационный индекс (TRI*M Index). Это разработанный и стандартизированный нами инструмент, который позволяет сравнить отношение к компании различных групп. Методика TRI*M позволяет выявить и оценить факторы, которые влияют на репутацию данной организации, увидеть ее слабые и сильные стороны. Результаты такого анализа можно представить наглядно — в виде графика-«сетки» TRI*M (рис. 4). Эти данные помогают руководству компании сориентироваться — с чего, собственно говоря, начинать «лечить» репутацию.

Рис. 4. «Сетка» TRI*M. «Сеточный» анализ определяет рычаги управления репутацией

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

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

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

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

Такое понятие, как репутация, безусловно, важно для всех компаний, но особенно ценно оно для финансового сектора. Компания TNS уже провела более девяти тысяч исследований банков и страховых компаний в 90 странах мира, мы имеем огромные базы данных, ведем так называемые Benchmark Numbers (показатели индекса, которые могут быть использованы для сравнительного конкурентного анализа). Благодаря этим базам данных мы можем, работая с каждым клиентом, оценивать его показатели в динамике или сравнивать с региональными, отраслевыми и другими показателями.

Например, мы можем сравнить и проанализировать результаты многочисленных исследований для банковской сферы, которые проводились по всему миру (рис. 5, 6). Что же показали полученные результаты? На рисунках видно, что по уровню доверия к банкам страны делятся на различные группы: в Дании (81), США (73), Южно-Африканской Республике (71) население в целом с большим доверием относится к банковской системе, а вот в Японии (22), Аргентине (28) и Китае (31) доверие к банкам очень низкое. Успешность ведения бизнеса в конкретной стране зависит от отношения ее населения к определенному сектору экономики, на это нужно обращать внимание. Результаты исследований мы стараемся валидизировать, оцениваем, насколько эти показатели повлияют на развитие бизнеса клиента, каких показателей ему нужно достичь.

Рис. 5, 6. Репутация основных банков в стране

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

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

Приведем другой пример из этого сектора — одна из норвежских страховых компаний, которая намеревалась выйти на рынок пенсионных услуг (рис. 7). В Норвегии принята система государственного пенсионного обеспечения, но к сумме государственной пенсии за время работы можно и нужно добавлять личные сбережения. Для того чтобы прогнозировать успешность деятельности в новом для нее сегменте, компания решила оценить свою репутацию в глазах ключевых заинтересованных групп. Главная группа для этого бизнеса — все общество Норвегии, а целевая, на которую компании следует обратить внимание, — 36% работающих граждан, не имеющих дополнительной пенсии. К сожалению, индекс доверия к этому нашему клиенту составляет всего 36. Имея такую низкую оценку репутации, построить успешный бизнес шансов немного…

Рис. 7. «Репутационный радар» TRI*M (норвежская страховая компания)

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

Внутренние изменения в компании влияют на репутационный индекс. На рисунке 8 видно, что с 2002-го по 2004 год банк развивался, соответственно, повышался его рейтинг. Затем развитие несколько затормозилось, а теперь и вовсе остановилось. Мы выяснили, что наибольшие потери принес уход ряда корпоративных клиентов — компаний малого и среднего бизнеса. Сравнение банка с основными конкурентами рынка (рис. 9) показывает, что его показатели значительно упали.

Рис. 8. Шведский банк (динамика индекса удовлетворенности клиентов за 2002–2006 годы)

 

Рис. 9. Сравнение основных банков и средних показателей рынка

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

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

  • Как вы чувствуете себя в банке? Насколько вы удовлетворены его работой?

  • Будете ли вы рекомендовать банк своим коллегам, знакомым, друзьям, насколько вы хотите, чтобы ваши друзья были клиентами этого банка?

  • Хотите ли вы продолжать иметь дело с этим банком?

  • Отдаете ли вы этому банку предпочтение перед другими?

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

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

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

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

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

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

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

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

Кроме того, мы опросили сотрудников:

  • Насколько они загружены работой?

  • Имеют ли достаточно свободного времени или систематически перерабатывают?

  • Сами ли определяют свою рабочую нагрузку — или объем работ задается им директивно?

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

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

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

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

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

Рис. 10. Унифицированный шаблон действий

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

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

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

Что мы сделали для этого клиента? Собрали информацию о компании, рассчитали для нее репутационный индекс — на тот момент он составил 57. Обратившись к нашей базе данных, сравнили показатели этой компании с другими: ее главный конкурент № 1 имел такой же индекс, конкурент № 2 — 47, при этом средний индекс по всем компаниям группы составлял 58. В принципе, ситуация была не самой плохой, однако из общения с топ-менеджерами мы выяснили, что они хотят повысить свой репутационный индекс до 82, то есть войти в десятку лучших. С этой точки зрения компания находится очень далеко от позиции, на которую претендует.

Посмотрим, как к ней относятся разные заинтересованные группы: ученые — позитивно (показатель — 69), а вот журналисты в последнее время стали опасаться (43), да и менеджеры уже не желают иметь с ней дел (45). Широкая общественность, как правило, воспринимает происходящее через призму отношения журналистов (43), (рис. 11). Таким образом, если бы руководство имело намерения изменить репутацию этой компании, необходимо было бы обратить внимание на работу с журналистами и с менеджерами. Что важно, направлять усилия надо на работу с несколькими целевыми группами одновременно.

Рис. 11. «Репутационный радар» TRI*M для нефтяной компании: отношение заинтересованных групп

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

Рис. 12. «Сетка» TRI*M для нефтяной компании: социальная ответственность

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

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

Селандер Йоран, HR-Лига

hr-portal.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.

Ссылки[ | код]

ru.wikibedia.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.

Ссылки

wikiredia.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.

Ссылки

wikiredia.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.

Ссылки[ | код]

ru.wikibedia.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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вовлечены

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

В согласии

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

Удовлетворены внедрением

Crystal Clear app clean.png Представители стейкхолдеров обеспечивают обратную связь с точки зрения их групп стейкхолдеров.Crystal Clear app clean.png Представители стейкхолдеров подтверждают, что система готова для разворачивания.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • примеров или областей решений, определенных стейкхолдерами;
  • реализации решений, принятых на более высоком уровне системной иерархии;
  • требований по использованию определенных обеспечивающих систем, ресурсов и штатного персонала.[8]
  1. ↑ 1,01,11,21,31,41,51,6 ГОСТ Р ИСО/МЭК 15288, 2005
  2. ↑ 2,02,12,22,3 ISO/IEC 29148, 2011
  3. ↑ 3,03,1 ISO/IEC 42010, 2011
  4. ↑ 4,04,14,24,34,44,54,64,7 OMG Essence, 2014
  5. ↑ Tom Gilb. The Ten Most Powerful Systems Engineering Heuristics
  6. ↑ 6,06,16,26,3 Systems Engineering Principles and Practice, 2011
  7. ↑ 7,07,17,2 SEBoK, 2012
  8. ↑ 8,008,018,028,038,048,058,068,078,088,098,108,118,128,138,148,15 ГОСТ Р ИСО/МЭК 12207, 2010
  9. ↑ ИСО/МЭК 9126-1, 2001
  10. ↑ ИСО/МЭК 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.
  • ГОСТ Р ИСО/МЭК 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.

wp.wiki-wiki.ru