Марат Садеков, руководитель направления проектов Business Continuity Management, X5 Retail Group
Видели ли вы проекты, для которых недостаточно одного менеджера? Надо назначить еще одного… Или лучше двух… В помощь первому — проект ведь "очень большой". Финал у таких историй предсказуем, так как менеджер у проекта должен быть один — для меня это аксиома. Как обеспечить разумную загрузку менеджера проекта и не создать очередную "лебедь-рако-щуку"? Как применить индивидуальный подход к группам специалистов, участвующих в решении масштабной многоплановой активности (свои сотрудники и подрядчики, консультанты SAP и тестировщики, спецы по инфраструктуре и «портальщики»)? Как увязать задачи, подлежащие четкому планированию, и исследовательские задачи, требующие гибкого подхода? Как увязать расписание этих задач с операционной деятельностью компании? Попробуйте реализовать управление через программу проектов.
С конца нулевых, чуть более 10 лет, компания X5 Retail Group (X5) эксплуатировала дата-центры как на территории России, так и за рубежом. Большое количество критичных систем было размещено в дата-центре IBM в Швейцарии. С 2015 г. в связи с новыми требованиями законодательства РФ, а также изменениями экономической ситуации и стремлением минимизировать валютные риски компания начала сокращать размещение информационных систем в европейском ЦОД.
В 2018 г. в X5 было принято решение о переносе оставшейся части информационных систем из европейского ЦОД (ЕЦОД), в ЦОД на территории РФ (РосЦОД). Тот факт, что в 2019 г. заканчивался очередной цикл эксплуатации большей части ИТ-инфраструктуры систем в ЕЦОД (необходимость увеличения производительности в связи с органическим ростом числа магазинов торговых сетей и истечение сроков вендорской поддержки), жестко ограничивал сроки миграции I кварталом 2020 г.
Подготовка к масштабной миграции
На момент, когда принималось решение о миграции, ландшафт систем, размещенных в дата-центре в Женеве, примерно соответствовал представленному на рис. 1.
Ключевой системой являлась SAP ERP — одна из крупнейших инсталляций в мире. Помимо SAP ERP, в ЕЦОД функционировали системы, автоматизирующие процессы пополнения и товародвижения в магазинах, интеграционная шина и ряд других критичных для бизнеса систем (High Load). Требовалось исключить риски сбоев в работе этих систем как во время, так и после их миграции, поскольку от их стабильной работы зависит то, как "бьются" чеки в 17 тыс. магазинов Х5 по всей стране.
Перед миграцией систем в РосЦОД был установлен, протестирован и введен в эксплуатацию комплекс технических средств (18 стоек), создающих запас производительности до 2022 г. включительно. Для того чтобы обеспечить надежный процесс репликации между площадками (ЕЦОД и РосЦОД), были организованы два дополнительных временных канала связи. Были также разработаны и одобрены документы, описывающие порядок миграции систем, согласованные плановые и резервные окна DT, порядок тестирования и сроки стабилизации после миграции. Параллельно с этим решались задачи создания и ввода в эксплуатацию геораспределенного кластера интеграционной шины (ГРК SAP PO) на территории РФ, обновления версии интеграционной шины, переключения интеграционных потоков из ЕЦОД на ГРК SAP PO в РосЦОД, подготовки к выводу из эксплуатации, утилизации и продаже оборудования в ЕЦОД по мере его высвобождения.
В то же время технические владельцы информационных систем работали над сокращением требований к инфраструктурным мощностям, актуализацией описаний интеграционных потоков и сокращением списка интеграций (по итогам миграции до 300 интеграционных потоков были выведены из эксплуатации как потерявшие актуальность).
Выбор подхода к управлению
Традиционным для нас, как и для большинства ИТ-служб в РФ, подходом к решению перечисленных выше задач было создание временной организационной структуры в виде одного крупного проекта. Чтобы избежать классических проблем, свойственных всем "мегапроектам", я предложил руководству реализовать управление через формирование программы проектов. По аналогии с SOA (англ. Service-Oriented Architecture) — модульный подход к реализации изменений в компании даёт определённую гибкость в управлении. Каждый из проектов программы решал одну из крупных задач либо минимизировал риски, обусловленные реализацией "головного" проекта, который, в свою очередь, отвечал за достижение главной цели — миграцию информационных систем на территорию РФ.
Для каждого проекта были четко определены свои цели и содержание, свой устав, свой менеджер проекта и своя команда. Если проект предполагалось выполнять собственными силами, а формирование однозначного ТЗ представлялось маловозможным, мы применяли Agile-подходы к управлению таким проектом. В других ситуациях — четкое ТЗ для подрядчика и планирование по Waterfall (Agile - гибкая, Waterfall - каскадная модели разработки проекта -- прим. редактора). Исходя из согласованного подхода к управлению, выбирали менеджера на данный конкретный проект, поскольку талант планировать и страсть работать по Agile редко встречаются в одном человеке.
Устав программы проектов
На уровне устава программы проекты объединялись по тому же принципу, как рамочный договор объединяет несколько заказов общими условиями. Часть ключевых менеджеров и технических экспертов формировали команду программы и обеспечивали слаженность технических и управленческих решений для проектов, входящих в программу.
Команда программы могла оперативно перераспределить ресурсы от одного проекта другому. Менеджер головного проекта одновременно являлся руководителем программы.
Устав программы проектов ("рамочный договор") требовал жесткой фиксации скоупа, бюджета и сроков в уставе отдельно взятого проекта, причем скоуп, сроки и бюджет самой программы могли быть оперативно скорректированы решением управляющего комитета программы. Принцип корректируемого скоупа позволил оперативно разработать и согласовать устав программы, не описывая мельчайшие детали проектов, время инициации которых еще не пришло.
Сроки реализации
В проектах программы одновременно работало от 120 до 200 (в зависимости от периода) специалистов компании и подрядных организаций. Общий срок жизни программы от ее инициации и до завершения последнего из проектов составил 18 месяцев (рис. 2), при том что миграция информационных систем была осуществлена всего за три месяца. Остальное время ушло на подготовку к переезду, опытную эксплуатацию КТС в РФ, высвобождение площадей ЕЦОД и подведение итогов программы.
7 ключевых эффектов от выбранного подхода
Реализованный нами подход позволил:
Синхронизировать проекты программы по целям, скоупу и срокам, примененным техническим решениям.
Распределить ответственность и нагрузку на менеджеров проектов.
Сократить суммарные издержки на реализацию проектов.
Исключить инциденты прерывания ИТ-сервисов, обусловленные миграцией систем.
Реализовать гибкие методологии в одних проектах и старый добрый "вотерфолл" в других.
Обеспечить синхронизацию проектов программы и задач из операционной деятельности ИТ.
Создать лучшую управляемость со стороны заказчиков и владельцев, объединенных в один управляющий комитет программы проектов.
Итогом реализации программы стало сокращение расходов на инфраструктуру SAP-систем, предсказуемый рублевый бюджет на услуги Collocation и катастрофоустойчивое решение для интеграционной шины, связывающей несколько сотен информационных систем, эксплуатируемых в Х5.
Надеюсь, управление программами проектов и далее будет практиковаться для достижения масштабных целей в Х5, а также поможет вам в решении управленческих задач. Попробуйте «микросервисную архитектуру» в проектном управлении!