Все статьи

Иван Селеверстов

Business Agility Coach c опытом работы в разных сегментах бизнеса.

Развивает направления Business Agility, SAFe® и OKR в России. Публичные кейсы: ГНИВЦ, Вконтакте, Сбер Банк Беларуси, РТЛабс, СберЗвук Бизнес, NX Studio, Главстрой, КиноПоиск, Xsolla, Inpas Soft, Билайн.

Подробнее

Проворная розница: физический мир с цифровой начинкой

Дата: 07.11.2021

История Agile-трансформации торговой сети «Пятерочка»: 70 тыс. кассовых аппаратов, 16 тыс. магазинов, 66 регионов России и 1 трлн чистой розничной выручки — в ИТ-инфраструктуре, которую необходимо своевременно обслуживать, устанавливать обновления и добавлять новые сервисы.

Доклад с конференции AgileDays 2020 Валерия Петриева (ТС «Пятерочка») и Ивана Селеверстова (ScrumTrek).

Модератор: Доклад «Проворная розница: физический мир с цифровой начинкой», Валерий Петриев, Иван Селеверстов. О пути, который прошла компания «Пятерочка», которую все мы прекрасно знаем и любим. Я лично хожу не каждый день, но довольно часто, и вижу, как всё меняется.

Иван Селеверстов: Я — партнер компании ScrumTrek. Работаю с энтерпрайзами, в основном по продуктовой трансформации, а также помогаю выстраивать целеполагание.

Валерий Петриев: Я руковожу центром компетенций продуктового подхода торговой сети «Пятерочка». Наш центр компетенций – это тот, кто воплощает различные изменения в жизнь.

Иван Селеверстов: Мы расскажем, какие изменения мы сделали, чтобы сделать Agile-трансформацию в торговой сети «Пятерочка». Будем рассказывать о технике Lean Change Management (LCM): покажем на практике, какие инструменты применяли.

Для кого будет интересно? Для тех людей, кто уже в пилоте применяет Agile, или только собирается применять Agile, или вы пошли в пилот, и в какой-то момент у вас всё затормозилось. Как раз об этих практиках, которые помогут вам сдвинуть ваш пилот и двигаться вперед, мы сегодня будем рассказывать. Теперь что такое «Пятерочка»?

Валерий Петриев: Торговая сеть не нуждается в представлении. По итогам 2019 года – это более 16 тыс. магазинов на территории 66 регионов нашей страны, а также больше 1 трлн чистой розничной выручки. Но это не так важно. Важно то, что она рядом, и более 11 млн покупателей ежедневно покупают там товары первой необходимости.

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

Для чего я всё это говорю? Чтобы чуть-чуть описать масштаб и ту скорость изменений, которую нам диктует рынок и наша собственная стратегия. Производственным подразделениям, которые находятся внутри, необходимо соответствовать очень амбициозным целям компании и рынка в целом. Глядя сверху на масштаб компании, которая управляет 70 тыс. кассами в магазинах, а количество магазинов растет каждый месяц, мы понимаем, что каждая точка обслуживания – это не просто обслуживание нашего гостя. Это также инфраструктура, которую со стороны ИТ необходимо своевременно обслуживать, устанавливать обновления, добавлять новые сервисы. Это огромный парк, который должен, с одной стороны, работать быстро, с другой стороны — абсолютно стабильно. Цена ошибки, попавшей в продуктив, слишком высока. Мы не можем себе позволить остановить продажи по всей стране.

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

У нас был стимул к изменениям, и это — самое главное. Мы начали изучать рынок (зачем выдумывать велосипед?) на предмет существующих на рынке методологий. Это в основном методологии масштабируемого характера уровня энтерпрайза, и поняли, что большинство из них предполагает не просто изменение процессов, а скорее глубокую перестройку самого бизнеса, в том числе, и оргструктуры.

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

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

Дальше встал вопрос, как двигаться, с чего конкретно начать. Здесь нам помогли наши партнеры, пришли, собрали нас и провели сессию Value Stream Mapping, в рамках которой мы подробно изучили наш производственный процесс, выделив  контур изменений и ключевые метрики, по которым будем понимать, куда мы движемся и достигаем ли цели.

Иван Селеверстов: Когда мы провели сессию Value Stream Mapping и нарисовали все проблемные места, мы спрашивали сотрудников: «Вы готовы за это взяться? Готовы что-то поменять?» В глазах читалось: «Опять пришли нас трогать, пришли нас менять? Мы не верим уже в эти изменения. Сколько можно?» Люди не были готовы не то, чтобы меняться, они не верили в изменения, которые могут быть, потому что до этого уже были попытки что-то сдвинуть.

Value Stream Mapping собран, проблемы собраны, Action plan есть. Но тех людей, которые будут отвечать за Action Plan, нет. Нам пришлось распустить людей, а самим решать, как их вовлечь в работу.

Есть два пути изменений — Big bang и путь постепенных изменений. Мы начали смотреть, что можно было бы сделать. Когда начинают какую-то масштабную трансформацию, самый простой способ – «сверху» сказать «надо делать», и у заказчика была эта возможность. Но это не всегда приводит к результатам.

Но что здесь еще очень важно? Обычно Big bang приводит к следующему подходу, к трансформации в стиле строительства «потемкинской деревни». Раньше был менеджер проекта, теперь станет Scrum-мастер. Раньше был главный по маркетингу, теперь стал Product Owner.

Если вы зовете профессиональных людей, которые уже давно занимаются трансформациями, они вам скажут, что есть еще один подход, который называется «давайте сделаем пилот». Сделаем пилот, начнем там работать, применим лучшие практики, выберем людей, которые готовы меняться, потом это всё масштабируем на всю компанию. Самая большая проблема компании — масштабировать этот пилот. Бывают случаи на рынке, когда компании отдельно отстраивают пилот, показывают, как это можно сделать по-другому, делают чуть ли не отдельную компанию, потом говорят: «Теперь вливаемся и на всех делаем то же самое». Но на слиянии возникает масса проблем интеграции процессов и продуктов.

Можно пойти по другому пути — запустить процесс постоянных изменений, и не просто изменений, а набора процессных экспериментов.

Такой подход называется Lean Change Management.

Lean Change Management – это инструмент, который считает, что ваши изменения – это продукт в запутанной системе, и к нему надо подходить так же, как и к любой продуктовой разработке. Мы работаем экспериментом, находим пути движения, и потом, исходя из различных вариантов экспериментов, получаем инсайты и масштабируем эти изменения или не масштабируем.

Вроде бы всё понятно, а что под капотом? А под капотом, продуктовый подход, но только к изменениям — команда изменений, инструменты продуктовой разработки, бэклог изменений. Мы должны измерять эти изменения, мы должны работать циклами для того, чтобы быстро проверять гипотезы и по результатам оценивать эффективность движения команды.

Мы использовали Lean Change Management Canvas — это инструмент, который помогает вам визуализировать вашу работу по изменениям.

Как это применили в конкретном случае с «Пятерочкой»? 

Мы взяли лучшие практики из этого фреймворка и начали работать итеративно-инкрементально. Мы работаем недельными циклами. В начале недели мы формировали гипотезы, ставили эксперименты, выбирали контур, куда «сбрасывать бомбы», и сбрасывали их в течение недели, смотрели на результаты, какие плоды дали эти изменения, и после этого демонстрировали результаты, получали обратную связь и оценивали работу команды.

Оценка работы команды – отдельная важная техника. Вы должны понимать, делая  небольшие изменения за неделю, нужно уметь оценить результаты. Часто применив изменения, результат можно было оценить через две-три недели.

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

Валерий Петриев: Вся работа строится на шаблоне эксперимента, когда мы понимаем, что мы хотим сделать, для чего мы хотим сделать, как мы потом измерим конечный результат. Слово «измерим» – это самое правильное, самое важное слово в этой фразе.

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

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

Первое, во что уперлись – это как оценивать метрики. Почему это важно? Потому что без них элементарно возникало очень жгучее желание понабирать кучу работы. Что там делать? Сейчас напишем – выпустим, напишем – выпустим. Не тут-то было.

Мы начали замечать, что что-то идет не так, у нас медленно идет продвижение к цели. Начали ставить себе оценки. Даже здесь уже метрики начали играть нам в плюс, потому что, как только мы начали ставить себе оценки, как мы сами поработали, сразу возникло ощущение, что что-то идет не так, и начались вопросы: «Как же? Мы же много, что сделали». Сделали-то мы, может быть, много, а результата принесли не так много, как хотелось бы.

Тут нам опять помогают гибкие практики, то самое ограничение на работу в прогрессе из Kanban-метода. Это первое, что приходит на ум. Сказано – сделано, применили. Самое первое, что потребовалось – это ограничить работу, те обязательства, которые мы сами на себя берем. Только удерживая фокус, мы смогли выйти на прогнозируемое продвижение к нашим целям.

Иван Селеверстов: Когда ребята научились работать по целям и метрикам —  поменялось мышление.

В таком режиме мы проработали два месяца, сделали различные эксперименты, различные пилоты и нашли наилучший фреймворк для масштабирования на магазинах  IT-инфраструктуры. Следующие два месяца группа изменений занималась внедрением фреймворка масштабированием Agile на 150+ человек.

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

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

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

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

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

Управление командой – это отдельная история. Если у вас есть группа человек, которая работает в какой-то оргструктуре и даже содержит в себе кросс-функциональные элементы, это ещё не значит, что они  — команда, что они культурно готовы воспринимать себя как часть чего-то большего, брать ответственность за общий результат и ориентироваться на цели бизнеса.

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

Меняется работа самим менеджментом. Когда у тебя на одном поле сходится так много областей, в которых требуется изменения, это требует и подстройки всей организации. Хотите изменить мир, не сломав его? LCM – один из лучших инструментов, который может помочь это сделать.

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

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

Иван Селеверстов: Делайте изменения. Изменения – это не только процессы.

SAFe® для команд
Тренинг SAFe® for Teams дает навыки работы в Agile-команде, которая в рамках Agile Release Train (ART) совместно с другими Agile-командами и заинтересованными лицами разрабатывает единое решение. По окончании тренинга и сдачи выходного экзамена участники получают международный сертификат Certified SAFe® Practitioner (SP).

Поделиться

VK
Telegram