Хочу с Вами поделиться опытом Северстали по внедрению новой ERP платформы. С разрешения авторов (ссылочки на их профиль и на оригинал статьи) и выкладываю их реальный опыт здесь.
Содержание:
Привет, Хабр! Мы – Антон Кузнецов и Ксения Краснова, Agile coach и руководитель Программы проектов в компании «Северсталь». Расскажем, как мы применили гибкие подходы для внедрения новой ERP-системы S/4HANA
ERP – большая и сложная система, в которой учитываются производственные операции, ресурсы, финансы и активы компании. Она позволяет автоматизировать работу большого предприятия и сделать любой процесс (от документооборота до продажи нескольких сотен тонн металла) проще, быстрее и удобнее.
В «Северстали» ERP – это «сердце» компании. В ней работают 20 тысяч пользователей, и без ERP трудно представить работу такой огромной металлургической корпорации. «Северсталь» – это не просто заводы, рабочие и тяжелый физический труд. Мы повышаем эффективность работы за счет цифровых технологий, активно применяем Data Science, роботизируем и цифровизируем процессы. «Северсталь» уже давно не просто металлургическая, а цифровая компания. И вот, мы плавно подошли к следующему вопросу:
Компания динамично развивается и использует новые технологии. И понятно, зачем: это позволит автоматизировать все, что можно автоматизировать, сократить влияние человеческого фактора, увеличить скорость работы производства и, как следствие, повысить удовлетворенность клиентов, а вслед за ней и прибыль.
Причина №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 – это сердце компании, речь идёт ни много ни мало о трансплантации сердца на ходу.
Ощутили всю серьезность ситуации и степень ответственности? Представили масштабы проекта? А теперь, еще пара вводных для полной картины:
Изменения в процессах и структуре компании непрерывные и динамичные;
Платформа монолитная: меняя что-то в одном месте, легко можно сломать что-нибудь в другом;
Развитие текущей ERP нельзя останавливать (мы заморозим работу всей компании), но при этом необходимо переосмыслить множество процессов и «с нуля» создать новую систему.
Обычно, когда говоришь о модернизации такого большого и глубоко интегрированного механизма, то представляешь процесс в виде Waterfall: прежде чем начать разработку, надо всё спроектировать, учесть все зависимости, попытаться предусмотреть риски и написать документ, который по объему будет не меньше, чем «Война и мир».
В общем, фаза анализа по составлению документации и требований в классическом подходе на наших объемах заняла бы 6-8 месяцев. Пока бы мы тратили столько времени на составление плана и детализацию ожиданий от S/4HANA, все процессы компании, которая динамично развивается, могли измениться. В конечном итоге, наш поезд никуда бы не поехал, так как направление общего движения за это время изменилось, рельсы нужно перекладывать. Получается замкнутый круг: мы работаем и выпускаем документацию, к этому моменту она устаревает, мы пишем новую, и так до бесконечности.
Перед нами встала задача: как сделать так, чтобы ничего не потерять и выпустить продукт, который удовлетворит конечного пользователя, и при этом учесть постоянное развитие и изменения в процессах? Посмотрели чужой опыт, запросили у консультантов методики и варианты, но так и не нашли ответа на вопрос, чье кунг-фу сильнее.
Поэтому решили из всего многообразия известных подходов выбрать только то, что подходит именно нам. За основу взяли SAFe, немного Nexus, ну и как же без любимого SCRUM.
Следует упомянуть, что проект состоит из трех фаз:
Концептуальное проектирование;
Разработка и тестирование;
Внедрение и завершение работ.
Сейчас мы только перешли к третьей фазе, а в рамках этой статьи подробнее поговорим именно про фазу «Разработка и тестирование». Концептуальное проектирование осуществлялось по классической модели 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 инкрементов.
В классическом планировании все задачи и зависимости между командами фиксируют на доске со стикерами и нитками. Мы заменили ее на цифровую доску Jira. Так мы видим планы с разбивкой по спринтам как в разрезе одной команды, так и всей программы в целом, с учетом межкомандных зависимостей. Зависимости – это взаимосвязанные между собой задачи, в которых одна задача не может быть выполнена, если не выполнена другая.
Все зависимости имеют цветовую индикацию. Красная линия связи – повод поменять планы: выход задачи заблокирован другой задачей, которая планируется к выходу позже. Чаще всего диаграмма пестрит желтыми линиями — они означают, что зависимые задачи завершаются в одном спринте. По таким задачам надо постоянно синхронизироваться, чтобы убедиться, что в планах зависимых команд ничего не поменялось. Зеленая линия говорит о том, что блокирующая задача выполняется раньше заблокированной.
Также в рамках планирования мы учитываем все риски и блокираторы, которые могут нам помешать успешно завершить инкремент. Риски и блокираторы программы учитываем в Excel-таблице — и тоже выводим на доску при планировании, а затем в течение всего инкремента мониторим на NIT:
Еще во время планирования мы сразу обсуждаем сценарий интеграционного тестирования, чтобы убедиться, что вся функциональность, участвующая в сценарии, запланирована в инкремент.
Помимо Jira в процессе всего планирования мы используем и другие инструменты:
· общение – Microsoft Teams;
· проведение опросов – Mentimeter;
· оценка задач – Voting Poker.
И теперь, даже после частичного снятия ограничений, мы все равно проводим PI Planning в online-формате.
С помощью всех вышеперечисленных инструментов и методологии, которую мы обсудили в статье, мы успешно прошли всю фазу «Разработка и тестирование». Выработанный нами Agile-mix позволил качественно следить за выполнением бэклога, оперативно реагировать на изменения и управлять командой численностью более 1900 человек, в распределенном режиме. К тому же, сейчас все встречи и взаимодействия в проекте проходят на 100% в онлайне: мы проверили на себе, что для эффективного выполнения задач не обязательно работать очно, и повысили продуктивность работы на 60% в удаленном формате.
На наш взгляд, всё получилось, потому что мы сфокусировались на вовлечении людей в изменения, создании среды для обучения и работе над осознанностью. И, конечно, ввели единые для всех правила игры.
Сейчас мы разработали свою методологию с использованием Agile-практик и для финальной фазы проекта: «Внедрение и завершение работ». После того, как мы попробовали работать по этой методологии, уже не хочется возвращаться к более традиционным практикам.
Comments