Заинтересованные стороны проекта

⚠️Много текста

-=Уровень: Middle=-

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

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

В Babok Guide v3.0 дано следующее определение:

Заинтересованные стороны — это группа или отдельное лицо, связанное с изменением, потребностью или решением.

Классификации заинтересованных сторон

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

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

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

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

Профессор университета Алабама Грант Саваж предложил в 2001 году двухпараметрическую модель классификации:

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

Профессор предпринимательства Роналд Митчелл и его коллеги Б.Эйгль и Д.Вуд разработали одну из самых известных классификаций основанную на трех критериях и их комбинациях

Три основных критерия :

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

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

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

И последней классификацией (самой распространенной) будет трехпараметрическая модель Р.Мюррея-Вебстера и П.Саймона

Эту модель можно изобразить по другому:

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

Выявление заинтересованных сторон

Итак, нам необходимо выявить заинтересованные стороны. Кого мы будем искать?

Тех, кто может повлиять на проект (формально и неформально)
Тех, кто может повлиять на компанию
Тех, кто может предоставить информацию для бизнес-анализа
Тех, кто заинтересован в нашем проекте
Тех, на работу которых может повлиять наше решение

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

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

Несвоевременное выявление заинтересованных сторон может привести к проблемам, которые могут «похоронить проект»:

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

А также эти заинтересованные стороны могут стать противниками проекта, либо смотреть на проект пессимистически.

Во время выполнения проекта важно понимать то, как представители заказчика относятся к проекту, при этом такое отношение можно анализировать с разных сторон:

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

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

Отношение к бизнес-анализу:

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

Отношение к сотрудничеству:

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

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

Джон Коттер в своей книге «Впереди перемен» пишет, что есть такие ошибки при проведении организационных изменений:

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

И эти ошибки ведут к таким последствиям:

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

Отношение представителей заказчика к проекту

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

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

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

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

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

Также надо дать ответ на вопрос: «Можно ли получить пользу другим способом«? Иногда ошибкой команды проекта есть использование своего опыта и уже проработанных решений в проекте. Раз это решение было успешно применено у другого заказчика, нормально зайдет оно и здесь. Решение для заказчика должно формироваться на основе анализа проблемы заказчика. И не надо забывать спрашивать у заказчика — «Какое он видит решение?», достаточно часто заказчик понимает какое ему нужно решение. Конечно это неправильно, когда заказчик вместо того чтобы работать в зоне проблемы, сразу перескакивает в зону решения (вместо что и зачем, сразу говорить как). Но если он говорит про то как он видит решения — нельзя это просто игнорировать. Если разрыв между тем, что в голове заказчика и тем что предлагает проектная команда большой, то это уже проблема (я с таким сталкивался не один раз). Бизнес-аналитик должен всегда уточнять у заказчика согласен ли он с предоставляемым решением или считает что польза может быть получена другим путем.

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

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

Мнение на проект может также формироваться по ходу его течения. Если ЗС видит, что проект идет хорошо, то это его успокоит, если же он видит, что проект идет как-то хаотически и делается не то, что нужно по его мнению- то это может его напрячь.

Еще одной проблемой может стать негативное отношение заказчика к бизнес-анализу. Большинство отечественного бизнес считает, что все можно решить с командой разработки, а бизнес-аналитики — это лишнее звено, которое к тому же забирает много времени. Такое отношение к бизнес-анализу может значительно осложнить проект.

Проблемой также есть отношение заказчика к сбору требований и апеллирование к уже существующим решениям на рынке. «Хочу как в 1С» — такое я очень часто слышал на проектах по внедрению ERP-системы. «Зачем мне вам что-то рассказывать — нам нужно тоже самое, что у нас есть — но только на другой платформе. Вот вам наша 1С — изучайте себе на здоровье». Или же он просто давал описание своей системы либо ТЗ написанное для этой системы. «Вот есть готовое ТЗ под 1С — нам нужно тоже самое но на другой платформе». Такие формулировки опасны и должны быть сразу отвергнуты. Изучение старой системы и перенос требований на новую может занять очень много времени и при этом положительный результат не гарантирован.

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

Техники выявления заинтересованных сторон

BABOK Guide v3.0 рекомендует применять следующие техники:

Мозговой штурм
Анализ бизнес-правил
Анализ документов
Интервью
Анализ полученного опыта
Карта ассоциаций
Организационное моделирование
Моделирование бизнес-процессов
Опрос или анкетирование
Семинар (workshop) требований
Список, карта или персоны заинтересованных сторон

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

Организационное моделирование (моделирование оргструктуры)

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

Моделирование бизнес-процессов

Бизнес-аналитик практически в каждом проекте должен разобраться как работает организация сейчас (as is). Для этого он разрабатывает модели тех бизнес-процессов, которые нам интересны с точки зрения проекта. Это чаще всего используется для разработки требований. Далее моделирование нужно для того чтобы увидеть как будут выглядеть процессы в будущем (to be). Также с помощью моделирования можно выявить заинтересованных лиц.

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

ехники выявления заинтересованных сторон RACI Matrix

Данная техника позволяет определить степень вовлеченности ЗСт. в выполнение той или иной задачи

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

Часто метод RACI называют диаграммой или таблицей, но по сути это именно матрица ответственностей.

Термин RACI (или ARCI) является аббревиатурой:

R – Responsible (исполняет);
A – Accountable (несет ответственность);
C – Consult before doing (консультирует до исполнения);
I – Inform after doing (оповещается после исполнения).

Иногда можно встретить вариант аббревиатуры – RACIS, где

S – supported (оказывает поддержку)

Инструкция

1. Определить все задачи, выполняемые в рамках проекта (части проекта). Перечислить задачи в левой части таблицы (матрицы) в порядке их выполнения;
2.Определить все проектные роли и привести их вдоль верхней части таблицы (матрицы);
3.Заполнить ячейки таблицы (матрицы), указав, кто исполняет, кто отвечает за полноту и корректность исполнения, с кем консультируются и кого ставят в известность в рамках
выполнения каждой задачи;
4.Убедиться, что каждая задача имеет хотя бы одного исполнителя и одного, и только одного ответственного за исполнение;
5.Устранить все выявленные конфликты;
6.Обсудить и утвердить RACI Matrix с ЗС до того, как начнутся работы в рамках проекта.

«Список, карта или персоны заинтересованных сторон»

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

И давайте более детально разберем инструмент «Карта заинтересованных сторон»

Карта ЗС — инструмент, который помогает определить, каким образом лидер компании/проекта может влиять на заинтересованные стороны.

В процессе составления карты визуализируют близость заинтересованных сторон к лидеру. В частности на карте выделяют три области:

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

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

Выводы

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

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

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

Хочешь узнать больше о заинтересованных сторонах или у тебя появились вопросы/идеи?
Присоединяйся к нашему телеграм-чату, и мы с удовольствием обсудим все с тобой и другими коллегами 😉