Почему проекты SAP выходят за рамки бюджета и как это остановить

Проекты SAP выходят за рамки бюджета в основном потому, что компании пытаются удержать стоимость низкой на старте, а затем получают удар на фазе Explore, когда воркшопы Fit-to-Standard показывают реальный объём работ. В программах, которые я анализировал, перерасход в 40–60 процентов встречается часто.

Короткий ответ: бюджет SAP превышается, когда его утвердили до того, как кто-либо знал объём работ, и когда этот объём контролирует поставщик, а не клиент. Следите за числом объектов WRICEF на фазе Explore, сами владейте объёмом работ и держите 10–20 процентов резерва на своей стороне.

Средние цифры опросов выглядят спокойнее. ERP Report 2026 от Panorama Consulting показал, что более четверти организаций превысили бюджет ERP, и главной причиной стали дополнительные технологические потребности. Средние по опросам и программы, которые в итоге оказываются на столе у консультанта, это разные совокупности, поэтому планируйте под вторую.

40-60%

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

Источник: Noel D'Costa, опубликованное наблюдение

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

В 21 программе SAP, которую я возглавлял или спасал, повторяются одни и те же причины. Большинство из них видно ещё до подписания контракта.

1. Бюджет занижают, а затем Explore показывает реальный объём

Это самая частая причина, которую я вижу. Компании пытаются удержать стоимость низкой на старте, часто потому, что бизнес-кейсу нужна цифра, которую утвердит совет директоров. Затем наступает фаза Explore.

В SAP Activate фаза Explore предназначена для воркшопов Fit-to-Standard, на которых стандартные процессы SAP сопоставляются с тем, как бизнес работает на самом деле (SAP Learning). Каждый найденный там разрыв становится элементом бэклога: отчётом, интерфейсом, конвертацией, расширением, формой или workflow. Ничего из этого не было в исходной цене.

Бюджет оказался неверным не потому, что кто-то ошибся в расчётах. Он оказался неверным, потому что его утвердили до того, как появился объём работ. Если можете, проведите короткую оценку Fit-to-Standard до утверждения итоговой цифры.

2. Объём работ контролирует поставщик

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

Разрывы позже всплывают в виде запросов на изменения, и каждый такой запрос оценивает тот же поставщик. Пишите объём работ сами или пригласите независимого от внедрения специалиста, чтобы он написал его вместе с вами.

3. Изменения объёма без контроля затрат

Одна розничная сеть заложила в бюджет $5M, а закончила на $12,3M. Плохой сбор требований привёл к постоянным изменениям объёма. На полпути компания обнаружила, что её процессы управления запасами не совпадают со стандартной функциональностью SAP, и последовали обширные доработки.

Она также недооценила миграцию данных из унаследованных систем. Привести процессы к стандарту на этапе проектирования было бы гораздо дешевле.

4. Сроки, продиктованные давлением руководства

Одна глобальная производственная программа превысила бюджет на 143% ($14M против запланированных $5,8M) и запустилась с опозданием на 11 месяцев. Причины: нереалистичное давление руководства по срокам, недоукомплектованная внутренняя команда, слишком много модулей одновременно и самый дешёвый партнёр без отраслевой экспертизы.

Дешевле не значит автоматически лучше. Клиент, выбравший самый дешёвый вариант внедрения, в итоге потратил на 30% больше на исправление проблем, которых избежала бы более опытная команда.

5. Внутренние сотрудники на неполную занятость

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

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

6. Поздно обнаруженные проблемы с данными

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

Я также разбираю эту тему в видео на моём YouTube-канале (на английском).

Самый явный ранний тревожный сигнал: сама фаза Explore. Следите за числом объектов WRICEF: отчётов, интерфейсов, конвертаций, расширений, форм и workflow. Если этот список растёт от воркшопа к воркшопу, бюджет уже отстаёт от объёма работ.

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

Тревожный сигнал	Что это обычно значит	Что делать
Число объектов WRICEF растёт в ходе Explore	Реальный объём больше оценённого	Пересмотрите базовый бюджет в конце Explore, до начала Realize
Разрывы по умолчанию закрываются решением «доработаем»	Стандартные процессы никто не оспаривает	Попросите владельца бизнес-процесса обосновать каждый разрыв относительно стандарта
Документы по объёму работ составляет системный интегратор	Поставщик определяет, что попадает в оценку	Возьмите объём работ на себя и проверьте его с независимым специалистом
Запросы на изменения рассматриваются раз в месяц или без оценки	Мелкие изменения незаметно накапливаются	Оценивайте каждый запрос на изменение и рассматривайте их еженедельно
Профилирование данных не начато к концу Explore	Проблемы с данными всплывут при тестировании или cutover	Начните профилирование сейчас, параллельно с требованиями
Ключевые пользователи всё ещё на неполной занятости	Решения замедляются, переделок становится больше	Разгрузите их от текущих обязанностей или сдвиньте график

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

1. Владейте объёмом работ. Пишите его на стороне клиента, замораживайте в конце Explore и относитесь к каждому последующему изменению как к оценённому решению, а не как к заметке с воркшопа.
2. Принимайте стандартные процессы. Каждая доработка обходится дважды: при создании и затем при каждом обновлении. Один производственный клиент сэкономил более $800K, адаптировав свои процессы к стандартам SAP вместо доработок. Для некоторых подразделений это было болезненно, но финансовая разница оказалась огромной.
3. Разбивайте тиражирование на этапы. Розничный клиент сэкономил $1,2M, разделив тиражирование на три этапа в течение 18 месяцев вместо того, чтобы делать всё сразу. Первоначальные инвестиции снизились на 40%, а уроки первого этапа ускорили последующие.
4. Платите за экспертизу, а не за низкую дневную ставку. Клиент из химической отрасли сменил универсального партнёра SAP на отраслевого специалиста и потратил в целом на 20% меньше, несмотря на более высокие почасовые ставки. Специалисты работали быстрее и ошибались реже.
5. Держите резерв на своей стороне. Сохраняйте 10–20 процентов поверх бюджета и расходуйте их только под названные риски. Резерв внутри цены партнёра тратится на приоритеты партнёра.
6. Рассматривайте запросы на изменения каждую неделю. Оценивайте каждый запрос по влиянию на бюджет и график до его утверждения, а не в конце месяца.
7. Автоматизируйте регрессионное тестирование. Такие инструменты, как Tricentis Tosca или собственная автоматизация тестирования SAP, окупаются в любой программе с более чем двумя циклами тестирования, а каждое обновление после go-live означает ещё один цикл.

О коммерческой стороне рассказывают мой чек-лист переговоров по лицензиям SAP и обзор стоимости контракта для финансовых директоров: на чём настаивать до подписания.

Модель подписки переносит затраты из капитальных в операционные. Она не устраняет риск перерасхода, но меняет место, где этот риск находится.

GROW with SAP работает на S/4HANA Cloud Public Edition, где расширения допускаются только через выпущенные интерфейсы. Это ограничивает рост списка WRICEF, а программы GROW часто занимают около 6–9 месяцев. Обратная сторона: меньше свободы подстраивать SAP под нестандартные процессы.

RISE with SAP работает на S/4HANA Cloud Private Edition, где ядро по-прежнему можно модифицировать. Clean Core там является решением в рамках управления, а не техническим ограничением, поэтому риск фазы Explore тот же, что и в on-premise. Программы RISE обычно занимают 9–18 месяцев, а многолетний срок подписки должен быть виден в бизнес-кейсе.

AI это новая статья бюджета, а не экономия, которую можно заранее записать в доход. Некоторые возможности Joule входят в облачные подписки SAP, а премиальные функции AI оцениваются отдельно. Запрашивайте допущение о производительности, стоящее за любым прайс-листом партнёра, который обещает экономию за счёт AI.

Это важно для того, как крупная программа отразится в отчёте о прибылях и убытках. По МСФО и US GAAP затраты на создание актива, который вы контролируете, можно капитализировать; затраты на эксплуатацию, обучение и подготовку нельзя. Облако меняет ответ для большой части бюджета.

Статья затрат	Лицензия on-premise	Облачная подписка (RISE / GROW)
Платежи за лицензию или подписку	Капитализировать как нематериальный актив	Относить на расходы в течение срока (договор на услуги)
Услуги по настройке и разработке	Капитализировать, если прямо относимы	МСФО: часто относятся на расходы, если не создают отдельный актив, который вы контролируете. US GAAP: капитализировать затраты на внедрение и амортизировать в течение срока хостинга
Внутренний труд на разработку	Капитализировать, если прямо относим	То же разделение, что выше
Обучение и управление изменениями	Расходы	Расходы
Очистка данных	Расходы	Расходы
Инструменты конвертации данных, которые остаются у вас	Капитализировать, если используются повторно	Оценивать в каждом случае отдельно
Hypercare и поддержка	Расходы	Расходы

Позиция по МСФО основана на решении Комитета по интерпретациям МСФО 2021 года о затратах на настройку и доработку в рамках договоров облачных вычислений. Позиция по US GAAP основана на ASU 2018-15. Особенно по МСФО бизнес-кейс RISE, который исходит из капитализации как в on-premise, может существенно завысить прибыль первого года.

Документация решает, сколько вы сохраните. Один производственный клиент сэкономил $2,3M расходов текущего года благодаря правильной капитализации, потому что вёл учёт работ консультантов достаточно тщательно, чтобы отстоять свой подход. Другой клиент столкнулся с болезненным пересчётом отчётности, потому что не смог обосновать свои решения о капитализации.

Аудиторы пристально изучают крупные капитализированные проекты. Согласуйте с ними политику до начала программы, а не в конце года.

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

Это руководство входит в мой обзор внедрения SAP, где собраны ссылки на все темы, от бизнес-обоснования до запуска.

Почему внедрения SAP выходят за рамки бюджета?

Чаще всего потому, что бюджет держат низким на старте, а затем фаза Explore показывает реальный объём работ. Воркшопы Fit-to-Standard превращают разрывы в отчёты, интерфейсы, конвертации, расширения, формы и workflow, которые никогда не оценивались. Объём, контролируемый поставщиком, внутренние команды на неполной занятости и поздняя работа с данными усугубляют ситуацию.

Насколько обычно проекты SAP превышают бюджет?

В программах, которые я анализировал, перерасход в 40–60 процентов встречается часто. Опрос Panorama Consulting 2026 года показал, что более четверти организаций превысили бюджет ERP. Программы, которые доходят до консультанта, как правило, составляют проблемный хвост этой совокупности.

Каковы ранние тревожные сигналы перерасхода бюджета SAP?

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

Как остановить разрастание объёма работ в проекте SAP?

Владейте объёмом работ на стороне клиента, а не позволяйте системному интегратору его писать. Замораживайте его в конце Explore, оспаривайте каждый разрыв относительно стандарта SAP и оценивайте каждый запрос на изменение до его утверждения. Рассматривайте запросы на изменения еженедельно, а не в конце месяца.

Снижает ли RISE with SAP риск выхода за рамки бюджета?

Само по себе нет. RISE работает на Private Edition, где ядро по-прежнему можно модифицировать, поэтому риск фазы Explore тот же, что и в on-premise. GROW with SAP на Public Edition ограничивает расширения выпущенными интерфейсами, что сужает возможный рост объёма работ.

Можно ли капитализировать затраты на внедрение RISE with SAP?

Частично, и это зависит от вашего стандарта учёта. Сама подписка обычно относится на расходы. По МСФО услуги по настройке и доработке в рамках SaaS-договора тоже часто относятся на расходы, если не создают отдельный актив, который вы контролируете; по US GAAP (ASU 2018-15) затраты на внедрение капитализируются и амортизируются в течение срока хостинга.