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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как подойти к функционалу

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

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

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

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

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

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

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

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

Если предупредительные меры не были предприняты, то возникает ситуация конфликта между сотрудниками и консультантами, в котором первые обвиняют вторых в плохом качестве системы, а те в свою очередь защищают систему, мотивирую нежеланием и неумением первых с ней работать. В этом случае заказчику нельзя допускать типичную ошибку: перенести ответственность за разрешение конфликта на плечи консультантов. Часто это выглядит как "разберитесь с сотрудниками и сделайте, что они хотят". В результате – серия итераций по доработке и улучшению системы, в которых сотрудники все так же находят новые аргументы для отказа от работы с ПО.

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

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

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

Автор статьи: Александр Рыжков

Tweet