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

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

Что такое карта стейкхолдеров

Карта строится для конкретного изменения и пересматривается при смене участников, полномочий или условий проекта.

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

Форматов несколько: список сторон, схема связей, матрица. Здесь используем матрицу «влияние / интерес» из руководства Nielsen Norman Group. Рядом с участниками запишем ожидания, основания оценок и следующие действия. Карта сама никому не назначает полномочия.

Сначала ограничьте проект

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

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

От персоны такая карта отличается предметом: мы разбираем участников конкретного проекта, а не собираем портрет аудитории. CJM показывает этапы клиентского пути. Здесь временная последовательность не нужна: вопрос в том, чьё участие требуется для решения о подтверждении.

Как читать влияние и интерес

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

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

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

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

Названия этих групп в руководствах различаются. В методике Office for National Statistics для сторон с высоким интересом и низким влиянием предусмотрены консультации. Подпись «информировать» не должна превращать общение в одностороннюю рассылку.

Заполненный пример: запись в сервисный центр

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

Учебный документ Д1 задаёт порядок запуска: руководитель центра утверждает правила записи, финансовый директор согласует дополнительные расходы. Полномочия ИТ-подрядчика в Д1 не описаны. В учебных разговорах С1–С4 участники поясняют свои ожидания. Этих сведений достаточно для первой версии, но не для решения о техническом запуске.

Руководитель центра: согласовать порядок

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

Финансовый директор

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

Кто будет работать с записью?

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

Клиенту важен результат

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

Левый нижний сектор пока пуст. Не добавляйте туда случайного участника ради симметрии. Карта с незаполненным сектором полезнее карты, в которой неподтверждённые оценки выглядят завершёнными.

Неизвестное оставляйте неизвестным

Про ИТ-подрядчика команда записала версию Г1: «Он только настраивает систему, согласование не требуется». В договоре и порядке запуска это ещё не проверили. Ставить подрядчика в сектор низкого влияния рано: отсутствие сведений не подтверждает отсутствие полномочий.

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

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

От карты к плану общения

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

Как распределить роли по RACI

Для следующего действия укажите, кто свяжется с участником, о чём спросит и какое решение ждёт ответа. Назначение исполнителей по задачам можно вынести в матрицу RACI. У неё другая работа: распределение ответственности. Буква в таблице ролей не объясняет, почему клиенту нужен перенос визита или что беспокоит администратора.

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

Как собрать ожидания в WebAsk

Для первоначального сбора используйте «Поле ввода» с настройкой «Большое поле». Вместо общего «Поддерживаете ли вы изменения?» спросите: «Что изменится в вашей работе при новом порядке записи?» и «Какая информация нужна вам перед запуском?» Отдельно оставьте место для вопроса, который команда не предусмотрела.

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

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

Сохранённые ответы и выгрузка в CSV или XLSX описаны в инструкции по результатам. Размечайте источники после выгрузки, а карту и план общения собирайте в документе или на доске. WebAsk помогает получить ответы; он не определяет влияние участников и не строит такую матрицу автоматически.

Чего карта не показывает

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

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

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

Частые вопросы

Кто составляет карту стейкхолдеров?

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

Нужно ли считать влияние по шкале от одного до десяти?

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

Можно ли составить карту только по ответам анкеты?

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

Как отмечать участника, о котором мало сведений?

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