Цифровая трансформация бизнеса заметно ускоряется в последние годы. Компании стремятся внедрять новые решения, чтобы оптимизировать работу и быть эффективными. Но, к сожалению многие решения так и остаются невостребованными после внедрения или используются только частично.
Мировая статистика показывает, что доля успешных IT-проектов составляет 31% ( на основании исследований компании Standish Group, отчет CHAOS Report за 2020 год). Остальные 69% – это либо проблемные ИТ-проекты, либо проваленные.
Ключевую роль во внедрении играют конечно же люди.Сотрудникам приходится подстраиваться под новые решения и переучиваться. И это большой стресс. Если не уделять этому вопросу должного внимания, то проект рискует попасть в те самые 69% или даже столкнуться с саботажем пользователей.
В статье мы делимся своим опытом, с какими проблемами и возражениями со стороны сотрудников сталкиваются компании.А также расскажем о том, как с ними работать, чтобы внедрение оказалось успешным.
Приведенные рекомендации в первую очередь рассчитаны для заказчика, так как вендор, даже если он подписывается под конкретными результатами, не имеет полномочий и не может влиять на сотрудников компании.
IT-отдел
Обычно это один из самых загруженных отделов в компании. Так как специалисты должны следить за всей инфраструктурой, то не удивительно, что они могут не успеть выполнить нужные работы или понизить их приоритет.
Независимо от того, внедряет ли заказчик систему самостоятельно или силами вендора, собственная IT служба всегда задействована. Самая частая проблема, с которой мы сталкиваемся - это несоблюдение сроков.
И рекомендация здесь одна - у куратора проекта должны быть достаточные полномочия и административный ресурс, чтобы влиять на приоритетность проекта.
Отделы закупок и логистики
Это пользователи, которые непосредственно будут работать в программе. И здесь с особой тщательностью нужно подходить к их вовлечению в работу с новым инструментом.
Саботаж сотрудников отдела закупок в основном бывает вызван тремя причинами:
- Люди привыкли к определенному инструменту или подходу и не хотят его менять, потому что это потребует от них серьезных усилий.
- Они боятся того, что программа их может заменить.
- У них нет доверия к расчетам программы, которую они не знают.
Сотрудники отделов закупок - это в основном достаточно опытные и консервативные люди. Поэтому замена одного инструмента на другой редко вызывает энтузиазм.
Чтобы снизить риски по первому и второму пункту, сотрудникам нужно объяснить, что происходит в компании, и зачем именно внедряется новая программа.
Важно вовлекать сотрудников в процессы еще до начала внедрения программы
Как это сделать? Хорошо, если руководители компании проведут встречи с отделом закупок, расскажут детали и ответят на вопросы. Тут необходимо донести до сотрудников, что программа предназначена для того, чтобы помочь им работать эффективнее, а не чтобы заменить их. Важно показать перспективу улучшения работы. Например, что расчеты можно будет делать не несколько часов, как раньше, а 20-30 минут, либо вообще в полностью автоматическом режиме.
Но при этом люди должны понимать, что они будут делать, если часть их работы будет автоматизирована. И ответы на такие вопросы нужно подготовить заранее.
По нашему опыту сотрудники отделов закупок часто перегружены, и частичная автоматизация рутинных процессов помогает высвободить часть времени на другие важные задачи, которые нельзя автоматизировать - анализ трендов, рынка, общение с поставщиками и т.д.
Второе, что мы рекомендуем делать перед внедрением - провести расширенную встречу с вендором и сотрудниками отдела закупок. На неё нужно пригласить всех, кто будет работать в программе.
На встрече работники смогут задать вопросы, посмотреть демонстрацию, узнать о деталях программы, как работает та или иная функция, как теперь изменится их работа и чем поможет им программа. Важно увлечь людей и объяснить, как программа должна вписаться в текущую деятельность компании.
Как правило, если такая встреча выстроена корректно, она помогает снять некоторую напряженность, связанную с внедрением нового продукта.
Как повысить доверие к расчетам?
Второй краеугольный камень внедрения - доверие к расчетам. В большинстве случаев новая программа - это новая методология расчетов. Не все готовы сразу принять её. Часто пользователи не хотят учиться новому и саботируют программу, говоря, что программа считает неправильно.
Чтобы снизить риски саботажа, мы рекомендуем такой алгоритм действий:
- Обучение пользователей. Эту задачу должен брать на себя вендор. Важно, чтобы он предлагал закрепляющие задания, которые потом будут контролироваться. Со стороны заказчика должен быть ответственный, который собирает все возникающие в ходе обучения вопросы и передает их вендору. Впоследствии все это вопросы нужно обязательно разобрать вместе со всей командой. Если в ходе обучения у команды не возникает вопросов, то как и в любом обучении, это важный звонок, что возможно что-то идет не так.
- Проведение тестовых расчетов после обучения. Первое время сотрудники будут тратить чуть больше времени на это, так как расчет будут проводить в двух системах - старой и новой. И сравнивать их. Главное условие - это разбирать вместе в вендором все существенные расхождения в расчетах. Если вы видите, что полученные данные разнятся, то обязательно подключаете сотрудников поддержки вендора и детально разбираете, почему программа посчитала именно так, какие факторы повлияли на это. Здесь принципиально важно этот процесс не игнорировать. Только так можно повысить доверие пользователей к программе.
- Накопление экспертизы внутри компании. На первых этапах стоит начать создавать центр компетенций по новому продукту внутри компании. Для это еще до внедрения стоит выбрать 1-2 сотрудников отдела закупок, лояльных к изменениям. Впоследствии эти сотрудники должны стать центром экспертизы и внутри компании и масштабировать знания. Таким образом, остальные сотрудники будут видеть, что их коллеги уже применяют программу, а значит она работает и это повышает доверие.. К тому же им будет проще и быстрее обратиться за помощью к коллегами, нежели к вендору.
Резюмируя вышесказанное, можно отметить главный принцип - это вовлекать пользователей системы с самого начала внедрения и поддерживать постоянный диалог между ними, руководством и вендором.
