Привет, Хабр! На связи Надежда Костякова, техлид в ПГК Диджитал. Мы разработали «Оптимизатор ремонтов», инструмент, который позволяет быстро и эффективно формировать план технического обслуживания вагонов. Однако на этапе внедрения столкнулись с проблемой — коллеги неохотно переходили на новую систему, продолжая вести расчеты в электронных таблицах. Сегодня я поделюсь историей о том, как нам удалось развеять их сомнения — и при чем здесь методология change management.
Немного контекста
Первая грузовая компания — оператор грузовых железнодорожных перевозок. Наш парк насчитывает около ста тысяч вагонов. Очевидно, каждый из них должен быть в исправном состоянии. Если вагон ломается в пути, он сразу направляется на текущий ремонт. Все платформы также проходят регулярный технический осмотр — раз в три года или каждые 160 тыс. километров. Планированием ремонтов занимаются коллеги из отдела техобслуживания (мы их называем «вагонниками»), и это не самая простая задача. Нужно учитывать тип вагона, его текущее местоположение, расстояние до ближайшего ремонтного депо и места, куда он должен отправиться после — чем дольше вагон движется пустым, тем больше денег теряет компания.
Для составления плана ремонтов специалисты вагонного блока долгое время использовали электронные таблицы и проводили расчеты вручную. При таком подходе процессы шли довольно медленно: нужно постоянно учитывать новые вводные от подрядчиков и меняющиеся внутренние факторы — скорости ручным расчетам это точно не прибавляет. Чтобы помочь коллегам, мы в ПГК Диджитал разработали специальный инструмент — «Оптимизатор ремонтов». Он составляет график техобслуживания на месяц вперед и дает рекомендации. Однако на этапе внедрения «Оптимизатора ремонтов», мы столкнулись с проблемой — коллеги игнорировали новый инструмент, предпочитая привычные электронные таблицы. Все же хорошо — планы планируются, вагоны ремонтируются, колесные пары подкатываются. Но мы видели, что новая система эффективнее, она в десятки раз ускоряет проведение расчетов. Чтобы переубедить вагонников, вовлечь их в осуществление необходимых для организации перемен, мы применили методологию управления изменениями.
Что это за методология
В 1960-х годах американский психолог Элизабет Кюблер-Росс выделила пять стадий принятия неизбежного, которые известны многим. Это — отрицание, гнев, торг, депрессия, смирение. Со временем модель вышла за пределы медицины и психологии и нашла применение в других областях — например, в бизнесе, где человеку часто приходится адаптироваться к изменениям. Для этих целей оригинальная концепция была детализирована, и современная версия включает семь стадий:
Шок. Первая реакция сотрудников на нововведение, которая, как правило, влечет за собой снижение продуктивности.
Отрицание. Сотрудники считают, что изменения не нужны.
Фрустрация. Страх неизвестного, продуктивность продолжает падать.
Уныние. Принятие неизбежного, уровни мотивации и энергии понижаются, а чувство тревоги обостряется.
Эксперимент. Сотрудники начинают разбираться, как на них влияют предлагаемые изменения.
Решение. Продуктивность растет, потому что большая часть коллектива понимает, как работать в новых условиях.
Интеграция. Заключительная стадия, когда новое становится привычным.
Очевидно, что процесс принятия нового проходит в компаниях довольно болезненно. Руководству недостаточно объявить о структурных или системных изменениях, необходимо помочь персоналу адаптироваться к модифицированным регламентам.
Чтобы преодолеть кризис трансформации в бизнесе, Джон Коттер, эксперт в области лидерства и перемен, предложил методику управления изменениями. Она базируется на исследовании более ста организаций. В основе модели лежит идея, что если сотрудники поймут пользу преобразований, то будут содействовать их продвижению. Фреймворк включает восемь шагов: 1) создание острого ощущения необходимости, 2) формирование команды единомышленников, 3) формулировку общего видения, 4) обсуждение новых идей, 5) обход препятствий, мешающих внедрению изменений, 6) достижение первых успехов, 7) закрепление успехов, 8) закрепление новых практик.
В 2008 году фреймворк Коттера применил производитель телекоммуникационного оборудования Ericsson. Тогда компания выходила на рынок 4G и проходила через масштабную реструктуризацию. В это время топ-менеджмент проводил регулярные встречи с сотрудниками, на которых ставил краткосрочные цели, хвалил работников за успехи, повышая их мотивацию. Как отмечают специалисты, которые трудились в компании на тот момент, руководство сыграло огромную роль, помогая адаптироваться к изменениям.
Помимо фреймворка Коттера, существуют и другие методики change management. Одна из известных — теория трех ступеней американского социолога Курта Левина. Он утверждал, что перемены для человека или организации — непростой путь, который состоит из нескольких стадий трансформации, ведущих к равновесию. Концепция Левина включает в себя три ступени:
«Разморозка». Заключается в осознании необходимости изменений.
«Движение». Непосредственно процесс трансформации.
«Заморозка». Характеризуется принятием новых принципов работы.
В каком-то смысле теория Левина включает все шаги, предложенные Джоном Коттером, но при этом более компактная. Мне нравится её терминология, и именно на неё я буду опираться в рассказе о том, как мы убедили коллег дать шанс «Оптимизатору ремонтов».
«Размораживание» вагонного блока
Показываем необходимость изменений
Первый этап методологии является определяющим, и от него во многом зависит конечный результат. Прежде всего нужно наладить эффективную коммуникацию и преодолеть начальное сопротивление. Иными словами, необходимо убедить людей в безотлагательности перемен, выделив проблемные места и возможные решения.
Мы решили сформировать картину положительных изменений. В качестве оптимального показателя выбрали экономический эффект от внедрения «Оптимизатора ремонтов». Мы посчитали выгоду, которую получает компания при переходе на новый интеллектуальный инструмент: сумма затрат на ремонт при использовании «Оптимизатора ремонтов» оказалась меньше, чем при ручном расчете, потому что новый инструмент мог учесть больше факторов (например, по возможности объединять текущий и плановый ремонты, чтобы не отправлять вагон в депо два раза подряд). И это стало сильным толчком в осознании потребности. Для доведения информации до исполнителей мы провели ряд встреч, в основном демо, на которых транслировали новую позицию: «Оптимизатор ремонтов» может быть полной заменой работе с таблицами.
Привлекаем единомышленников
Далее, согласно методологии, мы занялись формированием команды единомышленников. Руководство вагонного блока поддерживало нас с самого начала, но нам нужно было привлечь на свою сторону рядовых вагонников. Тут стоит отметить, что мы продолжали (и продолжаем) дорабатывать «Оптимизатор ремонтов»: инструмент должен учитывать новые вводные от вагоноремонтных предприятий и другие изменяющиеся параметры внешней и внутренней среды. К тому же, мы постоянно в поиске решений, которые помогут нам повысить общую эффективность «Оптимизатора ремонтов» и дадут значимое улучшение в метрике стоимости ремонта.
На этом этапе мы отметили, что коллеги из отдела технического обслуживания никак не вовлечены в процесс разработки. В итоге они не чувствовали себя частью команды, хотя инструмент создавался именно для них. Чтобы исправить положение, мы обратились к одному из стейкхолдеров, готовому работать с нами и давать критическую оценку всем предлагаемым доработкам с позиции вагонников. Мы попросили его анализировать все предложения Discovery-команды еще до старта работ, чтобы отбирать только действительно нужные и ценные. Благодаря его вкладу, мы смогли разгрузить Discovery-команду и получить дополнительное подтверждение важности выбранных доработок.
Распространением нового видения — о том, чтобы полностью заменить Excel на «Оптимизатор ремонтов» — занялась команда топ-менеджеров вагонного блока. Мы со свой стороны помогали проводить презентации и старались привлечь еще больше пользователей к процессу улучшения сервиса (об этом ниже).
«Движение» вагонного блока
Второй этап методологии включает перестройку процессов, противоречащих новому видению. Здесь формируются и применяются практики, которые постепенно вливаются в привычный распорядок дня. Важно активно продвигать установленные цели, чтобы сотрудники не отклонялись от намеченного курса.
Устраняем препятствия
Еще на первом этапе мы перестали рассчитывать, что специалисты отдела техобслуживания будут пользоваться инструментом сами просто потому, что он хорошо работает. Если сначала, чтобы сдвинуть процесс с мертвой точки, мы делали акцент на финансовую выгоду, то далее стали объяснять коллегам, что «Оптимизатор ремонтов» не просто полезен, но и удобен.
В основном упор делали на то, что планирование с помощью нового решения даст вагонникам возможность работать быстрее и легче. Например, при формировании плана ремонтов иногда требуется рассчитать несколько сценариев. Раньше расчет одного сценария мог занимать сутки. Новый инструмент справляется с задачей за 10 минут, что увеличивает вариативность планирования и позволяет стратегически подойти к будущему циклу плановых ремонтов. Несколько раз попробовав провести такой расчет, коллеги почувствовали интерес к «Оптимизатору ремонтов».
Кроме того, нам было важно сделать новый инструмент максимально удобным для пользователей. Для этого мы проводили опросы в письменном виде и на встречах в формате брейншторма. В процессе люди предлагали изменения, которые должны произойти в «Оптимизаторе ремонтов» для того, чтобы пользоваться им стало просто и легко. С одной стороны, такой подход позволил нам улучшить юзабилити сервиса, с другой — мы продолжили вовлекать рядовых пользователей в процесс доработки. На смену безразличию пришла личная заинтересованность в продукте.
Достигаем первых результатов
Некоторое время «Оптимизатор ремонтов» и Excel существовали параллельно: коллеги продолжали пользоваться таблицами, а мы рассчитывали план ремонтов в новом инструменте. Возможно, в нашем случае это стало дополнительным рычагом для изменений — месяц за месяцем наш расчетчик показывал лучший результат, так что польза «Оптимизатора ремонтов» стала очевидна даже консервативным коллегам.
Закрепляем успех
Сейчас мы находимся на этапе закрепления успеха. Одна из важных задач — сделать так, чтобы пользователи обращались к нам для учета всех текущих изменений. Дополнительную сложность вносит то, что процесс планирования ремонтов постоянно меняется, и наш релизный цикл должен быть очень коротким, чтобы к новому этапу планирования все доработки уже были протестированы и выведены в прод. Релизный цикл для нас составляет две недели (раз в спринт). Чтобы работа в таких условиях была эффективной, мы ищем возможности улучшить практики разработки. Например, недавно мы выделили отдельную роль Delivery-менеджера под планирование и выкатку релизов.
«Замораживание» вагонного блока
Цель заключительного этапа — закрепить успех. Несмотря на все трудности, «Оптимизатор ремонтов» стал основным инструментом при составлении планов. Что не менее важно, пользовательская база активно расширяется — например, к системе присоединились экономисты и работники других направлений вагонного блока. Мы провели исследование и подсчитали индекс потребительской лояльности (NPS): пользователи не испытывают сложностей в работе с сервисом и готовы рекомендовать его.
Для нас дополнительным подтверждением того, что «Оптимизатор ремонтов» окончательно прижился, станут самостоятельные запросы от пользователей на доработку нашего инструмента. Если в начале мы в основном долгими опросами и исследованиями «выбивали» из них идеи, то через некоторое время они сами будут придумывать новые гипотезы и фичи. И к этому, я надеюсь, мы когда-нибудь придем — не без помощи методологии управления изменениями.