Управление изменениями в компании: почему буксует внедрение

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

Кому эта статья полезна

Владельцу компании, где уже что-то внедряли и не внедрили. Новая CRM, по которой работают три человека из тридцати. Оргструктура, которая живёт в презентации. Регламенты, которые написаны и лежат.

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

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

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

Два внедрения, которые заняли по году

В Skillbox мы внедряли много систем, и два проекта были самыми большими и сложными. Confluence как база знаний и место, где живут описания проектов. Jira для всех задач и для автоматических цепочек согласования. Каждый занял примерно год.

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

Что такое управление изменениями и что с моделями

В учебниках управление изменениями это набор моделей: восемь шагов Коттера, ADKAR, размораживание и замораживание Левина. Пересказов этих моделей в интернете достаточно, и пересказывать их ещё раз я не буду.

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

Почему буксует внедрение: пять причин

Причина первая. У изменения нет выделенного владельца

Изменение поручили тому, у кого и так полная загрузка, или размазали по нескольким руководителям.

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

Как это выглядит у вас: на вопрос «кто отвечает за внедрение» называют двух-трёх человек, и у каждого это третий приоритет из пяти.

Причина вторая. Горизонт короче цикла изменения

У каждого изменения есть свой естественный срок, и он длиннее, чем хочется.

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

Как это выглядит у вас: через два-три месяца после старта на планёрке звучит «ну и где результат», и никто не может вспомнить, был ли вообще назван срок.

Причина третья. Старый способ остался доступным

Самая частая и самая недооценённая.

Вот что было тяжелее всего на обоих наших внедрениях. Люди привыкали к новым процессам, и при этом кто-то продолжал вести табличку, кто-то писал в почту, какие-то вещи по-прежнему решались напрямую. Есть таблички, есть почта, есть Jira, есть ещё несколько сущностей, в которых человек работает, и он выбирает привычное. Пока не напишешь конкретному исполнителю «я кинул тебе задачу, зайди и закрой», ничего не поедет.

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

Как это выглядит у вас: новая система работает, и рядом с ней спокойно живёт старая табличка, которую никто не отменял.

Причина четвёртая. Первое лицо переезжает последним

Здесь мне придётся признаться.

Я сам не отличился быстрым переездом ни в Confluence, ни в Jira. Долго привыкал, продолжал работать по-старому и не считал это проблемой, потому что вокруг было много других дел. Пока несколько коллег не сделали мне замечание.

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

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

Как это выглядит у вас: вы можете назвать три вещи, которые должны делать по-новому сотрудники, и ни одной, которую по-новому делаете вы.

Причина пятая. Нет цифры, по которой видно движение

«Внедряем клиентоориентированность» проверить нельзя, поэтому через полгода все считают, что она внедрена.

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

Как это выглядит у вас: если спросить пятерых руководителей, внедрено изменение или нет, вы получите пять разных ответов, и все уверенные.

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

Внедрение изменений в компании: порядок, который работает

1. Одно изменение за раз. Компания переваривает ограниченное количество нового. Три параллельных внедрения означают, что не приживётся ни одно.

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

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

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

5. Решить, закрываете ли вы старый канал. Радикально означает быстро и болезненно. Мягко означает год параллельной жизни. Оба варианта рабочие, нерабочий только один: не выбрать и делать вид, что вопрос не стоит.

6. Метрика и ритм. Одна цифра, по которой видно движение, и регулярная точка, где на неё смотрят.

7. Первое лицо переезжает в первой волне. Если не получается силой воли, помогает календарь.

Сколько времени это занимает на самом деле

Левая колонка из моего опыта, правая из наблюдений. Разрыв между ними и есть статистика провалов внедрения.

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

Что остаётся

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

Самое частое изменение, которое компании не могут внедрить годами, это, кстати, вовсе не система и не структура. Это выход собственника из операционного управления — тема отдельного разбора. А про то, почему написанные при внедрении документы не соблюдаются, я разобрал в статье про регламенты в компании.