Все статьи
Год в сапогах — меняем всю компанию при запуске трайбов в бизнес-линиях
Дата: 29.06.2022
История банка «Открытие» о том, как системно настроить Enterprise Agility в большой компании. Что реально работает и что оказалось самым полезным для бизнеса. Это взгляд практика стратегии и бизнес-развития на Enterprise Agile-трансформацию.
Доклад на конференции Enterprise Agile Russia 29 ноября 2021 года.
Я вице-президент банка «Открытие» и представляю департамент стратегии. Сегодня расскажу, как глазами менеджмента, глазами стратегов посмотреть на то, как создает или не создает добавленную стоимость Enterprise Agile-трансформация и почему.
Есть у сторителлеров такая мудрость: все события, которые с вами происходят, делятся на две большие категории. Одни события приносят вам удовольствие и счастье, а о других мы потом рассказываем истории. И у меня для вас будут три истории про год в сапогах «Открытия», про то, как мы сделали Enterprise Agile-трансформацию. На самом деле, эта история больше грустная, чем веселая, — она про наши уроки, про то, с чем мы столкнулись и что у нас болит в результате этого движения.
Содержание статьи
История первая — наш текущий setup
История первая — это наш текущий сетап, то, как мы организованы на сегодняшний день. Первый слайд — это то, какого масштаба была Enterprise Agile-трансформация в «Открытии». Это три бизнес-линии: КИБ (корпоративно-инвестиционный бизнес — прим. ред.), розница и малый-средний бизнес. Здесь важны не цифры, а несколько других моментов. Оглядываясь назад, я понимаю, что решение о том, как быстро мы движемся и как глубоко, принципиально, фундаментально важно для успеха. Сначала я дам тактический взгляд на эту тему, а потом — стратегический.
Тактический взгляд:
- Первое, нам нужно идти достаточно быстро и достигать достаточно серьезного масштаба трансформации просто потому, что если мы будем на протяжении года или нескольких лет слишком маленькими, мы, с точки зрения бизнеса, никаких реальных эффектов не увидим. Это первый аспект, который двигает нас к тому, чтобы делать трансформацию быстрее.
- Вторая история связана с тем, что мы не можем себе позволить внутри компании долго поддерживать две разные модели. К примеру, в рознице есть часть команд, которые пришли в формат трайбов, или в формат динамической бизнес-модели, как мы ее называем, — они синхронизируются уже в новой логике. И есть часть компании, которая работает еще в старой логике динамических проектов. Чем больше мы накапливаем этот разрыв внутри одной бизнес-линии, — то есть между одной частью компании, которая уже трансформировалась, и той, что синхронизируется по-старому — тем сложнее этой конструкцией управлять.
- Компания при Enterprise Agile-трансформации требует изменения не только продуктовых процессов и процессов поставки, она требует еще и изменения процессов поддержки. Это бизнес-планирование, бюджетирование, система мотивации и оплаты труда, карьерное развитие и другие элементы инфраструктуры, которые нужны для того, чтобы модель изменилась. И тут снова возникает вопрос: насколько большими мы должны быть с точки зрения работы в целевой модели, чтобы было рационально поддержать те изменения, которые мы проводим в продуктовой поставке, чтобы поменять структуру бизнес-плана и бюджета, поменять принципы управления карьерой и так далее.
Это те аргументы, которые говорят в пользу того, что нужно делать Agile-трансформацию быстрее. С другой стороны, есть аргументы, которые не позволяют делать ее мгновенно.
Недавно в Enterprise Agile-сообществе была дискуссия по поводу кейса ING Bank AIG о том, насколько хорошо работает Big-bang трансформация. Заглядывая назад в историю, когда мы смотрим на динамику стоимости ING Bank AIG в сравнении с отраслевыми и банковскими бенчмарками, мы видим, что ING Bank AIG, который сделал Big-bang трансформацию, с точки зрения рыночных индикаторов на горизонте пяти лет смотрится гораздо хуже всей остальной индустрии технологической и банковской в частности.
Поэтому скорость ограничивается:
- Нашей способностью подготовиться к работе в новом формате.
- Способностью перестроить и пересобрать команды по новой логике, чтобы они не останавливались, — ведь любая трансформация тормозит продуктовые команды.
- Финансами. Мы запускали трайбы в условиях ограниченного бюджета, и у нас не хватало средств для того, чтобы трансформировать всю компанию за один год. Это реальные инвестиции, которые компания должна осознанно реализовывать для осознанного эффекта.
Поэтому выбор между тем, как глубоко мы готовы погрузиться, и какая скорость должна быть, чтобы компания была в состоянии это переварить, важный и принципиальный.
Значение бизнес-модели — разделение бизнес-ответственности в трайбах
Достаточно сложный слайд, как проверка зрения у окулиста. Им я хотел донести, что еще важна логика построения модели. Этот слайд показали нам McKinsey в начале пути. Мы, как все приличные компании, подумали, почему бы не начать Enterprise Agile-трансформацию с McKinsey. И начали с них. Мы можем делать три сетапа построения Value Streams (потом их можно называть трайбами):
- Продуктовый сетап, когда мы строим вокруг продукта сквозные кросс-функциональные команды.
- Канальный сетап, когда мы пытаемся сделать лучшие каналы и выстраивать команды, к примеру, вокруг цифрового канала, вокруг канала контакт-центра или канала работы физической сети.
- Value Streams вокруг сегментов.
Первоначально мы выбрали гибридную модель. Все-таки ядро решения — это построение вокруг продукта. Для нас это было достаточно болезненно, потому что мы, собирая сквозной клиентский путь вокруг продукта, разбирали канальные команды. Во многих компаниях есть сильные Интернет-банк и мобильный банк, которые развиваются как самостоятельная платформа, и хорошо работают, когда они вместе. И мы, запускаясь и перезапускаясь вокруг продукта, переставляли команды, которые отвечали, к примеру, за открытие вклада в дистанционном банке в продуктовую команду, в продуктовый трек вклады, и так далее. Мы пересобирали весь IT-ресурс и весь продуктовый ресурс вокруг сквозного клиентского пути.
Как мы сейчас понимаем, сложности пересборки такой структуры очень серьезные — это приводит к замедлению команд. Возвращаясь к тому, как быстро мы готовы меняться, какое замедление мы себе готовы позволить? Но наша цель заключалась в том, что мы все-таки внутри одной P&L-ответственности (Profit and Loss, прибыль и убытки — прим. ред.) покрываем сквозной end-to-end клиентский путь.
Мы разобрали старые команды, собрали в сквозной клиентский путь вокруг продукта. Также задизайнили, но не сделали сегментный трайб, который назывался «трайб Premium», — по идее, это был Value Stream вокруг потребностей клиентов премиального сегмента. У нас была гипотеза, что для таких клиентов нужно иметь отдельные клиентские пути, отдельные продукты и так далее. Почему не сделали? Потому что оказалось очень дорого, потому что вся логика продуктовой разработки в банке и платформ в банке построена вокруг IT-систем. И если ты собираешься сделать сегментный трайб, автоматически ты должен в этом трайбе повторить весь IT-ландшафт. Это, с точки зрения управляемости и инфраструктуры, оказалось очень сложной конструкцией, которую тяжело осуществить. Поэтому в результате базовое ядро нарезки, которую мы выбрали, была продуктовая нарезка. И даже переход к простой продуктовой нарезке без выделения сегментов, проходил очень болезненно для нас с точки зрения именно стабильности команд, их замедления, оттока людей. Это важная история, которую мы осознаем, оглядываясь назад спустя год этой трансформации.
Как устроена мотивация трайбов — синхронизация с KPI правления банка
Это слайд про то, как строится управление перфомансом этих трайбов внутри «Открытия». Здесь тоже был определенный путь, который мы прошли. На слайде вы видите, чего мы добиваемся сейчас. Это дизайн той системы, на которую мы переходим с начала года. Мы пытаемся каскадировать метрики, которые стоят у борда управления в метрики трайбов, которые собраны вокруг продуктового P&L. Мы дизайним трайбы именно как Business Unit с P&L-ответственностью, и каскадируем все показатели.
Это RUN-показатели (операционные показатели — прим. ред.): прибыль, объем продаж, Cost to Income Ratio (CIR, отношение операционных расходов к доходам — прим. ред.), отдача на капитал. С точки зрения системы мотивации эти бизнес-юниты имеют RUN-показатели, и, что важно, эти показатели распространяются не только на команды бизнеса, которые находятся внутри трайба, но и на команды IT. Речь идет о том, что и айтишники, и бизнес переходят на единый набор KPI (Key Performance Indicators, ключевые показатели эффективности, КПЭ — прим. ред.) и в этом наборе показателей эффективности, помимо бизнес-метрик, появляются еще технические метрики. Корректирующий блок показателей в нашем случае — это глубина технического долга и количество ошибок в продуктивном окружении.
Легко сказать, что мы перевели айтишников на бизнесовые KPI. Но действительно сложным в этом движении стало то, что изменения в бизнесе были довольно инерционные. Например, результат, который трайб «Ипотека» делает, продавая ипотечные кредиты в четвертом квартале этого года, во многом определяется портфелем, который был создан полгода или даже год назад. Когда говоришь айтишникам, что они с нового года или с 1 апреля будут отвечать за бизнес-метрики, у них возникает вопрос: «А почему? Эти результаты ведь определяются тем бизнесом, который был сделан за год до нас и без нас».
В этом переходе мы с айтишниками договорились о грейс-периоде. Мы принципиально договорились при запуске трайба, при его дизайне о том, что ставим для всех общие KPI, но мы дали грейс-период полгода для того, чтобы айтишники поняли, как эти KPI работают, как меняется динамика бизнеса, как продуктовые инкременты, которые они делают, реально влияют на воронки и на показатели эффективности. И уже только после этого переводим их на общие с бизнесом KPI.
Параллельно бизнес должен разобраться в технических метриках насколько сильно они могут влиять на технический долг, насколько сильно от них зависит количество дефектов в продуктивном окружении. Соответственно, увязка двух систем KPI при запуске общей конструкции тоже была важным уроком при построении модели и при проведении Change-менеджмента.
Определение приоритетов по трем направлениям
Еще один вопрос, который мы должны были решить, — вопрос скоринга и приоритизации задач. Здесь тоже была история для нас довольно сложная. Нас, кстати, ScrumTrek об этом предупреждал. Помните, когда я говорил, что мы нарезались в продуктовые трайбы, вокруг продуктов «Ипотека», «Кредит наличными» и «Кредитные карты»? Когда мы делаем такую нарезку, это автоматически означает, что мы закрепляем определенный объем ресурсов разработки банка за определенными продуктовыми направлениями, и закрепляем достаточно надолго. Если мы для себя принимаем решение, что мы надолго закрепляем ресурсы, мы должны быть готовы к тому, что у нас продукты внутри компании приносят разную рентабельность, разный доход.
Есть кредит наличными, есть ипотека, есть транзакционные продукты. Например, в трайб по кредитам наличными — самый доходный в рознице, мы вложили определенный ресурс, но через полгода поняли, что нужно вложить в два раза больше ресурсов в этот бизнес для того, чтобы сделать тот бэклог, который позволяет нам достигать бизнес-целей. Это означает, что мы должны забирать ресурсы с других трайбов, но тогда, они становятся нежизнеспособными. У нас даже появилось понятие Minimum Viable Tribe — минимальный жизнеспособный трайб, который в состоянии поставлять end-to-end ценность по продукту.
Этот конфликт приоритетов привел нас к тому, что мы от локальных скорингов, когда каждый трайб придумывал изощренный скоринг, как, например, степень инновационности доработки, вынуждены были прийти к модели, когда есть единые сквозные правила скоринга задач не только внутри розничной бизнес-линии между трайбами, но и между бизнес-линиями. Потому что часто бывает, когда КИБ приходит в розницу и говорит: «Нам нужно сделать счета эскроу. Эта задача дает на миллиард рублей больше, чем то, что вы сейчас делаете в ипотеке».
Нам нужно научиться приоритизировать задачи так, чтобы мы, как банк, управляли ресурсом наиболее эффективно. Но это противоречит базовому сетапу, когда трайб, бизнес-единицы, самостоятельная команда, P&L-ответственность и так далее.
Резюме
Где мы находимся сейчас? Это вызов и для нас, и, на мой взгляд, это вызов для тех компаний, которые по-крупному внедряют Agile, как найти баланс между самостоятельностью, ответственностью и P&L-ответственностью продуктов, трайбов, у которых может быть разная рентабельность, и тем, что нам нужно максимально эффективно использовать ограниченный бюджет разработки.
Пока промежуточный шаг, который мы сделали, — это шаг формирования общих принципов и правил приоритизации бэклога. Дальше логика простая. Три корзины:
- задачи, которые влияют на прибыль;
- на клиентский опыт;
- и на регуляторку, техдолг и межпроектные требования.
И, соответственно, внутри каждой корзины есть сквозные правила приоритизации, которые мы сейчас пытаемся распространить на все бизнес-линии.
Урок этого года, и, пожалуй, самый болезненный урок, — это вопрос аллокации ресурсов, бюджетов и P&L-ответственности. Мы окончательно для себя ответа на этот вопрос еще не нашли.
История вторая — год в сапогах
Я говорил про стратегический взгляд. В любой стратегии создания стоимости через M&A (Mergers and Acquisitions, слияние и поглощение компаний — прим. ред.) есть два принципиально разных пути, которые, на мой взгляд, очень сильно похожи на то, что мы с вами делаем в Enterprise Agile-трансформации:
- Первый путь называется Reinvent my business model — это путь, когда ты хочешь через покупку нового бизнеса (в нашем случае через Enterprise Agile-трансформацию) построить принципиально новую бизнес-модель, то есть стать принципиально другим.
- Второй путь называется Leverage my business model — это когда ты хочешь через покупку нового бизнеса (в нашем случае через Enterprise Agile-трансформацию) сделать свой бизнес чуть более эффективным.
На самом деле, эти два фундаментальных сценария принципиально важны.
Возвращаюсь к операционным метрикам, о которых я говорил в самом начале. Если мы идем по-крупному и рискуем, то тогда у нас Big-bang и куча изменений сразу: мы выгоняем старую команду, принимаем новую команду, которая уже давно умеет работать с продуктовой технологией, знает и Discovery, и Delivery, и все продуктовые метрики, и все остальное. Либо мы пытаемся развивать собственную экспертизу, собственную компетенцию, делаем школу продактов и так далее. Этот выбор, на самом деле, определяется стратегическим контекстом компании, амбициями и готовностью инвестировать и рисковать.
Мы пошли по пути Leverage my business model, то есть не принципиально быстрых изменений, итеративных, learning by doing. Но я знаю примеры, когда компании идут гораздо более агрессивно в силу своего организационного контекста и тех ограничений, которые перед ними выставляют акционеры и правление.
Зрелость имеет значение — для запуска трайба необходимо соответствие пяти критериям
Мы для себя разработали систему из пяти критериев и сами же ее поломали, и сами же на грабли встали. Самое принципиальное в этих пяти критериях то, как хорошо запускаются кросс-функциональные команды, когда у тебя есть зрелая архитектура, IT-инфраструктура и когда есть достаточно зрелая продуктовая гигиена. Т.е. Agile хорошо работает, когда у тебя уже есть зрелая технологическая и продуктовая инфраструктура, и тебе нужно быстро протестировать продуктовую гипотезу в условиях неопределенности.
Почему я говорю, что мы наступили на грабли? Потому что мы сами для себя определили правила, но при этом у нас есть ограничение, о котором я рассказывал в начале. Когда, с одной стороны, есть постулат об архитектурной и продуктовой зрелости, а с другой стороны, мы компанию сломаем, если будем растягивать все на год. Этот компромисс автоматически порождает проблемы при Agile-трансформации.
Когда мы создали трайбы, мы сделали вид, что у нас все вопросы про продуктовую, инженерную зрелость и гигиену решены, а на самом деле оказалось, что не решено 40%. Это означает, что мы по-прежнему тратим ресурсы команд, которые собраны вокруг клиентского пути, на развитие платформ и хардкор продуктовых настроек, которые и так понятны без Agile. В результате история про то, что нам нужно строить Discovery-процесс, быстро тестировать гипотезы, превращается в фейк. Потому что мы не тестируем гипотезы, а занимаемся тем, что добиваем технический долг и пытаемся довести до ума инженерную инфраструктуру.
Еще один тезис, который мы переживаем особенно остро в цикле планирования следующего года — трайб очень дорого стоит. Вот здесь пример нашего Minimum Viable Tribe. Главная боль при дизайне и запуске любого трайба, с которым мы сталкиваемся, в том, что у нас нет возможности внутри трайба сделать каждую команду полностью кросс-функциональной. То есть чтобы у нее был и Discovery, и Delivery на всех системах, которые этой команде нужны для того, чтобы нести ответственность end-to-end. Единственное, чего мы могли добиться, это когда в трайбе есть Discovery-команды, и есть у них Delivery-ресурсы. И получается, дизайн трайба строится таким образом, чтобы он 80% задач решал внутри, без внешних зависимостей. Это нам удалось сделать при создании Minimum Viable Tribe.
Трайб стоит очень дорого
«Открытие» выходит на IPO, нам нужно обеспечить хороший CIR и целевую отдачу на капитал.. А это значить — агрессивно сокращать расходы. Мы понимаем, что сокращение одной команды в трайбе ломает трайб целиком, кросс-функциональная логика разваливается. Трайб — это где-то 200 миллионов рублей (тут только прямые затраты в сетапе Minimum Viable Tribe). Обычно в компании в среднем на круг требуется еще 200 миллионов рублей аллокации, это уже 400 миллионов рублей. При CIR 40-50% нужно, чтобы трайб приносил миллиард прибыли в год для того, чтобы окупать свои расходы в формате Minimum Viable Tribe. Если хоть одну команду убираешь, она становится нежизнеспособной. Мы для себя еще не нащупали, как в этой ситуации правильно распорядиться ограниченным ресурсом. Если компания растет, готова инвестировать, на каком-то горизонте это нормально работает. Когда вам нужно ограничить затраты, дорогая модель начинает сбоить и рушиться. Об этом тоже нужно думать и помнить, когда проводим трансформацию.
Понятно, что прибыль лишь косвенно доказывает эффективность внедрения. Главное, чего мы должны добиться, — это сокращение Time-To-Market (время выхода на рынок — прим. ред.) и ускорение команд, рост Velocity (показатель скорости Scrum-команд в относительных единицах оценки работ — прим. ред.), рост Capacity (вместимость, в случае Scrum-команд совпадает с показателем скорости — прим. ред.). Половина команд растет с точки зрения скорости, у другой половины скорость снижается. У половины команд Time-To-Market снижается, у половины увеличивается. Но мы почувствовали, что гибкое управление ресурсами и их перераспределение между трайбами снижает производительность команд. И это то, к чему нужно быть готовым.
История третья — как на этом заработать
Мы видим, что в банковском бизнесе компании, которые быстрее проходят цифровую трансформацию, Enterprise Agile-трансформацию, стоят дороже. Мы сейчас выходим на рынок, и для нас это яркий индикатор с точки зрения стоимости и количества капиталов, которые за тебя дают. Если бизнес цифровизирован, за него платят больше, у него отдача на капитал существенно выше, чем у тех, кто не цифровизирован. Это мировая статистика. Если бизнес цифровизирован, даже в России, у него ROE (Return on Equity, рентабельность собственного капитала — прим. ред.) существенно выше. Именно поэтому мы, несмотря на все те сложности, про которые я вам рассказал, все-таки в эту историю инвестируем и в эту историю дальше идем. Успех цифровой трансформации — это случайная величина, но мы верим в лучшее.
Видео и слайды
