Российский рынок систем IBP (Integrated Business Planning), по данным CNews, в 2024 году вырос примерно на 17%, достигнув объема в 3,5 млрд рублей. Импортозамещение SAP IBP и Oracle Demand Management Cloud подстегнуло спрос. Но вместе с деньгами пришли и разочарования от внедрения. Как не потратить деньги на IBP-проект впустую, рассказывает Екатерина Маркелова, бизнес-аналитик в «Навикон».

Долго, дорого и без результата
Под IBP обычно понимают подход или класс цифровых систем, объединяющих стратегию, операционное планирование и финансовые показатели компании в единую управляемую модель. Спрос на такие продукты быстро растет — в условиях высокой волатильности рынка заказчики рассчитывают с помощью IBP повысить прозрачность планирования и управления финансовыми потоками. Однако, по данным исследования Oliver Wight, реальную пользу от интегрированного бизнес-планирования получают менее 15% организаций.
Это означает, что более 85% проектов в лучшем случае окупаются частично, а в худшем — приносят только разочарование, конфликтующие планы продаж, закупок и производства, которые по старинке сводят в Excel. Чтобы не уйти в бесконечную череду доработок на проекте и в итоге не попасть в ситуацию, когда потратили много денег и не добились результата, важно избегать нескольких типовых ошибок.
Ошибка первая: неверно сформулированная цель
Хорошая цель для проекта внедрения IBP должна звучать так: «Создать единый, структурированный и скоординированный процесс планирования, в котором все функции компании работают в едином информационном пространстве, согласовывают планы между собой и действуют на основе централизованных данных». Плохо сформулированные цели бывают двух типов:
- Первый — характеризует завышенные ожидания. Амбициозная задача «внедрить полный цикл IBP планирования за один год» почти гарантированно провалится, если в компании отсутствует четко прописанная методология планирования, либо если процессы сильно разветвлены и запутаны. Вместо того чтобы замахиваться на годовой проект с нуля, стоит сначала построить дорожную карту, выделить минимально жизнеспособный продукт (MVP), а уже потом наращивать функционал до целевой модели автоматизации. Поэтапный подход спасает от переделок, лишних затрат и раздражения бизнес-заказчиков.
- Второй тип неудачной цели характеризуется несоответствием ожиданий и реальности. Например, «снизить затраты в цепочке поставок на 30%» — звучит как то, ради чего нанимают топ-менеджеров. Но IBP не нацелен на снижение затрат. Скорее, на создание сбалансированной системы, где продажи, маркетинг, закупки, логистика, производство и финансы тесно связаны. И уже реализация кросс-функционального взаимодействия приводит к постепенному снижению затрат в каждом звене.
Оцифрованное значение в 30% в уставе проекта — почти всегда путь к тому, что через год вас спросят: «А где 30%?». Их нет, потому что главная цель IBP — согласование, а не экономия. Экономия придет потом (или не придет), но если она была единственным KPI – проект признают провальным.
Ошибка вторая: «грязные» данные
Цель сформулирована, декомпозиция на задачи сделана. Теперь важно понять на каких данных все это будет строиться, и можно ли этим данным верить. Большинство руководителей на этом этапе скажут «да», но это чаще всего не так.
Если сказать «нет», это будет означать, что проект по IBP нужно останавливать и начинать другой — по нормализации данных и управлению мастер-данными. А это дополнительные деньги, время и неудобные разговоры с владельцами процессов. Поэтому компании предпочитают не замечать проблему. И зря.
Согласно отчету IBM Institute for Business Value (IBV) за 2025 год, более четверти организаций оценивают свои ежегодные потери от плохого качества данных в сумму свыше 5 млн долларов. 7% компаний теряют $25 млн и более. А исследование Stibo Systems 2025 года показало, что 91% руководителей признают важность управления клиентскими данными, но лишь 31% полностью доверяют данным.
В России ситуация, по данным исследования Gartner, не лучше. 72% компаний фиксируют финансовые потери из-за проблем с данными, а 36% признают, что им не хватает компетенций для управления быстро растущими объемами информации.
IBP, запущенный на «грязных» данных, дает прогнозы, которые нельзя выполнить. И когда через полгода выясняется, что план продаж построен на истории с дублями клиентов и пропущенными возвратами, переделывать уже поздно.
Ошибка третья: отсутствие методологии
Допустим, что цель верна, а данные — в порядке. Или хотя бы компания признала, что они не в порядке, и запустила параллельный проект по нормализации данных. Дальше нужно узнать: «Как вы хотите производить расчеты? Что учитывать, а что игнорировать? Кто будет принимать результаты?».
Методология планирования — формализованные правила, по которым прогноз спроса превращается в план закупок, а план закупок — в бюджет. Если у компании нет методолога или хотя бы ответственного от бизнеса эксперта, который может сказать «это правильный расчет, а это нет», проект превращается в бесконечные согласования. Аналитики Lokad назвали это «театром консенсуса». Вариантов два:
- Первый — найти интегратора, который окажет услугу по разработке методики.
- Второй — выделить ответственного из числа бизнес-экспертов, чтобы он разработал внутреннюю методику, и главное — вся компания ее приняла и стала на нее равняться.
Без этого IBP-софт лишь усилит соблюдение процедур, но не улучшит результаты.
Ошибка четвертая: самостоятельный выбор продукта
Если компания действует самостоятельно, она обычно нанимает в штат или на аутсорс специалиста из бизнес-области, запускает анализ рынка, смотрит презентации вендоров, запрашивает техническую документацию. Сравнивает, выбирает и покупает. Вероятность ошибиться при таком подходе достаточно велика, ведь легко выбрать красивое, даже функциональное, но неподходящее решение. Однако потом его нужно менять, затрачивая еще больше денег.
В связи с этим важно уже на старте искать грамотного продуктового эксперта — это может быть как отдельный специалист, так и интегратор. В случае интегратора он закроет еще один вопрос — выбор исполнителя проекта, ведь обычно у интегратора есть команда с опытом и реальными кейсами внедрения. Не нужно будет своими силами собирать или переучивать штат и отлаживать внутренние процессы.
Как проверить готовность к IBP
Есть тест для топ-менеджера, который задумался об IBP — возьмите лист бумаги и ответьте на пять вопросов. Если хотя бы на один ответ «нет» или «не уверен», пересмотрите проект:
- Сформулирована ли цель как процесс, а не как цифровой показатель? Правильно: «Создать кросс-функциональное согласование», а неправильно: «Снизить запасы на 25%».
- Есть ли в компании утвержденная методика планирования, которую знают и принимают руководители продаж, закупок, производства и финансов?
- Данные в системах учета (ERP, CRM, WMS) точны? Проведите простой аудит: возьмите 100 случайных записей о продажах за прошлый месяц и проверьте, совпадают ли номенклатура, количество и цена с первичными документами. Если ошибок больше 5% — данные не готовы.
- Есть ли у вас проверенный интегратор, который уже внедрял IBP на выбранном классе задач? Именно по IBP с похожим объемом и сложностью.
- Готов ли интегратор предложить пилотный проект на 2-3 месяца за фиксированную сумму, а не сразу годовой контракт с неясными результатами?
Успешное внедрение IBP без траты лишних денег и нервов строится на пяти китах: определение цели и измеримых задач, методика расчетов и приемка результатов, подготовленные и достоверные данные в нужном объеме, проверенный интегратор, который отвечает и за софт, и за процесс, и подходящий программный продукт, выбранный под конкретную архитектуру и алгоритмы.
Если хотя бы один из пяти шагов вызывает сомнение, лучше остановиться и уйти в проект по нормативно-справочной информации, по методологии и по аудиту данных — это сэкономит бюджет. Только когда все пять пунктов вызывают уверенность, можно двигаться дальше, ведь только в этом случае IBP принесет прибыль и пользу.