Поделиться
Как преодолеть сопротивление сотрудников новым ИТ-решениям
При внедрении новой ИТ-системы компания зачастую сталкивается с сопротивлением сотрудников, которые всячески саботируют работу в ней, мотивируя свой отказ надуманными причинами или значительно преувеличивая проблемы. Как можно уменьшить масштаб протеста еще на стадии разработки и внедрения, и что лучше сделать, если начальный этап уже пропущен. Рассмотрим советы и рекомендации.Большинство компаний, внедряющих ERP-решения, в том или ином виде сталкиваются с проблемой сопротивления сотрудников. Преимущественно она возникает на заключительных этапах проекта, когда основная часть работы выполнена, и кажется, что успешному запуску системы ничего не помешает.
Сопротивление сотрудников проявляется в их отказе от использования ИС под различными поводами. Наиболее частые "причины" - наличие большого числа ошибок, препятствующих комфортной работе с системой, отсутствие понимания логики ее работы, непривычный и неудобный интерфейс, большое количество действий, необходимых для выполнения простых операций, и т.д.
Сопротивление сотрудников может привести к приостановке проекта, затягиванию его сроков и даже к его сворачиванию. Но, следуя определенным принципам ведения проекта, можно заранее снизить силу "протеста" и легче пережить его.
Как формируется сопротивление
Сопротивление возникает сразу, как сотрудники начинают работать с системой. Однажды им сообщают, что скоро они будут пользоваться новой удаленной ИС, которая автоматизирует их операции, сократит трудозатраты и сэкономит рабочее время. Конечно же, их научат работать в ней.
Наступает день тренинга. Сотрудников собирают в группы. (При этом по долгу службы часть не может полностью погрузиться в обучение и параллельно работает, что по результату часто аналогично отсутствию на обучении.)
На обучении специалисты компании впервые видят систему, с которой им придется работать. Изучение решения состоит из обзора его функциональности и интерфейса, а также из выполнения типовых практических заданий. С помощью тренера сотрудникам хоть и удается выполнить упражнения, но часто это не приводит к пониманию ими логики работы системы. Они могли бы лучше изучить решение, если сразу же после окончания обучения приступили бы к работе с ним – однако этому часто мешает разрыв (который бывает на проектах внедрения) между обучением и запуском системы в эксплуатацию, а также отсутствие "домашних заданий» или невозможность их выполнения из-за недоступности ПО.
К тому моменту, когда сотрудники приступают к работе в новой ИС, часть из них уже не помнит правила, а другая - вообще не умеет ей пользоваться, так как отсутствовала на обучении. Консультант или тренер, который мог бы ответить на вопросы, уже отсутствует. Все что остается – длинное и трудночитаемое "руководство пользователя".
Дополнительные факторы, способствующие протесту против ИС
- В системе имеются ошибки, без которых не обходится ни один программный продукт, и скорость их исправления низка. Причем значимость некритичных для бизнес-процесса ошибок сотрудниками неумышленно завышается.
- Для решения некоторых типовых задач с использованием новой системы сотрудникам необходимо выполнить большее число операций, чем при использовании старых систем или любимого всеми Excel. Причинами этого является как непонимание принципов работы системы, так и результат проектирования, не учитывающего эргономичность работы
- Механизмы и бизнес-процессы, заложенные в системе, несколько отличаются от реально применяемых в повседневной работе
По причине непонимания логики работы ПО и способов выполнения повседневных операций, а также из-за естественного отторжения нового и непривычного интерфейса системы у сотрудников начинает формироваться ее неприятие, которое в дальнейшем усугубляется дополнительными факторами.
В результате до руководства доходит коллективное мнение, сильно искажающее реальную ситуацию: "Система полна ошибок, из-за которых невозможно работать. Но даже там, где их нет, нам приходится тратить по 30 минут на выполнение действий, которые в Excel занимают 5 минут. Так мы не сможем выполнять наши обязанности. И вообще, систему сделали непонятной и сложной, наверное, они [консультанты] не понимают, как мы работаем".
В такой ситуации руководитель преимущественно начинает разбор ситуации с компанией-консультантом. А пока процесс идет, сотрудники "выбивают" право пользоваться старыми способами работы (если им была оставлена альтернатива) или уговаривают руководство официально разрешить использование старых систем. Таким образом, новая система проигрывает первый и главный раунд.
Как избежать сопротивления
Сопротивление изменениям заложено в человеческой природе, поэтому полностью избежать этого не удастся. Однако можно уменьшить его силу, заранее позаботившись о трех его главных источниках: непонимании системы, ошибках и неправильной реализации бизнес-процессов. Эти источники проблем можно нивелировать, вовлекая сотрудников в работу над проектом с ранних стадий.
На этапе проведения анализа бизнес-процессов и требований заказчика компанией-консультантом чаще всего производится интервьюирование менеджеров, которые описывают процессы в том виде, как они его представляют, и со своего уровня. При этом менеджеры часто не в курсе деталей и нюансов процессов, отдельных операций, выполняемых сотрудниками. Таким образом, то, что важно в операционной работе рядовых служащих, может не попасть в перечень требований к системе.
На данном этапе консультант должен максимально декомпозировать и детализировать бизнес-процессы, привлекая к анализу рядовых специалистов, участвующих в них, зафиксировав детали выполняемых ими повседневных операций. Это позволит учесть и реализовать потребности сотрудников.
После проведения анализа консультант разрабатывает техническое задание или дизайн-проект. Это документ, содержащий (с той или иной степенью детализации) все, что будет реализовано в системе. Проблема заключается в том, что большинство представителей заказчика часто "не понимают" такой документ, в итоге полагая, что "консультант все понял и, наверное, все верно изложил". В итоге ТЗ согласовывается и передается в разработку.
Однако чтобы избежать дальнейших разногласий и дорогостоящих переделок функционала, на данном этапе необходимо тщательно проанализировать описание, сделанное консультантом, и обсудить все непонятные заказчикам места, попросив их сопроводить макетами. Наилучший результат даст проведение консультантом демонстрации для заказчиков и ключевых сотрудников того, как будут выполняться в системе повседневные операции сотрудников (так называемые Use Case).
После согласования дизайна исполнитель приступает к разработке системы. В большинстве проектов, построенных не на основе гибких методологий, заказчик видит конечный результат после окончания разработки, когда цена любых новых изменений системы повышается. Рекомендация – дробить разработку на как можно большее число шагов, на каждом из которых реализуется небольшой законченный бизнес-процесс.
Короткая ссылка
