Как мы замиксовали Agile для внедрения новой ERP-платформы

Привет, Хабр! Мы – Антон Кузнецов и Ксения Краснова, Agile coach и руководитель Программы проектов в компании «Северсталь». Расскажем, как мы применили гибкие подходы для внедрения новой ERP-системы S/4HANA

Начнем сначала: что значит ERP для «Северстали»?

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

В «Северстали» ERP – это «сердце» компании. В ней работают 20 тысяч пользователей, и без ERP трудно представить работу такой огромной металлургической корпорации.  «Северсталь» – это не просто заводы, рабочие и тяжелый физический труд. Мы повышаем эффективность работы за счет цифровых технологий, активно применяем Data Science, роботизируем и цифровизируем процессы. «Северсталь» уже давно не просто металлургическая, а цифровая компания. И вот, мы плавно подошли к следующему вопросу:

Зачем мы вообще начали менять текущую ERP на S/4HANA?

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

Причина №1: Сейчас компания использует систему SAP ECC 6.0. Развитие этой системы уже остановлено, а поддержка SAP ECC будет полностью прекращена с 2027 года. Тогда почему мы поставили себе срок перехода на S/4HANA в 2021 году, а не ближе к 2027? Чем раньше – тем лучше, не только из-за того, что к 2027 мы точно успеем отладить и стабилизировать систему, но и потому что специалисты S/4HANA находятся в дефиците. Чем больше затягивается переход, тем ожесточеннее борьба за кадры. К тому же, другие системы, стоящие вокруг ERP, уже развиваются на базе S/4HANA. Оставаться и дальше на ECC 6.0 – значит постоянно тратить время на костыли и интеграцию.   

Еще один важный момент, связанный с текущей системой: доработки, которые нужны для реализации новой бизнес-стратегии «Северстали», скорее всего, сломают действующую систему или, как минимум, сильно её замедлят.

Причина №2: «Быстрее! Выше! Сильнее!» – это про «Северсталь». Мы хотим снизить количество кастомного (нестандартного) кода и улучшить time-to-market (время от начала разработки до внедрения продукта). К 2022 году мы планируем снизить time-to-market в 2-3 раза по отношению к 2019-му.

По этим причинам в 2019 году мы начали работу над проектом по замене текущей системы на систему SAP S/4HANA. Внедрение S/4HANA – это не просто внедрение новой ИТ-системы. Это глобальное изменение важных процессов компании. Если вспомнить о том, что ERP – это сердце компании, речь идёт ни много ни мало о трансплантации сердца на ходу.

Почему нам не подходит Waterfall?

Ощутили всю серьезность ситуации и степень ответственности? Представили масштабы проекта? А теперь, еще пара вводных для полной картины:

1.    Изменения в процессах и структуре компании непрерывные и динамичные;

2.    Платформа монолитная: меняя что-то в одном месте, легко можно сломать что-нибудь в другом;

3.    Развитие текущей ERP нельзя останавливать (мы заморозим работу всей компании), но при этом необходимо переосмыслить множество процессов и «с нуля» создать новую систему.

Обычно, когда говоришь о модернизации такого большого и глубоко интегрированного механизма, то представляешь процесс в виде Waterfall: прежде чем начать разработку, надо всё спроектировать, учесть все зависимости, попытаться предусмотреть риски и написать документ, который по объему будет не меньше, чем «Война и мир».

В общем, фаза анализа по составлению документации и требований в классическом подходе на наших объемах заняла бы 6-8 месяцев. Пока бы мы тратили столько времени на составление плана и детализацию ожиданий от S/4HANA, все процессы компании, которая динамично развивается, могли измениться. В конечном итоге, наш поезд никуда бы не поехал, так как направление общего движения за это время изменилось, рельсы нужно перекладывать. Получается замкнутый круг: мы работаем и выпускаем документацию, к этому моменту она устаревает, мы пишем новую, и так до бесконечности.

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

Поэтому решили из всего многообразия известных подходов выбрать только то, что подходит именно нам. За основу взяли SAFe​, немного Nexus, ну и как же без любимого SCRUM.

Как мы в итоге выстроили работу проекта?

Следует упомянуть, что проект состоит из трех фаз:

1.    Концептуальное проектирование;

2.    Разработка и тестирование;

3.    Внедрение и завершение работ.

Сейчас мы только перешли к третьей фазе, а в рамках этой статьи подробнее поговорим именно про фазу «Разработка и тестирование». Концептуальное проектирование осуществлялось по классической модели Waterfall, так как дизайн методологии разрабатывался в рамках этой фазы. А вот разработку и тестирование мы полностью проходили уже с использованием нашего Agile-mix.

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

В конце каждого инкремента полученные результаты проделанной работы мы демонстрируем заказчикам проекта – владельцам сквозных процессов. Еще не запутались? Ниже на схеме отражены все фазы.

А сейчас давайте глубже окунемся во все тонкости организации нашей внутрикомандной работы.

Команды: разделять и особо не властвовать

Принцип формирования и структура команд проекта S/4HANA строится следующим образом:

·       10 команд функционального внедрения, где каждая команда отвечает за определенное функциональное направление (например, ремонты, продажи и т.д.);

·       3 платформенные: команда миграции данных, команда интеграции со смежными системами и команда сопровождающих сервисов.

Все они автономны с точки зрения ресурсов и компетенций и выстроены таким образом, чтобы поставлять функциональный объем направления от начала и до конца (end-to-end). Немного о принципе формирования функциональных команд: мы опирались не только на модули системы, но и на организационную структуру предприятия. Таким образом, функциональные команды сформированы исходя из бизнес-процессов компании.

Мы не придумывали экзотических ролей.

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

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

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

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

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

Чем мы руководствовались, когда формировали команды?

Здесь работают три основных принципа: ставка на внутренние компетенции, самоформирование и функциональное подчинение.

Ставка на внутренние компетенции

Мы приняли принципиальное решение максимально подключать к проекту внутренних сотрудников, а не приглашенных экспертов. Они не только лучше знают «внутреннюю кухню» компании, но среди них есть те, кто участвовал в прошлом внедрении системы. Эти люди уже «нюхнули пороха» с предыдущим внедрением ERP и, преисполненные опытом, могут спрогнозировать ошибки. Еще нам важно, чтобы все компетенции и знания, полученные в ходе реализации проекта, оставались и в дальнейшем внутри компании.

Самоформирование

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

Функциональное подчинение

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

Церемонии, ритуалы и немного магии

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

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

Нельзя сказать, что новую методологию все приняли с восторгом. Кому-то она оказалась близка, и они с готовностью включились. Кто-то не понимал эти мероприятия, и для него всё казалось напрасной тратой времени. Мы продолжали работать над осознанностью...

Но после первого же инкремента мы получили ответ от команд: «Давайте так работать дальше!» Многие отмечали, что прозрачность процессов увеличилась, скорость выполнения задач возросла, участники стали сближаться и становиться настоящей командой.

Важная часть нашей Agile-трансформации – регулярные встречи scrum-мастеров (scrum-of-scrums), на которых мы обсуждаем разные вопросы по улучшению процесса кросс-командного взаимодействия, не обязательно напрямую связанные с методологией. Например, почему бы не назначить один день в неделю, свободный от встреч на уровне программы (чтобы решить текущие задачи команды)?

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

В течение проекта мы постепенно добавляли все новые и новые практики. Например, для scrum-мастеров мы организовали agile-интервизии. Они помогают разобраться в проблемах, возникающих в командах. Каждый скрам-мастер формирует кейс и выносит его на общее обсуждение. Также scrum-мастер может обратиться к agile-коучу, вместе с ним разобрать проблему в команде и найти решение в формате супервизии.

Если говорить про систему регулярных встреч на уровне всего проекта, то она выглядит так:

●      стендапы, на которых каждая команда ежедневно выравнивается относительно своих планов;

●      ежедневный утренний NIT (Nexus Integration Team), где мы обсуждаем технические решения на уровне архитекторов команд, а также риски и блокираторы;

●      синхронизация владельцев продуктов (PO Synс), где владельцы продуктов сверяют свои задачи и сроки их реализации;

●      встреча scrum-мастеров (scrum-of-scrums), где scrum-мастера обсуждают текущие проблемы кросс-командного взаимодействия и синхронизируют подходы;

●      демонстрация результатов спринта (demo), где команды демонстрируют реализованные за спринт задачи;

●      ретроспектива, которая проводится как для всего проекта, так и для каждой команды в отдельности. На них обсуждают, что необходимо сделать, чтобы в дальнейшем быть более эффективными. Ретроспективы проводятся после каждого спринта и, отдельно, после каждого инкремента;

●      регулярные встречи по планированию спринта, на них команды определяют список задач для выполнения в начале каждого спринта;

●      кросс-командное выравнивание по планированию спринта, где представители команд рассказывают, как прошло командное планирование и возникли ли какие-либо сложности;

●      кросс-командное выравнивание по результатам спринта, задачей которого является обсуждение реализации целей спринта и прогресса по выполнению целей инкремента. Своего рода некое «ревью» по итогам трехнедельной итерации;

●      презентация интеграционного сценария, которая происходит в последнем спринте, в рамках которого мы интегрируем разработанные решения;

●      планирование инкремента (PI Planning), которое также происходит после последнего, четвертого спринта, и на котором мы в течение двух дней планируем задачи на следующий инкремент.

Жизнь вносит свои коррективы

Отдельным вызовом для нас (как и для многих других) стал карантин, который случился на старте проекта. Мы успели арендовать новый офис, чтобы все могли беспрепятственно общаться в духе Agile, провести первое PI-планирование, запустить первый инкремент. А дальше пришлось перестраиваться.

Внутрикомандные церемонии легко переехали в online, потому что некоторые участники изначально работали удаленно. А вот с масштабными мероприятиями, вроде PI Planning, оказалось сложнее. И мы взяли таймаут длиной в спринт (коллеги занимались техническим долгом и прочими полезными вещами), чтобы придумать, как обеспечить эффективную работу в online для нескольких сотен человек. В итоге мы разработали план действий с применением online-инструментов, с помощью которых успешно запланировали и завершили еще 5 инкрементов.

Так из чего же состоит наше PI-планирование?

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

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

Также в рамках планирования мы учитываем все риски и блокираторы, которые могут нам помешать успешно завершить инкремент. Риски и блокираторы программы учитываем в Excel-таблице — и тоже выводим на доску при планировании, а затем в течение всего инкремента мониторим на NIT:

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

Помимо Jira в процессе всего планирования мы используем и другие инструменты:

·       общение – Microsoft Teams;

·       проведение опросов – Mentimeter;

·       оценка задач – Voting Poker.

И теперь, даже после частичного снятия ограничений, мы все равно проводим PI Planning в online-формате.

Подведем итоги

С помощью всех вышеперечисленных инструментов и методологии, которую мы обсудили в статье, мы успешно прошли всю фазу «Разработка и тестирование». Выработанный нами Agile-mix позволил качественно следить за выполнением бэклога, оперативно реагировать на изменения и управлять командой численностью более 1900 человек, в распределенном режиме. К тому же, сейчас все встречи и взаимодействия в проекте проходят на 100% в онлайне: мы проверили на себе, что для эффективного выполнения задач не обязательно работать очно, и повысили продуктивность работы на 60% в удаленном формате.

На наш взгляд, всё получилось, потому что мы сфокусировались на вовлечении людей в изменения, создании среды для обучения и работе над осознанностью. И, конечно, ввели единые для всех правила игры.

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

Хабравчане, а у вас был опыт применения Agile на больших проектах? Поделитесь своим мнением и историями в комментариях!