Можно ли внедрять ERP по Agile?

Гибкость - там, где она ускоряет. Жёсткость - там, где ошибка слишком дорога.

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

Сразу зафиксирую предмет разговора. Под трансформационным внедрением ERP я понимаю внедрение core-ERP, при котором одновременно происходит перестройка сквозных бизнес-процессов, операционной модели, организационных ролей и моделей данных, а новая система замещает значительную часть legacy систем. Типичный масштаб таких программ - крупные холдинги от 10 000 сотрудников, хотя дело не в численности как таковой.

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

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

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

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

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

Что удалось найти в открытых источниках

Консалтинг. McKinsey в статье «Agile in enterprise resource planning: A myth no more» (2019) заявляет: несовместимость Agile и ERP является мифом. Методологию нужно лишь адаптировать, и результаты будут измеримо лучше: в описанном ими опыте порядка минус 10% к стоимости программы, плюс 20% к её ценности, втрое больше работы в единицу времени.

Вендор. SAP позиционирует методологию Activate как сочетание best practices, направляемой конфигурации и agile-методов. Устройство самой методологии при этом последовательное: фазы Discover, Prepare, Explore, Realize, Deploy, Run и управление через quality gates. Уже на ранних этапах SAP требует определить стратегический периметр, роли, ответственность и governance, а в материалах о Business Innovation Framework гибким методологиям отводится роль механизма быстрой проверки инновационных сценариев, а не метода управления программой в целом.

Практик 1. Команда «Северстали» в известном кейсе на Хабре описывает свой Agile-mix (SAFe + Nexus + Scrum) на программе внедрения S/4HANA: 13 команд, более 1900 участников, трёхмесячные инкременты из четырёх трёхнедельных спринтов. При этом первая фаза программы, концептуальное проектирование, прямым текстом выполнялась по классическому Waterfall.

Практик 2. Juan Pablo Franco, руководитель трёх внедрений (S/4HANA, Oracle Fusion, Dynamics 365), свидетельствует: на просьбы клиентов вести проект по Agile сертифицированные партнёры SAP, Oracle и Microsoft «последовательно отвечали отказом», поскольку их методологии (Activate, OUM, Sure Step) ближе к каскаду. Agile он допускает в отдельных направлениях: интеграции, очистка и миграция данных, хранилища, кастомизации.

Наука. Исследование Gren, Wong и Kristoffersson (2019) охватывает 21 внедрение ERP в 20 компаниях. Важно понимать выборку: это не исследование эффективности Agile против Waterfall. Авторы сознательно изучали успешные проекты, находящиеся около границы между двумя подходами, и искали факторы, по которым выбор методологии можно предсказать заранее. Таких факторов почти не нашлось: по сложности, неопределённости требований и прочим характеристикам agile- и plan-driven-проекты значимо не различались. Заметных отличий два: в agile-группе была выше вовлечённость руководства в изменение процессов (executive buy-in for process change) и сильнее приоритет низкой стоимости. Вывод авторов: ранний выбор методологии без знания контекста затруднителен.

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

Посмотрите, что именно McKinsey предлагает «адаптировать»: состав команд, длину спринтов, церемонии, программный офис, тестовую автоматизацию. Всё это механика поставки продукта. Ни один пункт не адресует то, что в трансформации является блокирующим фактором: организационные решения и межфункциональные конфликты. Кто уступит в споре закупок и финансов о структуре аналитики? Какая вертикаль поступится своими KPI ради сквозного процесса? Такие вопросы не решаются ретроспективой спринта. Они решаются позицией первых лиц.

Исследование 21 внедрения не доказывает, что методология не важна. Но оно показывает: одним из немногих факторов, отличавших agile-проекты от plan-driven, была вовлечённость руководства в изменение процессов. И это очень хорошо совпадает с практикой больших трансформаций.

Тезис 2. «Адаптированный Agile» - это гибрид, который стесняются так называть

Сначала зафиксируем термин. Agile в строгом смысле подразумевает переменный объём при фиксированном времени и команде, минимально жизнеспособный продукт вместо полного охвата, право менять требования в любой момент и самоорганизацию команд вокруг приоритетов заказчика. Именно в этом смысле слово используют, когда говорят «внедряйте гибко».

У McKinsey действительно описана полноценная agile-поставка: двух-трёхнедельные спринты, сквозные команды с бизнес-владельцами продукта, инкрементальная поставка, регулярные E2E- и приёмочные тесты, несколько волн внедрения. Но одновременно: весь объём проекта определяется заранее, на верхнем уровне, с критериями успеха, «в отличие от обычного для agile подхода к MVP»; работы над архитектурой и процессами больше, чем принято в agile; фаза сквозного тестирования и cutover длиннее спринта; сверху сильный проектный офис. И прямая цитата: «развёртывание в основном следует классическому подходу, но развёртывания происходят чаще». «Северсталь» прошла концептуальное проектирование по Waterfall и лишь затем включила инкременты, причём с жёсткой каденцией, где каждый четвёртый спринт отдан не разработке, а интеграции общего результата. SAP ведёт программу через фазы и quality gates. Franco пускает спринты только в технические подпотоки, увязывая их вехи с общим каскадным планом.

Точное имя этой конструкции: гибридная модель, agile-поставка внутри классического контура управления ERP-программой. Никто из авторов не переносит Agile на уровень управления программой: периметр, финансирование, архитектурные полномочия и точка запуска везде остаются классическими. Поэтому вопрос не в том, Agile это или Waterfall. Вопрос в том, на каком уровне программы находится Agile.

Конструкция разумная, я сам проповедую именно ее. Механика вреда от вывески проста. CEO читает заголовок «миф развенчан» и требует «внедрять гибко». В середине программы это оборачивается фразой бизнес-заказчика «мы же agile, давайте поменяем». Разницу между «внедряем по Agile» и «agile-поставка внутри жёсткого контура» компания узнаёт в самый дорогой момент: на подготовке к запуску.

Тезис 3. Миграция данных: не сервис для тестирования, а трансформационный стрим

В тексте McKinsey миграция данных отнесена к «нефункциональной работе», которую agile-подход затрагивает меньше функциональной поставки: от команды миграции требуется пораньше поставлять данные для наполнения тестовых сред. Формально их тезис и мой могут быть верными одновременно: Agile действительно меняет миграцию меньше, чем функциональную разработку. Но, на мой взгляд, McKinsey здесь серьёзно недооценивает роль итеративности, и корень недооценки в самом взгляде на миграцию как на вспомогательную функцию.

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

Отсюда её итерационная природа. Трансформация замещает десятки разрозненных систем с колоссальным объёмом некачественных или отсутствующих данных, при этом целевая модель данных уточняется по ходу программы. Один цикл «выгрузка, трансформация, загрузка» не даёт приемлемого качества в принципе. Цикл нужно автоматизировать и прогонять многократно, с первого прототипа, на каждой итерации повышая аналитичность и качество обогащения данных.

Из практики. В реализованных мной программах трансформации в промышленности до финальной загрузки в продуктив было выполнено семь полных итераций миграции по отдельным объектам данных. При «одном цикле в конце» программа не запустилась бы физически.

Косвенно статус миграции подтверждают и сами источники: у «Северстали» это одна из трёх платформенных команд программы, у Franco очистка и миграция данных стоят первым кандидатом на итеративный подход, в тулчейне SAP под миграцию выделен специализированный партнёрский инструмент. Откуда у консультантов взгляд на миграцию как на сервис, понятно: так она выглядит в мире классической разработки софта, где данные нужны, чтобы тестировать код. В трансформации это не так, и планирование программы по такой картине мира закладывает серьезные риски запуска.

Тезис 4. Владелец продукта не заменяет решения первых лиц

В списке причин провалов ERP-программ McKinsey сами указывают: решения об операционной модели, управлении данными и полномочиях требуют уровня исполнительного комитета, возникают в середине программы и опираются на информацию, которой ещё нет. А в списке рецептов предлагают наделить владельцев продукта полномочиями принимать ключевые решения с самого начала.

Противоречия здесь нет, если понимать, что речь о решениях разных уровней. Проблема в том, что источники эти уровни не разводят, а компании на практике их путают.

Владелец продукта решает: приоритеты и очерёдность функциональности, компромиссы между требованиями, детали процесса внутри уже утверждённой модели.

Проектный офис управляет: архитектурными конфликтами, зависимостями между стримами работ, изменениями общего объёма, межфункциональными и межсистемными интеграциями, ресурсами.

CEO, ТОП-менеджмент и Владельцы процессов определяют: операционную модель, владение данными, KPI, организационные преобразования, конфликты интересов между функциями и вертикалями.

Владелец продукта незаменим на своём уровне, но он не может быть заменой решений первых лиц. Сбой происходит, когда компания пытается делегировать владельцу продукта решения, которые по своей природе являются решениями об операционной модели: какая вертикаль и как должна перераспределить полномочия и функции, какие целевые управленческие аналитики должны измениться и/или стать общими. В традиционных компаниях такие вопросы к тому же упираются в HiPPO, привычку решать мнением самого высокооплачиваемого человека в комнате, а не данными.

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

Тезис 5. Подготовка к Go-Live: единственный этап, где Agile действительно опасен

Фраза McKinsey «развёртывание в основном следует классическому подходу» - почти всё, что оптимистичная версия говорит о самой опасной фазе. Между тем именно в точке запуска сходится всё: инкременты всех команд, сквозные процессы, интеграции, финальная миграция. Эта фаза управляется жёстким чек-листом, полным регрессионным тестированием и каскадным cut-over-планом.

У гибкости есть своя экономика. Agile даёт право менять решение до тех пор, пока стоимость изменения меньше стоимости преждевременной фиксации. За определённый срок до Go-Live эта экономика разворачивается: стоимость изменения становится выше стоимости отказа от него, потому что каждая правка тянет за собой цепочку из переделки, тестирования, интеграций, миграции, обучения и сдвига сроков. Гибкость требований на этом отрезке превращается из адаптивности в прямой риск остановки операционной деятельности.

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

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

Тезис 6. Чем ERP ближе к стандарту, тем меньше нужен Agile

Разговор об Agile в ERP сегодня невозможно вести, игнорируя стратегию fit-to-standard. SAP строит современную методологию вокруг стандартизованного каркаса и минимизации кастомизаций; Franco формулирует то же самое как совет клиентам: не заставляйте ERP соответствовать старым процессам, используйте отраслевые best practices, зашитые в систему.

Отсюда парадокс, который редко проговаривают. Чем стандартнее ERP, тем меньше неопределённости в функциональном дизайне и тем меньше причин использовать Agile как способ постоянно переизобретать процессы. Гибкость в трансформации нужна не для того, чтобы бесконечно менять систему. Она нужна, чтобы быстро проверять соответствие стандарту: увидеть на прототипе разрыв между стандартным процессом и реальностью компании и осознанно решить, что дешевле - кастомизация или организационное изменение.

Что из этого следует

Исследование 21 внедрения заканчивается выводом, который стоит выучить всем участникам спора: по общим характеристикам проекта нельзя заранее определить, должен ли он быть agile или waterfall. Решает контекст: конкретная организация, её культура, готовность руководства менять процессы, цели программы.

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

Как это устроено на практике

Рабочая конструкция из практики больших трансформаций выглядит так.

Гибридная фиксация объёма - ядро модели. На верхнем уровне жёстко фиксируется периметр: сквозные процессы, модули, ключевые функции, критерии успеха. Уровнем ниже фиксируются не детальные требования, а лимиты: объём разработок на программу в целом или по функциональным блокам и допустимое число переделок ранее утверждённых требований. Внутри лимитов команды свободны в приоритизации и уточнении. Конструкция закрепляется в базовых допущениях и ограничениях программы - основы в управлении объемом работ. Она даёт то, чего не даёт ни каскад, ни чистый Agile: детальную оценку объёма на этапе планирования и управляемую гибкость в ходе реализации.

Лимиты - это управление стоимостью изменений. Лимит переделок не запрещает изменения, он делает их стоимость видимой: каждое изменение тянет цепочку из переделки, тестирования, интеграции, миграции и обучения. Гибкость должна иметь лимит, иначе она превращается в способ незаметно увеличивать стоимость программы.

Из практики. Лимит «не более трёх переделок на утверждённое изначальное требование» за квартал дисциплинировал обе стороны: стала видимой прямая связь между бесконечной гибкостью и бесконечным бюджетом.

Итеративность там, где она окупается. Дизайн целевых процессов ведут смешанные команды бизнес-экспертов и ERP-консультантов, на прототипах, вместо многомесячного описания AS-IS. Это сокращает фазу дизайна, а главное, обнуляет поток фантазийных требований: бизнес видит стандарт вживую. Разработка и тестирование идут инкрементами под контролем лимитов на разработки и переделки. Миграция данных прогоняется максимальным числом автоматизированных циклов по критичным объектам миграции. Документация детализируется каскадно, по мере снятия неопределенности.

Расчёт мощности команды против «крайнего срока». Итерации делают измеримыми скорость уточнения требований, долю переделок, темп реализации и тестирования. Это позволяет заблаговременно, а не в декабре, формировать с бизнес-заказчиком ожидания: что из всего объёма требований, с учётом их критичности, входит в минимально необходимый и достаточный объем первоначального запуска, а что включается в релизное развитие после него, хоть ежемесячно. Релизное развитие после старта и есть легитимное место для настоящей продуктовой гибкости.

Красные линии. Заморозка объёма перед запуском, с персональным правом на исключения на уровне Спонсора программы. Целевая оргмодель до, а не во время. Кросс-функциональные решения на уровне первых лиц, на данных, а не на мнениях.

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

Вывод

Никто из серьёзных авторов на самом деле не предлагает внедрять трансформационный ERP как чистый Scrum-проект. Даже те, кто говорит «Agile ERP», добавляют архитектуру, governance, интеграции, миграцию, сквозное тестирование, этапные ворота и контролируемый cut-over.

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

Пять вопросов, по которым первое лицо или совет директоров могут проверить любую ERP-программу и любого консультанта с презентацией про гибкость.

1. Что зафиксировано на верхнем уровне: периметр программы и критерии успеха?

2. Какие лимиты установлены на объём разработок, кастомизации и переделки утверждённых требований?

3. Кто имеет право изменить ранее принятое решение и по какой процедуре?

4. Когда наступает заморозка объёма перед запуском и кто персонально вправе делать исключения?

5. Кто принимает кросс-функциональные решения, когда функции не могут договориться?

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

Кейсы взяты из практики трансформационных программ в промышленности, ритейле и строительстве.

Разбираемые источники: McKinsey, «Agile in enterprise resource planning: A myth no more» (2019); SAP, документация RISE with SAP Methodology / SAP Activate; SAP, Business Innovation Framework for SAP S/4HANA (2020); А. Кузнецов, К. Краснова («Северсталь»), «Как мы замиксовали Agile для внедрения новой ERP-платформы» (Хабр, 2021); J. P. Franco, «Leveraging Agile Methodologies in ERP Implementations»; L. Gren, A. Wong, E. Kristoffersson, «Choosing agile or plan-driven ERP implementations: A study on 21 implementations from 20 companies» (2019).