Поменять привычки: компании внедряют изменения быстрее, чем сотрудники успевают их освоить

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

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

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

Сколько изменений приходится на одну команду

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

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

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

Почему скорость пилота обманывает ожидания

Когда прототип удается собрать за несколько дней, месяцы на освоение начинают выглядеть как затягивание проекта. Но сотрудникам предстоит разобраться в новом порядке, распределить ответственность и научиться справляться с исключениями. Быстрая разработка не отменяет этой работы.

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

Поэтому вместе с результатом пилота нужно разбирать условия его успеха: что удастся воспроизвести, что придется доработать и сколько будет стоить поддержка. Если польза или экономика не подтвердились, вполне разумно остановить эксперимент. Проблема возникает, когда компания решила развивать полезную инициативу, но не организовала ее освоение.

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

Сотрудники также помнят преобразования, которые громко начинались и постепенно прекращались без объяснения результатов. После нескольких таких циклов очередную трансформацию встречают словами: «Такое уже пробовали». Команде внедрения приходится объяснять, что в этот раз будет устроено иначе и кто доведет работу до результата.

Что стоит закрепить за Adopt

Если опираться на распространенную управленческую модель Run — Change — Disrupt, деятельность компании можно разделить на три направления: текущую работу, развитие существующих процессов и поиск принципиально новых подходов. При таком разделении ответственность за освоение изменений нередко оказывается размытой между командой, которая разрабатывает и внедряет решение, и бизнес-подразделением, которому предстоит его использовать. Разработчики считают решение готовым, а сотрудники подразделения еще не могут уверенно работать по-новому.

Работа с принятием изменений давно существует в управленческой практике. Для Adopt следует планировать работу и закреплять ответственность за ее результат. Решение о масштабировании должно включать договоренность о том, кто поможет подразделению освоить новый процесс и сколько времени на это потребуется.

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

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

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

Для исполнителей Adopt должен входить хотя бы в тройку главных задач. Частая ошибка — добавить внедрение к прежним обязанностям, не освободив времени. Еще хуже, если его сразу объявляют второстепенным. В обоих случаях формальное назначение ответственного мало помогает.

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

Изменение нужно «продать» внутри компании

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

К внутренней «продаже» стоит относиться столь же внимательно, как к продаже продукта клиенту. Обещание «повысить эффективность» почти ничего не объясняет сотруднику. Ему важно понять пользу нового подхода и какие усилия потребуются для перехода. На примере собственной задачи человеку проще увидеть, зачем менять привычный способ работы.

При этом сопротивление может указывать на недостатки самого решения. Если сотрудник должен дублировать данные в двух системах, дополнительная рассылка вряд ли поможет. Команде Adopt нужно выяснить причину затруднения и организовать доработку процесса.

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

Коммуникация продолжается и после запуска. К сотрудникам необходимо вернуться с результатами: что получилось, что исправили по их замечаниям, какая польза уже видна. Если ожидаемого эффекта пока нет, это тоже стоит объяснить: что не сработало и какое решение принято дальше. Молчание после громкого запуска только укрепляет прежний скепсис.

После обучения начинается освоение

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

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

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

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

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

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

Когда изменение можно передать в обычную работу

Результат Adopt стоит оценивать через бизнес-эффект и участие людей. Для продаж важен вклад изменения в выручку, для внутренней автоматизации — стоимость операции с учетом поддержки и проверки результата. Сэкономленные часы не превращаются в деньги автоматически — нужно понимать, на что пошло высвободившееся время.

Одновременно метрики должны показывать, какая доля сотрудников, которым предназначено изменение, действительно применяет новый подход. Метрика зависит от процесса. Для ежедневного сервиса полезна регулярность использования. Для инструмента полугодовой оценки персонала — доля участников, воспользовавшихся им в соответствующем цикле.

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

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

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

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