Привет, Хабр! Меня зовут Настя Шаргородская, я работаю в компании Спортмастер почти 10 лет, за это время я была и бизнес-аналитиком, и руководителем отдела бизнес-процессов и технологий, и методологом продуктовой трансформации, и руководителем направления в работе с объектами стратегического развития.
Сегодня я поделюсь своим опытом управления изменениями, который получила во время руководства проектом по обновлению системы управления жизненным циклом продукта (PLM, Product Lifecycle Management) в рамках цифровой трансформации разработки товаров. Использование комплексного подхода по работе с изменениями позволило не только выполнить проект в срок, в соответствии с бюджетом и скоупом, но и адаптировать сотрудников к новому процессу работы, снизить сопротивление, а также создать целое сообщество change-лидеров, готовых участвовать в будущих трансформациях компании.
Любой проект — это командная работа. Спасибо моей команде: аналитикам, ИТ специалистам, бизнес-экспертам и представителям вендора за активное участие, поддержку и профессионализм. А особая благодарность моей коллеге, Кате Башниной, руководителю продукта PLM, которая помогала в подготовке этой статьи.
Ну, что ж, начнем… Но прежде, чем мы с вами погрузимся в теорию и практику управления изменениями, давайте разберемся, в чем же заключался наш проект обновления PLM.
Что такое PLM и почему его важно было обновить
PLM — это система, которая используется в Спортмастере для разработки собственных и лицензионных торговых марок. Большинство товаров, которые вы видите на полках магазинов Спортмастер, создаются именно с её помощью. В этой системе проходят все основные этапы создания товара от рождения первых идей до финального продукта с согласованной ценой и эталонными образцами для массового производства. Обновление PLM-системы было необходимо, чтобы продолжать использовать лучшие мировые практики в разработке товаров. Помимо этого своевременное обновление гарантировало сохранение расширенной поддержки и оперативную реакцию вендора на все критичные проблемы и вопросы по системе. А также ожидался кратный рост эффективности ряда процессов за счет новой функциональности и изменения интерфейса. Спонсор проекта хорошо понимал важность обновления PLM, а вот всё остальное окружение существовало в мире, где «ведь и так нормально работает». Кто-то работал в PLM уже несколько лет и привык к процессам и интерфейсу, а для кого-то перевод разработки в промышленную PLM-систему завершился совсем недавно, поэтому стресс от изучения и использования нового ИТ-продукта еще не прошел.
Я понимала, что простого проекта «запланировали, согласовали, пошли и сделали» у нас не будет и подойти к управлению надо с умом.
Ключ к успеху: управление изменениями
Когда мы реализуем крупную инициативу, то чаще всего фокусируем внимание на достижение цели, при соблюдении скоупа, сроков, бюджета. Активно работаем над определением дизайна целевого решения, планируем работы и следим за их реализацией.
Но на самом деле успех инициативы связан не только с тем, как успешно мы ведем проект, но и с тем, как мы управляем изменениями и помогаем принимать эти изменения всем вовлеченным сторонам.
Цель управления изменениями — повысить вероятность успеха, снизить затраты, риски и уменьшить стресс сотрудников.
Говорят, что никто не любит изменения, что базовая эмоция при изменениях — это страх. Внешний мир враждебный, и надо обороняться всем вместе, чтобы выжить. Главные реакции на страх – «бей, беги или прикинься мертвым».
Однако люди не всегда против изменений — большинство любят пробовать новое, будь то необычный вкус мороженного, современное течение в моде, путешествие в новую страну или непривычные форматы развлечений (иммерсивный театр, гончарный мастер-класс, полет в аэротрубе или хождение под парусом).
К тому же на то, как человек отреагирует на изменения, можно влиять.
Приведу пример из личного. У меня есть маленький сын четырех лет. Он большой любитель забираться куда-нибудь повыше и прыгать куда-нибудь подальше. Так вот, если он, например, прыгает с дивана и падает на колени, а рядом стоит папа, то наш папа обязательно воскликнет: «Как круто! Давай еще!» И ребенок, даже если ему немного больно от ушибленной коленки, радостно подпрыгнет и полезет опять покорять диван. Но если в такой же ситуации рядом с ним окажется бабушка, то ее первая реакция будет: «Бедный! Ты, наверное, ударился? Тебе больно!» И, конечно, малыш побежит со слезами на ручки, чтобы бабуля поцеловала ушибленную ногу.
Так и мы, взрослые люди, если считаем, что имеем достаточно способностей и воли к изменениям, чувствуем поддержку, то у нас не возникает необходимости сопротивляться переменам, потому что для нас они незначительны.
Но когда наших способностей, компетенций, воли и поддержки недостаточно для решения проблемы или реализации возможности, мы начинаем упираться всеми силами.
Модель Коттера: структура успеха
При управлении изменениями в проекте обновления PLM мы не придерживались никаких строгих моделей, подбирали те инструменты, которые казались наиболее эффективными в наших обстоятельствах. Позже, проанализировав подход, поняли, что на самом деле интуит��вно следовали модели Коттера.
Эта модель известна уже 30 лет. В ней Джон Коттер постарался собрать пошаговый алгоритм внедрения изменений на базе вовлечения сотрудников в осуществление перемен, необходимых компании.
Создание ощущения срочности и неизбежности
Формирование команды реформаторов
Создание и распространение видения перемен
Организация группы поддержки
Устранение барьеров
Достижение первых результатов и празднование побед
Развитие изменений
Закрепление изменений
Давайте подробнее разберем каждый из шагов и то, как мы проходили этот шаг в нашем проекте.
1. Создание ощущения срочности и неизбежности
Первый шаг — убедить участников изменений в неизбежности и важности грядущего будущего. Мол, без новых правил, процессов, систем вообще никак и никуда. Без понимания срочности, важности и неизбежности проект может вообще не начаться или катастрофически растянуться во времени.
Однажды в другом проекте мы столкнулись с неприятием, непониманием неизбежности трансформации, и в итоге проект задержался на год, запустившись лишь после того, как все стейкхолдеры осознали, что откладывать перемены мы больше не можем.
В проекте обновления PLM мы с самого начала создавали атмосферу срочности.
Для этого мы:
Подготовили «железобетонные доводы» срочности и неизбежности изменений (качественные и количественные + референсы других представителей отрасли).
Разработали предварительный план изменений и оценили степень вовлечения ключевых участников, чтобы показать, что у вас все под контролем и мы понимаем, как будем работать.
Погрузили ключевых стейкхолдеров в контекст изменений, обсудили их вопросы/тревоги и сомнения относительно изменений (обсуждения в формате личных встреч).
Организовали серию kick-off (установочных) встреч для спонсора, стейкхолдеров, а также для участников изменений, где:
«Презентовали» потенциальные угрозы, «что будет, если ничего не делать».
Рассказали о возможностях, которые могут быть использованы, «что получим, если сделаем».
Объяснили срочность, «почему важно сделать это сейчас», а не откладывать на потом
Приводили яркие и убедительные доводы
Показали, как будет организована работа, и кто чем будет заниматься.
2. Формирование команды реформаторов
Следующий шаг по модели Коттера — это создание команды реформаторов или по-другому лидеров трансформации. На старте нужно создать такую команду, в которой будут участники, обладающие:
властью;
компетентностью;
авторитетом.
В нашем проекте был следующий состав:
«Власть» — Управляющий комитет: В управляющий комитет мы включили спонсора изменений, заказчиков, представителей кросс-функциональных подразделений (которые могут повлиять на успех проекта), лидера проекта от бизнеса и IT. Также в управляющем комитете были представители вендора. Функция управляющего комитета поддерживать/ корректировать изменения используя свою ВЛАСТЬ.
«Компетентность» — Команда реализации: В команду реализации входили представители разных областей, которые должны быть задействованы в проекте, наши представители КОМПЕТЕНТНОСТИ: IT-специалисты (внутренние и со стороны вендора), бизнес-аналитики, команды поддержки сервисов, обучения, отчетности и т.д.
«Авторитет» — Эксперты: В команду экспертов входило более 70 человек, представляющих каждую роль в процессе разработки товара (дизайнеры, бренд-менеджеры, специалисты по ценообразованию И другие люди). Эксперты на проект выделялись заказчиками из числа конечных пользователей системы, которые обладают достаточным АВТОРИТЕТОМ в командах, знаниями и умениями по работе с системой и людьми. Это важно, так как именно эти сотрудники должны принимать решения от лица всех коллег, находящихся в такой же роли, участвовать в приемке системы, а затем помогать в поддержке коллег в процессе перехода.
Команду мы собрали так, чтобы учесть интересы всех сторон, интегрировать их в проект, разделить ответственность за результат и привлечь к принятию решений.
3. Создание и распространение видения перемен
Создание общего видения
Прежде чем начинать активную совместную работу над проектом, нам было важно убедиться, что видение перемен было едино в команде изменений. Для выравнивания видения перемен между всеми участниками мы сделали воркшоп, где обсудили:
Что такое изменения и почему ими нужно управлять?
Что выиграет компания, департамент и сотрудник при успехе проекта?
Что будет потеряно в случае провала?
Что ожидается от каждого участника в процессе работы?
Что конкретный участник проекта может сделать для успеха изменений?
Что будет наоборот мешать и отвлекать от достижения целей?
Воркшоп помог участникам из разных областей, департаментов и функций обменяться точками зрений, своим опытом, выявить переживания и принять общие решения.
То, что раньше говорила я, как лидер проекта, стало словами и мыслями самих сотрудников.
В итоге у нас сформировалось единое видение изменений, ценности этих изменений, произошла синхронизация действий команды и повысилась вовлечённость.
Распространение видения
Помимо работы с экспертами и членами проектной команды, нам было важно рассказать про грядущие изменения всем пользователям системы, а их у нас на тот момент было более 500, не только в России и странах СНГ, но и в Китае, Бангладеш, Вьетнаме. Пользователи — это и внутренние сотрудники компании, и внешние поставщики, совместно с которыми мы разрабатываем товары.
Чтобы все эти люди могли заранее узнать про изменения мы запустили PLM Upgrade Digest (рассылка полезной информации и новостей по проекту):
Раз в две недели мы отправляли информационное письмо с рассказом о новых функциях системы на русском, английском и китайском языках.
Для поставщиков и внутренних сотрудников создавались разные версии, так как функционал различался.
В дайджестах вёлся обратный отсчет до запуска системы.
Для обратной связи и вопросов была создана специальная почта, которая всегда указывалась во всех рассылках по проекту. Для экспертов и руководителей мы сделали дополнительные рассылки с акцентом на текущие результаты, новости и будущие планы. В этих рассылках мы также отмечали самых активных участников проекта, анонсировали конкурсы и дарили призы.
Таким образом мы создавали постоянный информационный фон. Все сотрудники и поставщики были в курсе происходящих изменений и понимали неизбежность часа X.
4. Организация группы поддержки
70 экспертов, представляющих каждую роль в процессе разработки, стали «лидерами изменений» и нашей «группой поддержки» внутри своих департаментов. Очень важно назначать на эту роль людей, которые обладают авторитетом, системным и критическим мышлением. Определить и вовлечь правильных экспертов нам помог опыт прошлых внедрений, некоторые эксперты прошли с нами не один проект, однако были и новые участники, которым нужно было более детально объяснить их новую роль.
Чтобы эксперты понимали, что от них ожидается, был подготовлен детальный план работ, критерии приемки каждого результата и ожидаемые сроки выполнения задач.
С экспертами мы взаимодействовали на регулярной основе в рамках проектных активностей: встреч, воркшопов, презентаций, но также у нас был единый канал связи в корпмессенджере, где мы делились оперативными новостями, обсуждали общие проблемы, искали наиболее удобные настройки и голосовали за решения, информировали о грядущих мероприятиях.
Нам удалось вовлечь экспертов в создание будущего своих департаментов, разделить с ними ответственность за результат, а также получить настоящую команду поддержки на стороне бизнеса. Наши эксперты могли ответить на вопросы остальных сотрудников, объяснить / обосновать / защитить решения, которые были приняты в ходе реализации проекта.
5. Устранение барьеров
Для оперативного мониторинга и устранения барьеров в проекте мы использовали различные инструменты обратной связи. Вот некоторые примеры:
Опрос по результатам презентации изменений в системе
Прямо во время проведения первой большой презентации изменений в системе PLM мы в режиме реального времени с помощью встроенных в корпоративный сервис опросов собирали обратную связь и оценку каждой новой фишки системы. Оценка показала, что большая часть экспертов позитивно оценивает новые функции, а эксперты смогли подсветить темы, которые требуют более детальной проработки и возможно, кастомизации.
Вопросы по результатам свободного тестирования
Одним из этапов в плане проекта был этап свободного тестирования. После проведенного тестирования эксперты сформулировали свои вопросы по системе и зафиксировали их в общем документе, а команда внедрения подготовила на них ответы. Часть вопросов были вынесены, как темы для более подробного освещения в рамках обучения, а что-то было настоящими багами, которые мы смогли передать на исправление в команду разработки.
Приемочное тестирование
Также важным этапом был этап приемочного тестирования. В ходе которого эксперты проходили по всем шагам процесса разработки товара в новой системе, заполняли успешность/неуспешность прохождения тес��овых сценариев в формате анкеты и фиксировали финальные комментарии. Ряд критичных с точки зрения экспертов моментов был оперативно исправлен непосредственно на этапе тестирования, и мы получили единогласное GO решение, часть некритичных доработок была отложена на период после обновления PLM. Эксперты пошли на компромисс и не стали мешать дальнейшему обновлению, так как доверяли команде и верили, что все договоренности будут исполнены.
Доработки системы в процессе реализации
Когда нам надо было оперативно принять решения по изменениям системы или процесса работы, мы использовали инструмент голосования в чате экспертов, где было удобно быстро связаться со всеми 70 экспертами и оперативно получить общее мнение по вопросу.
Конечно, команда проекта могла бы выполнить все этапы тестирования самостоятельно, а также единолично принять решения по необходимым настройкам системы, но я уверена, что в этом случае мы бы могли упустить важную специфику работы пользователей (мы все-таки не дизайнеры, не бренд-менеджеры и не костеры), а затем столкнулись с большим сопротивлением со стороны пользователей, эскалацией несовершенств системы и риском заморозки всей инициативы.
Будьте открыты, благодарите коллег за активность и оперативную обратную связь. Пусть ваши эксперты делятся своими переживаниями с командой проекта, чем идут жалуются руководству на незначительные дефекты. Жалоба не ускорит решение, а наоборот затормозит прогресс и создаст нездоровый климат в коллективе.
6. Достижение результатов и празднование успехов
У нас была дорожная карта бизнес-инициативы. Поэтому о каждом пройденном этапе мы на ежемесячной основе рассказывали нашему Управляющему комитету, а также освещали результаты этапов в нашем Digest для экспертов и их руководителей.
Но главный результат, который мы все очень ждали — это получение единогласного GO решения по обновлению системы PLM.
В проекте участвовало 10 различных команд, включая команду вендора, и нам было важно получить подтверждение готовности от представителей всех команд. Для того, чтобы работа шла синхронно, мы на еженедельной основе синхронизировались и планировали работы, подсвечивали проблемы и искали решения. Каждый, кто входил в рабочую группу, понимал важность своего решения и очень ответственно выполнял все запланированные шаги.
Когда мы получили единогласное GO решение от всех сторон — это было большое событие. Чтобы совместно отпраздновать завершение большого этапа мы организовали мероприятие для всех, кто участвовал в проекте. Там мы наградили коллег похвальными грамотами, присвоили бейджи «гуру проекта», самым активным экспертам начислили корпоративные бонусы. На мероприятии все пообщались в неформальной обстановке и поделились впечатлениями по проекту.
Для людей, которые участвуют в изменениях, вкладываются в успех этих изменений, очень важно почувствовать признательность руководства и коллег, понять, что все эти дополнительные часы тестирования, обучений, правок кода, презентаций все это важно, нужно и ценно. Возможность разделить эту радость со всеми участниками проекта очень вдохновляет на будущие свершения и запускает механизм непрерывного развития и совершенствования в коллективе.
А еще мы сделали сюрприз для сотрудников, которые пришли в офис в день запуска новой версии PLM – украсили офис в стиле Halloween (ведь эти дни совпали) и угостили коллег праздничными PLM-шками с предсказаниями.
На главную страницу обновленной системы PLM мы тоже поставили веселую тыкву для создания праздничной атмосферы.
7. Развитие изменений
После того как мы официально перешли на новую версию системы, работа с изменениями не закончилась.
В течение месяца команда проекта обеспечивала гиперподдержку, отвечая на вопросы всех наших 500 пользователей. Бизнес-эксперты играли ключевую роль на этом этапе, помогая коллегам адаптироваться к новой системе. За это время нам накидали ещё горочку новых идей. Работа с новыми некритичными запросами строилась в рамках стандартного процесса управления изменениями.
8. Закрепление изменений
Для устойчивого закрепления изменений мы создали:
Более 150 обучающих видеороликов.
Тренинги на платформе обучения с тестами для проверки знаний.
Обучения пользователей проходили при непосредственном участии экспертов предметных областей и аналитиков. Мы использовали концепцию Train the trainer, когда сначала обучаются ключевые пользователи, а затем они проводят обучения для всех остальных сотрудников. Плюс мы подготовили специальную тренинговую среду, где любой сотрудник мог ознакомиться с новым интерфейсом и функциональностью системы без риска «испортить» рабочую базу данных.
Все это помогло пользователям быстрее освоить новую систему и адаптироваться к изменениям.
Выводы и уроки
Залог успеха внедрения изменений — это коммуникация, команда и качество работы. Люди по-разному реагируют на изменения: кому-то нужно больше времени, чтобы адаптироваться, и это нормально, не торопите их. Если бы проект начинался заново, мы не стали бы переживать из-за неидеального хода событий, а просто бы сфокусировались на вовлечении и поддержке.
А как вы работаете с изменениями в вашей компании? Насколько эта работа отстроена на системном уровне? Буду рада, если поделитесь в комментариях.