Все статьи
Как перестать воевать и начать зарабатывать? Опыт KFC
Дата: 15.06.2022
История о том, почему KFC пришли к необходимости изменений и как в сжатые сроки добились результатов не только в бизнесе, но и в части изменения культуры.
Доклад на конференции Enterprise Agile Russia 29 ноября 2021 года.
У нас самый вкусный доклад однозначно, потому что у нас доклад про еду. Собственно, его тема – «Как перестать воевать и начать зарабатывать». Вы все ее, наверное, слышали и знаете. Поехали!
Сергей Грязев: Всем привет. Меня Сергей зовут. Я работаю в KFC, я СРО (Chief Product Officer), то есть делаю всякое в диджитале для нашей курочки.
Евгений Родионов: Меня зовут Женя и я лидер направления Enterprise Agility в Accenture Strategy Russia. Тут еще наши титулы написаны, которые мы, в принципе, на работе используем.
Вам будет полезен этот доклад, если:
- вы находитесь на старте масштабирования Agile, как и мы;
- вы не знаете, как подойти к внедрению крупных, масштабных изменений;
- хотите узнать, как можно нарезать поезда в HoReCa;
- вам интересно, как можно эффективно управлять вашими поездами. SAFe тут не полностью рассказывает, а мы расскажем полностью;
- также вы не знаете, как ценности и принципы SAFe могут помочь вам при внедрении.
Сергей Грязев: Кто не знает, что такое KFC? Классно, все знают. А кто не знает о том, что в KFC есть IT и вообще вся эта digital-история? Вот я тоже, на самом деле, руку поднял, потому что год назад еще я особо не знал.
На самом деле, в KFC есть не только курица, это очень большой операционный бизнес, там много завязано на цифровые продукты. Это гигантская компания, которая кластеризована на много-много хабов, 21 тысяча ресторанов в мире, 2 тысячи в хабе, в котором существуем мы, просто огромное количество клиентов, огромное количество операций, огромное количество рынков. Вы можете взять любое определение из нашей профессиональной тусовки, и назвать огромное число Х. Вот у нас огромное число всего.
Мы проходим процесс трансформации. Проходим по классической схеме больших компаний, когда у нас есть leadership-team, которая определяет стратегию компании, а дальше внутри много-много разных департаментов, каждый из которых отвечает за конкретную функцию. Например, операционную функцию, управление едой, жарка курочки и так далее, и так далее. Или, например, информационная функция. Вот смотрите, на слайде подсвечены как раз эти два департамента. Чуть позже мы расскажем, почему их, собственно, было два.
Сергей Грязев: На самом деле, так как мы корпорация довольно большая, у нас постоянно возникают разнородные проблемы, потому что разные функции отвечают за разные участки бизнеса. Соответственно, ключевые истории, где мы постоянно несем потери, — это истории, связанные с интеграциями, поставкой ценности в различных направлениях, в организованности и в планировании. На самом деле, везде: от стратегии до тактики. Если в каждую часть, в каждый участок производства мы погрузимся более детально, то увидим, что еще год назад мы довольно-таки конкретно огребали на каждом из них.
Евгений Родионов: Если постараться понять, где именно была пробита оборона, то сканируя со стороны всю эту историю, мы выделили самое главное, самое большое. Лидерами стали стратегическое планирование и бизнес-архитектура. Довольно стандартно на мой взгляд, да? Дальше идут сервис, дизайн и сборка — они, конечно, тоже страдают, но не настолько. Поэтому, глядя на эти радары, мы моментально сформировали фокус.
Сергей Грязев: О’кей. Я уже говорил, что у нас компания большая, и, соответственно, очень много разнородных задач. Так как организация существует функционально довольно давно, у нас был внутри IT-департамент, который обеспечивал IT-инфраструктуру компании, чтобы работали кассы, чтобы клиенты могли получать свои заказы и так далее.
Но так как корпорация у нас не только большая, но еще и умная, то она понимает свои проблемы и то, что IT-legacy все меньше позволяет нам развивать бизнес эффективно и все больше замедляет нас в этом прекрасном и в чем-то ужасном ковидном digital-мире. Поэтому, в какой-то момент было принято стратегическое решение сделать отдельный департамент и назвать его Digital. И этот отдельный IT-департамент, Digital-департамент, должен был создавать новую инфраструктуру с новыми цифровыми продуктами.
Если вы сейчас зайдете в наш ресторан, посмотрите на киоск, на наше приложение, на наш веб-сайт — то все это детище вот этого нового департамента. Но, естественно, так как это был отдельно стоящий кластер новых продуктов, которые разрабатывались изолированно, это приводило к чему? Конечно же, это приводило к проблемам в интеграциях, потому что часть решений сопровождается в одном департаменте, разрабатывается в другом, решение принимается в третьем. Все-все-все это наслаивалось друг на друга как снежный ком, и в итоге мы сейчас, в процессе трансформации, пытаемся этот клубок распутать.
Евгений Родионов: Абсолютно верно, классический закон Конвея. Чтобы начать сражаться с этой проблемой, мы предложили вот такую структуру – единый департамент. Довольно логично, не правда ли? Назвали его Tech & Data. Сверху он управляется CTDO, сложная аббревиатура расшифровывается как Chief Technology & Data Officer, и у него есть две дополнительные руки. Одна из них – это административная поддержка, которая позволяет решать административные вопросы, а вторая – это офис изменений, очень важный орган, который называют по-разному: офис трансформации, LACE, Agile PMO и так далее. Сначала обычно он появляется как маленький, затем – растет. Основная цель этого органа – помогать внедрять изменения в процессе трансформации.
Евгений Родионов: После того, как мы объединились, мы решили, что хорошо бы понять вообще, с кем мы воюем, куда стрелять, и что происходит, кто же наш настоящий враг. Вспоминаем цитату известного полководца: «Ваш величайший враг спрячется там, где вы будете меньше всего его искать». Собственно, где же он прячется? Мы начали копать, смотреть глубже и вспоминать, какая же наша психология? Прежде всего мы воспринимаем врага как какую-то внешнюю сущность, «это вот тот сотрудник, он виноват» или «вот этот процесс – неэффективный, в нем причина», или «это вообще до нас делали, и вот там проблема, если бы там не ошиблись, то все было бы хорошо». На самом деле, это не так. Наш настоящий враг находится внутри каждого из нас, он нам не дает меняться, и это собственно наши, так скажем, лживые ценности.
Я еще упомяну план боевых действий. По правде говоря, воевать без плана – глупая идея. Смотрим фактически на стандартную дорожную карту. Любая трансформация по большей части именно так и делается: смотрим, как мы будем ее делать, то есть проектируем дизайн, что-то запускаем, смотрим, к каким результатам это приведет, стабилизируем, масштабируем, и потом адаптируем, чтобы у нас это точно вжилось внутрь.
Вот мы сели в танк и поехали дальше, где встретили нашего первого врага.
Сергей Грязев: На самом деле, проблем у нас было, действительно, много, как Женя сказал. И основная, наверное, боль, которая была у всех, в том числе у меня, – это отсутствие прозрачности в точках интеграций. Так как я Chief Product Officer, я отвечаю за поставку ценности, то есть то, что у нас фактически доставлено на продуктив. Для меня непрозрачность – это штука, которая напрямую влияет на контролируемость изменений. Когда мы не знаем, как команды доставляют работу, потому что они не понимают процессов работы друг друга, у нас задача может быть реализована через две недели, через месяц, а может и «потом, когда-нибудь, когда будет время».
Все это проявлялось в каждой из команд. Собственно, у нас было очень мало независимых компонентов, и мы сильно страдали на интеграциях. Непрозрачность – это была наша ключевая боль, которая приводила к неконтролируемости. А что это за процесс, что за фреймворк, который невозможно контролировать? Это прямой сигнал к тому, что текущие подходы не работают, и нам нужно что-то новое.
Евгений Родионов: Точно. Очень важно понимать, что обычно SAFe говорит нам: «Выделите один поезд, запустите один поезд». Но можно и по-другому. Это рубрика «вредные советы». Мы сначала запустили всю компанию, сделали один большой PIP (прим.ред. — PI Planning). Было больно? Да. Было ли это похоже на PIP? Не особо. Помогло ли это? Да, помогло, это послужило таким мощным пинком, который неожиданно врывается в организацию и говорит: «Таймер пошел, назад нельзя», и все такие: «У-у-у, это уже первый PIP, надо что-то делать». Собственно, результаты инкремента вы видите на слайде.
Сергей Грязев: Да, на самом деле, я как раз один из людей, который посмотрел на формирование PI с начала, с инициации, и принял полностью участие во всем квартале, и потом посмотрел по итогу. И я скажу, что у меня скепсис по поводу всей этой истории уменьшался постепенно, когда шло само планирование. Поначалу мы что-то с кем-то обсудили, что-то с кем-то синхронизовали, ударили по рукам, посмотрели, где мы можем пересекаться на интеграциях, все задачки переставили. А потом, когда мы увидели, что людям понятен фреймворк и людям понятно, как следить за большим количеством изменений не обособленно, а всем вместе, когда появились… Точнее, ладно, они у нас еще не появились, они начали появляться, нормальные точки синхронизации, где, знаете, не как на утреннике в детском саду все приходит и говорят: «Я сегодня сделал вот это, завтра буду делать вот это», а когда люди начали именно обсуждать проблемы, мы поняли, что мы стали лучше доставлять ценность, банально. Мы до конца не знали ни lead time команд, не знали, где мы конкретно еще какие-то проблемы увидим. Но мы увидели, что точки синхронизации работают. И по итогам, на самом деле, мы большинство задач, что обещали, сделали, потому что, естественно, никто не совершенен, в том числе и этот процесс. Тут нужно вставить очень важную ремарку: у нас операционный бизнес, поэтому мы не из тех компаний, которые могут запланировать любой свой IT-инкремент впритык. Мы должны планировать 60-70%, потому что операционка и всякое другое случается. Сегодня мы живем нормально, а завтра QR-коды ввели, надо убегать делать другие задачи, и так далее.
Но в целом, если верхнеуровневыми мазками посмотреть, мы делали те вещи, о которых договорились, основываясь на стратегии компании, основываясь на нуждах нашего департамента, и сделали их достаточно хорошо.
Евгений Родионов: Да. Что добавить? Посмотрите, метрика Predictability – 92%. Нормально для первого PI, я считаю. В целом, очень даже неплохо. А то, что я говорил про офис трансформации, смотрите, в результате его работы появилось семь новых процессов, этот орган выступал драйвером, который ходил и всех заставлял что-то делать: «давайте, давайте, давайте, давайте», также мы провели семь образовательных тренингов. Хочу чуть-чуть добавить. Мы рассказывали бизнесу, что такое, например, архитектура, что такое управление проектами, рассказывали, как IT работает и что с этим делать, что такое, например, операционная модель или бюджетирование. Это было семь крупных тренингов на разные темы.
Собственно, второй враг, которого мы встретили, — это расфокусировка.
Евгений Родионов: Резонно, когда у тебя один суперогромный бэклог на всю компанию, работать очень сложно. Надо, наверное, все-таки идти к value streams и всей этой истории. Проведя Value Stream Workshop мы такие, раз, и нарисовали классные поезда вот таким образом. Смотрите, запоминайте, можно копировать.
Евгений Родионов: Guest Experience – все, что связано с опытом гостей. Понятный value stream, в него встроена операционная история про рестораны, про то, как курочка готовится, упаковывается и прочее. У нас есть отдельный поезд для развития технологической истории, потому что, как говорил Сергей, мы все-таки технологичные ребята, у нас много чего нужно поделать еще и для себя. И есть отдельный поезд — Backoffice Drivers. Там много всего нужно делать: Finance, HR, Supply Chain.
Евгений Родионов: Вот доска отображающая статус этих поездов, Guest Experience сейчас едет первый PI, страдает, но не сдается. T&D Growth на этапе подготовки – это наш технологический поезд. Operations Excellence в анализе, и в бэклоге у нас Backoffice Drivers, но мы и до него дойдем.
Сергей Грязев: Тут еще нужно ремарочку сделать. Женя так говорит, что создается впечатление, что сейчас такая success story рассказывается. Это не так, далеко не так, на самом деле. Все, что мы сейчас проходим, это, на самом деле, болью, какими-то проблемами решается, и мы находимся только на стадии, когда понимаем, что из этого всего хотя бы ценность есть. Мы понимаем, что мы пошли в трансформацию не зря. И вещь, о которой мы будем дальше рассказывать, – несогласованность. И это, на самом деле, основной бич больших компаний, которые работают по разным моделям, с разными департаментами, с разными KPI. Когда, условно говоря, IT-департамент запланировал одно, потом прибегает другой департамент, говорит: «Слушай, а у нас тут другая задача, это наши KPI. Давайте согласуем их, давайте вы свое подвинете и сделаете наше». На самом деле, классика. Но именно эта классика мешает нам работать, и именно отсутствие синхронизации и неправильный подход к планированию больших, крупных, особенно крупных кусков, которые мы собираемся делать на уровне всей компании – это то, что нам до сих пор мешает жить.
Евгений Родионов: Это точно. Итак, мы отправляемся вместе с этой прекрасной курицей к победе, и смотрим, как мы решаем эти проблемы. Здесь нарисована модель управления поездом: организационные форумы, управленческие, и прочее. Все в основном знают, что происходит на уровне команд, и все понимают стандартные форумы, которые трактует SAFe: PO Sync, Scrum of Scrums, System Demo. Все все это знают. Что нам не хватило, и что мы добавили сюда?
Евгений Родионов: Почему-то в SAFe на уровне Essential никто не говорит об архитектурном комитете? Поэтому у нас у каждого поезда случился архитектурный комитет. И он, конечно же, связан с Enterprise архитектурным комитетом. Это первый блок, выделенный красным.
Второй выделенный красным блок – это ART Committee. Что это такое? В SAFe есть PO Sync, Scrum of Scrums или ART Sync. При этом во главе у поезда стоят три человека: Product Management (самый главный product), RTE (самый главный скрам-мастер) и архитектор. Но нет площадки для их взаимодействия. Непонятно, как эта трехглавая гидра должна управляться. Мы решили, что у нас появляется специальная регламентированная площадка для их взаимодействия. Она называется ART Committee. Ее задачи очень простые. Первое — нужно разбирать то, что приходит в бэклог, новые discovery-задачи. Второе – нужно понимать, что это за задачи вообще, как их реализовывать, каким поездом и почему их стоит делать. Затем требуется приоритизировать бэклог программы, постоянно прорабатывать элементы в нем. Нужно контролировать, как происходят исследования и проработка задач, готова ли задача перейти в Delivery и так далее. На ART-комитете решаются организационные вопросы по формированию отчетности руководству. Именно отчетности, с точки зрения различных метрик и прочего. Мы не взваливаем все эти задачи на одного RTE.
Топология нашего бэклога задач. Стандартная топология, все ее знают. Но, например, в чем у нас здесь отличие, и что мы делаем немножко не так. И это пока что успешно работает. Хоть мы и находимся на уровне программы, запускаем поезда, но мы уже частично заходим на уровень портфеля и пытаемся выстраивать бизнес-эпики, enabler-эпики и работать с этим подходом в долгосрок, чтобы мы понимали на верхнем уровне, какие у нас IT-активы, как они живут, как они двигаются, на каком они этапе. Это работает далеко не для всех задач и активов, но мы идем туда, даже не успев закончить с программой.
Евгений Родионов: Мы выделили так называемую роль владельца эпика и владельца портфеля. По сути, владелец эпика – это драйвер эпика, на нем как бы основная инициатива, а владелец портфеля – это product owner портфеля.
Если говорить про уровень продукта, тут есть выделенные серым кубики, они очень спорные. Это все можно обсуждать очень долго, но мы решили работать так. Так как мы планируемся в российских реалиях на квартал, а на квартал детально планироваться, на мой взгляд, довольно тяжело. И надо понимать, что планируются у нас не только поезда продуктовой команды, но еще и классические проекты в остальной части организации. Используя небольшие истории на итерацию запланироваться очень тяжело. Разложить на квартал 50 историй одной командой – звучит как неподъемная задача. Поэтому мы решили оставить продуктовые эпики — это конечный, законченный, агрегированный инкремент в результате работы. Для проектов — это этапы; для продуктов — это некие крупные куски, чтобы людям было проще адаптироваться к такой детальной нарезке задач. Если мы сможем в дальнейшем от этого отказаться, мы откажемся.
Евгений Родионов: На плане боевых действий, если мы посмотрим на него еще раз, наша курица проехала первые два этапа и приближается к масштабированию. Наверное, она где-то в середине между ними. Так как же перестать воевать и начать зарабатывать? Удивительно простой ответ. Нам стоит измениться, сразившись с самим собой, с внутренним нашим противоречием и ценностями. Что вам в этом поможет? Опирайтесь, прежде всего, в своей борьбе на ценности SAFe. Например, следуем ценности Transparency – и она побеждает непрозрачность. Следуем Program Execution – и мы собираемся в поезда, в единые программы и работаем с расфокусировкой. Принимая ценность Alignment, которая работает и снизу вверх, и сверху вниз, мы работаем с несогласованностью действий. При этом все это надо щедро сдабривать, ценностью Built-in-Quality, потому что, как говорят: «You can’t scale crappy code», то есть замасштабировав плохой код, ты умышленно стреляешь себе в ногу.
Мы в рамках этой презентации рассказываем в основном про процессы, про управление и прочее, но нужно понимать, что параллельно всему этому идет огромная работа с архитектурой, с правилами разработки, с ресурсными пулами, с поддержкой и многим другим. То есть здесь вы видите только вершину айсберга. Рассказывать про технические изменения, мне кажется, не является темой этой конференции. Поэтому просто хочу сказать – не забывайте про Built-in-Quality. Без нее вам будет сложно победить.
Сергей Грязев: Я хотел бы еще добавить, что при внедрении этих изменений, естественно, вы будете встречать сопротивление. Я сам, на самом деле, когда мы внедряли полностью этот процесс, изначально всегда проверял на прочность принимаемые решения. Ключевой момент – то, что людям нужно пояснить, почему мы это делаем. Не потому, что у нас есть готовый фреймворк, а именно пояснить, почему каждый из этих этапов нужно внедрять или нужно попробовать внедрить.
Ребята на старте первого инкремента не навязали нам какой-то фреймворк, сказав: «Будем работать вот так». Нет, это было не так. Они рассказывали, из чего состоят ритуалы, для чего они нужны, и какую конкретную проблему они будут у нас решать. Не потому, что так заведено у нас в компании, а потому что процессы компаний 1, 2, 3, обоснованы проблемами компаний 1, 2, 3. Они рассказывали, как эти ритуалы помогут нашей компании перебороть наши проблемы. И, естественно, все были готовы к неприятию новых процессов, потому что люди никогда не любят меняться, это очевидный факт, конечно же. Но, только меняясь, у вас что-то получается.
Видео и слайды
