Работа с рисками и заинтересованными сторонами – задача не только подрядчиков, которых вы приглашаете для автоматизации бизнеса. Практика показывает, что результат дают именно совместные усилия команд заказчика и подрядчика.
В статье поделимся с вами инструментами из нашего опыта для работы с заинтересованными сторонами и рисками.
Зачем нужно работать с рисками и заинтересованными сторонами
Причин неудач проектов очень много. В том числе, это могут быть:
- Отсутствие четкой связи со стратегическими приоритетами организации;
- Отсутствие руководителя проекта на стороне заказчика;
- Отсутствие команды у руководителя проекта;
- Неэффективное вовлечение в проект заинтересованных сторон.
Все эти причины представляют собой риски для успешной реализации проекта автоматизации. С ними нужно работать постоянно:
- Фиксировать и оценивать.
- Обсудить меры реагирования на риски.
- Назначить ответственных за мониторинг риска и его устранение – если у вас не будет ответственных, то вы не будете работать с риском.
- Донести до команды процедуру работы с риском. Лучше сделать это в самом начале проекта. Если команда понимает для чего это делается, то всем становится комфортнее работать.
Один из важных рисков на проекте – недостаточная работа с заинтересованными сторонами. Работать с ними необходимо прежде всего потому, что сам проект – для людей. Именно они в дальнейшем будут работать в системе.
На практике, часто встречается вопрос: "Когда необходимо начинать работать с рисками?" Ответ: как можно раньше. Лучше всего, когда принято решение о старте проекта: вы поняли, какие блоки хотите автоматизировать, назначили руководителя проекта.
Второй вопрос, который также часто задают: "Достаточно ли на стадии инициации проработать реестр заинтересованных сторон и рисков и все передать подрядчику?"
Ответ зависит от типа вашего проекта. Если команда подрядчика находится у вас full-time целый год, то ответственность может быть полностью передана подрядчику, потому что он будет в курсе событий внутри компании.
Однако сейчас многие собственники отказываются от такого формата. Нужно понимать, не присутствуя постоянно на вашей территории, команда подрядчика может не знать ваши изменения внутри компании, конфликты и другие обстоятельства, влияющие на проект. Соответственно, руководитель проекта и команда с вашей стороны также должны работать с заинтересованными сторонами.
С заинтересованными сторонами нужно работать постоянно. Например, перед встречей нужно продумать, какие риски могут возникнуть, постоянно сканировать ситуацию в моменте и смотреть, что происходит, как реагируют участники. Ситуация может меняться быстро и кардинально, поскольку на бизнес влияет очень много факторов.
Роли на проекте
Все знают о ролях в команде подрядчика. Чаще всего это:
- Руководитель проекта,
- Тимлид,
- Эксперт, технический руководитель проекта, системный архитектор,
- Бизнес-архитектор,
- Бизнес-аналитик,
- Разработчик,
- Тестировщик.
Однако очень мало компаний заказчиков прорабатывают у себя роли и прописывают по ним зоны ответственности. Например, не назначают ключевых пользователей, которые ответственны за определенные процессы при автоматизации. Это тоже риск, который может грозить остановкой проекта.
Какие роли должны быть предусмотрены у заказчика?
- Спонсор проекта,
- Куратор проекта/руководитель проекта,
- Руководитель рабочей группы/владелец процессов/ключевой пользователь,
- Координатор/администратор проекта.
Анализ заинтересованных сторон
Для работы с заинтересованными сторонами нужно:
- Выделить стороны и определить их профессиональные и личные интересы;
- Уточнить точки зрения сторон на организацию: обратить внимание на важные для них моменты в текущей системе, чтобы перенести в новую, а также выявить опасения;
- Сформулировать ключевые стратегические вопросы – требования, которые являются критерием успеха проекта для заинтересованных лиц;
- Начать процесс выявления коалиций, оказывающих поддержку оппозиции;
- Разрешить возникающие конфликтные ситуации и защитить от потенциальных;
- Прогнозировать риски, связанные с деятельностью сторон.
Работать с заинтересованными сторонами и рисками можно по-разному. Рассмотрим несколько инструментов, которые мы используем на практике.
- Модель Митчелла
Она предполагает классификацию заинтересованных сторон по определенным группам, чтобы выбрать стратегию для работы с рисками. Ее можно перегруппировать, главное, чтобы она действительно давала вам результаты и информацию.
Модель Митчелла подходит для классификации сторон для любого проекта.
Обратите внимание, что здесь учитываются не только лица, принимающие решения, и собственники, но и обычные сотрудники – те люди, кто в дальнейшем будет использовать систему.
- Реестр возможных рисков
После этапа, где вы классифицировали ваши заинтересованные стороны по категориям, составляется реестр возможных рисков. Здесь работа строится с категориями рисков, а не заинтересованных сторон.
Лучше всего продумать возможные риски уже на стадии инициации: может ли возникнуть саботаж проекта, какова вероятность наступления риска и тяжесть последствий. Тогда в ходе проекта вы сможете гибко управлять ситуацией.
Однако реестр важно пересматривать в соответствии с изменениями хода проекта.
- Матрица «Власть/интерес» как стратегическая модель управления заинтересованными сторонами. Ее можно использовать, когда вы уже первично оценили риски.
Заинтересованные лица распределяются по квадрантам, в зависимости уровня власти и интереса к проекту. Исходя из результата, вы можете подумать, какую стратегию использовать в отношении определенных категорий.
Однако будьте внимательны – матрицу нужно смотреть в динамике, поскольку все может быстро меняться.
Например, в начале этапа концептуального моделирования финансовый директор был в квадрате "Сохранение удовлетворенности". У него высокая власть, а интерес низкий – он просто наблюдает. Но со временем его интерес растет – он попадает в "Ключевые действующие лица". Если вовремя это не заметить, то можно не учесть его требования и интерес, что может привести к конфликту. Последствия могут быть самыми разными, вплоть до остановки проекта.
- Описание стратегии реагирования на возможные риски
Выделяют четыре метода реагирования на возможные риски:
- Избегание,
- Минимизация,
- Передача,
- Принятие.
Вы можете заранее проработать приемлемые для вас варианты действий. Так в зависимости от ситуации с заинтересованной стороной можно уже на начальной стадии выбрать подходящее решение. Примеры приведены в таблице ниже.
Кейсы по работе с рисками и заинтересованными сторонами из нашей практики
Рассмотрим два реальных кейса из нашей практики.
Кейс 1. Дано:
- Крупное производственное предприятие с полным циклом производства;
- Многопередельное производство с индивидуальной проектной технологией;
- Низкая текучка кадров как в производственной, так и в коммерческой службе.
Что было на проекте с заинтересованными сторонами:
- Высокий интерес автоматизации у финансового отдела, но низкая власть. Именно они инициировали проект;
- Высокая власть у коммерческого и производственного отделов, но низкий интерес в автоматизации;
В результате проект оказался на грани срыва уже на стадии концептуального моделирования.
Еще раз отметим, что только на этапе обследования подрядчик может увидеть, что происходит у вас внутри и дать рекомендации. До этого момента такие риски можно только предположить, поскольку переговоры происходят только с лицами, которым интересен проект, а не со всеми сотрудниками.
Что было сделано на проекте в рамках работы с рисками? Было предложено организовать проектную команду заказчика, для чего выделили нескольких человек. С ними мы прорабатывали заинтересованные стороны: сотрудников коммерческой службы и производственников. Мы узнавали, какие у них могут быть интересы и опасения, что ценного в текущей системе для этих людей, чтобы перенести в новую.
Так мы предложили коммерческому отделу калькулятор, и они понимали его ценность. Производственный отдел сильно противился автоматизация. В то же время задачей финансового директора было получение себестоимости наряд-заказа хотя бы на входе и выходе.
Соответственно, мы приезжали к ключевым пользователям производственного отдела уже с прототипом: моделировали и показывали АРМ, который у них будет. Акцент был именно на работе в одном месте, а не на цепочке документов. Благодаря этому в ходе работы у ключевых пользователей производства появился интерес. Особенно когда они поняли, что их требования к АРМ-у могут быть учтены.
Кроме того, со своей стороны очень много сделала проектная команда заказчика – мы также научили их работать с ключевыми лицами.
В результате:
- Сменили концепцию автоматизации производства: были автоматизированы не все отделы;
- Решена задача финансового контура по себестоимости наряд-заказа;
- Производственный и коммерческий отделы получили удобные инструменты и сами инициировали дальнейшую автоматизацию.
Кейс 2. Дано:
- Международная дистрибуция – у заказчика было две компании;
- Есть свои самописные системы, в которых работает коммерческий отдел;
- "Зоопарк" программного обеспечения. Стоит вопрос обменов, поскольку бизнес развивается и нужны новые инструменты;
- Желание руководства перейти в систему 1С:ERP за один раз. Они уже сталкивались с переходом на систему раньше.
Часто руководство не всегда хорошо знает своих ключевых пользователей – тех, кто имеет вес в компании, и держателей бизнес-процессов, особенно если последние не описаны. В данном случае при инициации не были должным образом оценены интересы ключевых сотрудников компании – коммерческого отдела. Они, со своей стороны, не высказывали негатив, но воспринимали автоматизацию как зло и проект был под угрозой. Начались манипуляции со стороны сотрудников, и назревал саботаж проекта.
Что было нами предпринято? В обеих компаниях заказчика было предложено собрать проектные группы, мы прорабатывали с ними интересы и опасения, общались с заинтересованными сторонами.
Уже на начальной стадии моделирования есть вероятность возникновения негатива у заинтересованных сторон, потому что их не услышали и не учли требования. Мы проанализировали много вариантов в обеих компаниях и приняли решение оставить историческую самописную систему в качестве СRM. Такое решение встречается довольно часто, особенно если система написана на платформе Предприятие 8.
В результате:
- Принятое решение оставить самописную систему внесло спокойствие в проектную команду и ключевых сотрудников;
- Увеличилась вовлеченность и интерес коммерческого отдела. Они поняли, что автоматизация не будет мешать в их деятельности, и тоже стали принимать участие в процессе;
- Распределены роли по интересам заинтересованных сторон;
- Снижены риски.
Надеемся, что эта статья поможет вам при работе с рисками и заинтересованными сторонами.