Разделы

Цифровизация Внедрения

Как преодолеть сопротивление сотрудников новым ИТ-решениям

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

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

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

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

Как формируется сопротивление

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

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

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

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

Дополнительные факторы, способствующие протесту против ИС

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

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

В результате до руководства доходит коллективное мнение, сильно искажающее реальную ситуацию: "Система полна ошибок, из-за которых невозможно работать. Но даже там, где их нет, нам приходится тратить по 30 минут на выполнение действий, которые в Excel занимают 5 минут. Так мы не сможем выполнять наши обязанности. И вообще, систему сделали непонятной и сложной, наверное, они [консультанты] не понимают, как мы работаем".

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

Как избежать сопротивления

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

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

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

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

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

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