Внедрить нельзя саботировать. Неочевидные нюансы внедрения нового ПО

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

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

Анастасия Хрилева, руководитель портфеля проектов компании «Кауч», делится опытом: что нужно учесть, чтобы снизить влияние человеческого фактора на успех внедрения. Эти принципы пригодятся на разных этапах внедрения нового ПО и помогут облегчить жизнь как команде проекта, так и пользователям и другим стейкхолдерам.

Этап инициации. Стараемся как можно раньше вовлечь заинтересованные стороны в проект

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

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

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

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

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

Этап планирования. Проверяем требования к системе на потенциальный конфликт интересов

Важно проверить, не породит ли внедрение нового ПО конфликт интересов.

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

Чтобы избежать подобного исхода, можно предпринять следующее:

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

Как решили проблему в описанном кейсе: в дополнение к сканеру уязвимостей была приобретена система, которая «переводит» требования ИБ на язык ИТ и автоматизирует настройку систем.

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

Этап внедрения. Заручаемся поддержкой неформальных лидеров

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

Что можно сделать, чтобы вовлечь неформального лидера:

• пригласить в команду проекта в качестве главного эксперта, попросить поделиться мнением о внедряемом ПО, обсудить с ним возможности повышения вовлеченности его коллег. Часто такие люди обладают огромным опытом, поэтому участие неформального лидера приносит только пользу, особенно если к нему прислушиваются;
• предложить представить опыт внедрения по результатам успешного проекта на внутренних встречах или отраслевых мероприятиях, как главного эксперта. Такие лидеры могут быть недооценены в качестве источника знаний вне своего подразделения, но желание делиться опытом у них есть;
• если уместно, обсудить с руководством и предложить материальное или нематериальное поощрение по итогам проекта. Легко обосновать премию ключевым участникам внедрения, если автоматизация существенно сэкономит издержки компании. Также, например, можно номинировать проект на внутренние премии (или создать их).

Переход в эксплуатацию. Сопровождаем пользователей в период адаптации

Бывает так: внедрили новое ПО, настроили, протестировали, передали пользователям, а спустя время система оказывается заброшенной.

Основная причина — недостаточная поддержка пользователей в начале эксплуатации.

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

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

Что с этим делать? Вот несколько рекомендаций:

• предусмотрите этап поствнедренческой поддержки — срок зависит от объема изменений, но обычно это не менее 3–4 недель. Этот период необходим для закрепления новых сценариев. Важно назначить ответственных, которые будут оперативно решать технические проблемы и консультировать участников по новым процессам;
• зафиксируйте новые процессы в видеоинструкциях или презентациях: большие регламенты читать не любят, а короткое видео или понятный слайд удобно посмотреть и вспомнить как действовать;
• под конец периода поддержки запросите у пользователей обратную связь, насколько им понятно работать в системе. Если уровень понимания низкий, стоит рассмотреть повторное обучение или доработку материалов с разъяснением сложных моментов.

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

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