Что упускают проектные команды при работе с пользователями во время внедрения ИС?
По моим наблюдениям, работа с пользователями во многих проектах ограничивается тремя вещами:
— информированием о целях проекта; — обучением работе в новой системе; — консультационной поддержкой после запуска.
В более зрелых проектах дополнительно создают институт ключевых пользователей, которые помогают команде внедрения, участвуют в тестировании и становятся проводниками изменений внутри своих подразделений. Иногда из таких сотрудников впоследствии формируют внутреннее сообщество наставников.
Это уже хороший уровень.
Но даже этого недостаточно.
Проблема в том, что внедрение информационной системы — это не просто замена одной программы другой. Это изменение рабочей среды людей.
Мы вмешиваемся в привычный ритм работы сотрудников. Просим отказаться от инструментов, которыми они пользовались годами. Требуем осваивать новые процессы. Заставляем временно снизить скорость работы ради будущего результата.
Именно поэтому внедрение редко проваливается из-за технологий.
Чаще оно буксует из-за людей.
Многие проектные команды начинают работу с пользователями с обучения. Но обучение — это далеко не первый шаг.
Здесь полезно вспомнить модель ADKAR, которая говорит о том, что изменения начинаются не со знаний и инструкций.
Сначала человек должен понять проблему.
Затем захотеть её решить.
И только потом появляется смысл учить его новому инструменту.
При этом проблема должна быть не генерального директора и не проектного офиса.
Она должна быть личной для самого сотрудника.
Например:
— старая система регулярно зависает и отнимает время на ручные операции; — между подразделениями постоянно возникают конфликты из-за расхождений в данных; — сотрудники вынуждены вести параллельный учёт в Excel; — система настолько устарела, что её отказ может остановить важные бизнес-процессы.
Пока человек не увидит собственную проблему, он не будет заинтересован в её решении.
Ни лозунги про цифровизацию, ни рассказы про развитие компании, ни даже премии не смогут заменить понимание личной выгоды от изменений.
Есть ещё один момент, который часто недооценивают.
У пользователей есть основная работа.
Они участвуют в проекте не вместо своих обязанностей, а вместе с ними.
Они продолжают закрывать отчётность, рассчитывать зарплату, оформлять документы, взаимодействовать со смежными подразделениями и выполнять десятки других задач.
Поэтому многие сотрудники взаимодействуют с проектной командой в состоянии постоянной загрузки, усталости и стресса.
Это влияет на качество обратной связи.
Иногда требования формулируются неполно.
Иногда замечания появляются не сразу.
Иногда сотрудники вспоминают важные детали только спустя недели после обсуждения процесса.
И это нормально.
Особенно ярко это проявляется после перехода в промышленную эксплуатацию.
На этапе обучения и тестирования пользователь работает с системой эпизодически.
После запуска он проводит в ней весь рабочий день.
Интенсивность использования возрастает в разы.
Именно тогда начинают всплывать детали, которые раньше никто не замечал.
Это не всегда означает, что система плохая или сырая.
Часто это означает лишь то, что люди впервые столкнулись с реальной эксплуатацией нового инструмента.
Поэтому одна из самых важных компетенций руководителя цифровой трансформации — умение смотреть на проект глазами пользователя.
Понимать его контекст.
Понимать его опасения.
Понимать, что вчера он был экспертом в привычной системе, а сегодня снова чувствует себя новичком.
Иногда сотруднику недостаточно инструкции.
Иногда недостаточно обучения.
Иногда нужно просто сесть рядом и вместе выполнить несколько операций в новой системе.
Показать, что процесс работает.
Показать, что он не сложнее прежнего.
Показать, что возникающие трудности решаемы.
Люди привыкают к изменениям не через презентации. А через понимание смысла этих изменений, поддержку и собственный положительный опыт.
Поэтому внедрение начинается не с настройки системы.
А с работы с людьми.
