Почему ERP-системы медленные и дорогостоящие в развертывании — по замыслу

Joannes Vermorel

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

Неудобная правда заключается в том, что большинство внедрений ERP медленные и дорогостоящие по структурным причинам. Не потому, что каждая вовлечённая команда некомпетентна. И даже не потому, что требования были неясны. Они медленные и дорогостоящие, потому что экономические и технические стимулы, формировавшие ERP на протяжении десятилетий, делают их таковыми как категория.¹

В моей книге Введение в цепочку поставок (глава 5, «Информация», раздел «Системы учета») я уделяю внимание удивительно заброшенной идее: программное обеспечение, фиксирующее транзакции, является одновременно незаменимым и по своей сути ограниченным. Его задача — быть надежной бухгалтерской книгой — и ничем более. Когда компании забывают об этом, они начинают платить «стратегические» цены за то, что по существу является транзакционной канцелярской машиной. Именно с этим недоразумением начинаются проблемы.

Джунгли сущностей и беговая дорожка поставщика

Начнём с того, что такое ERP на практике. Это транзакционная система, построенная на основе реляционной базы данных, которая отслеживает ресурсы компании и рутинные операции через множество модулей, экранов и обширный каталог «сущностей» (продукты, клиенты, счета, заказы и так далее).¹

А теперь динамика, которая незаметно гарантирует, что внедрения ERP будут болезненными.

Поставщик ERP не разрабатывает программное обеспечение «для вас». Они создают его для совокупности своей клиентской базы на протяжении десятилетий. Продукт растёт путем накопления. Каждый крупный клиент приносит с собой несколько «обязательных» концепций, исключений, рабочих процессов, регуляторных особенностей и терминологии, которые будут требоваться как функции первого класса. Поставщики могут добавлять; они почти никогда не удаляют. Нет коммерческой выгоды в удалении неочевидных сущностей, от которых зависит какой-либо устаревший клиент. Результатом становится продукт, который неустанно расширяется — одна сущность за раз, один модуль за раз.¹

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

При первом внедрении этот рост маскируется процессом продаж. Поставщики ERP продают по модулям; клиентские компании внедряют по модулям. Один модуль сейчас, другой через шесть месяцев, еще один в следующем году. Компания получает иллюзию пошагового прогресса, а интегратор имеет возможность распределить усилия по этапам.¹

Модернизации — вот где иллюзия рушится.

Даже если вы остаетесь с тем же поставщиком, модернизации известны своей сложностью и часто затягиваются на месяцы, а иногда и годы.¹ Техническая причина не таит в себе загадки: миграция редко представляет собой простое копирование один к одному. Значение сущностей эволюционирует. Таблица, которая когда-то означала «заказы клиентов», начинает учитывать и возвраты; «исправление» превращается в отрицательные количества, дополнительные флаги, дополнительные соединения, особые случаи и скрытые последующие предположения, которые тихо ломаются.¹

Вот как возникает настоящая проблема: проблема сопоставления.

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

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

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

Когда одна система пытается выполнять три задачи

Вторая структурная проблема ещё более всеобъемлюща: компании рутинно просят ERP выполнять три различных задачи одновременно.

Они хотят, чтобы ERP фиксировала транзакции (бухгалтерскую книгу), предоставляла аналитику и панели управления («зеркало») и принимала решения (то, что можно назвать «мозгом»). Поставщики с готовностью поддерживают это, поскольку комплектование выгодно: как только ERP позиционируется как «платформа, управляющая компанией», каждый дополнительный модуль становится «обязательным».²

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

Обработка транзакций подразумевает быстрые, надёжные обновления и строгую согласованность. Аналитическая обработка предполагает сканирование больших наборов данных, агрегацию, сегментацию и исследование. Это различные рабочие нагрузки, часто реализуемые с использованием разных моделей данных и различных компромиссов по производительности; индустрия на протяжении десятилетий использует специальные термины для этого различия (OLTP vs OLAP).³

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

Не помогает и тот факт, что «ERP» — вводящее в заблуждение название. Исторически буква «П» в «планировании» воспринималась как обещание интеллекта. На самом деле, планирование в ERP является, в лучшем случае, второстепенным вопросом, а предиктивная аналитика, как правило, противоречит их основному транзакционному дизайну.¹

Моя статья за июнь 2024 года о корпоративном программном обеспечении утверждала, что хронические траты в отрасли возникают из-за смешения этих категорий и переплаты за неподходящие вещи. Основная мысль, без жаргона, проста: бухгалтерская книга не является стратегическим механизмом, и требование сделать её таковой приводит к усложнению без получения преимуществ.²

Если вы хотите яркое подтверждение того, что я не один так думаю, посмотрите, как крупные облачные поставщики описывают системы данных: они прямо рекомендуют использовать транзакционные системы для надёжного хранения и обновления записей и аналитические системы для создания отчётов и проведения сложного анализа. Они не притворяются, что один режим работы базы данных превосходит всё; они описывают дополняющие друг друга роли.³

ERP-поставщики продают противоположную мечту: одну систему, которая делает всё. Эта мечта приносит прибыль. Похмелье оплачивается клиентом.

Ловушка под названием «кастомизация» и работа, называемая «миграция»

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

Статья в ScienceDirect о кастомизации ERP описывает её как «обоюдоострый меч», отмечая, что, хотя кастомизация может улучшить соответствие, она также приводит к увеличению затрат на внедрение, возрастанию сложности и расходам на последующие обновления.⁴ Это академическая версия того, что интеграторы молча закладывают в каждое предложение: любое отклонение от стандартного пути — это будущий налог.

Даже если мы остаёмся в рамках мейнстримовых поставщиков, ситуация остаётся прежней. Руководство Microsoft по внедрению Dynamics 365 прямо заявляет, что «миграция данных — это сложный и затратный по времени процесс», а затем перечисляет виды работ: анализ источников, определение объёма, сопоставление и преобразование полей, загрузка, тестирование, проверка и валидация качества данных.⁵

Внимательно изучите этот список. Это не экзотическая технология. Это не «инновация». Это индустриализация процессов сопоставления и согласования.

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

Более разумная альтернатива: сознательно создайте небольшую бухгалтерскую книгу

В этот момент возникает очевидное возражение: «Хорошо. ERP-системы запутаны. Но нам нужны сложные функции. Нам требуется планирование. Нам нужна оптимизация. Мы не можем просто создать это сами.»

Это возражение содержит ту же категориальную ошибку, что и предложение ERP-систем.

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

И именно здесь 2026 год принципиально отличается от 2015 года.

Сейчас существуют программные агенты, специально разработанные для того, чтобы взять исходный код, набор задач и быстро внести рабочие изменения. Claude Code от Anthropic — это агент-программирования, работающий в терминале и помогающий создавать код с помощью команд на естественном языке. Codex от OpenAI позиционируется как агент в сфере разработки программного обеспечения, способный выполнять задачи, такие как написание функций, исправление ошибок и предложение pull-запросов. xAI предоставляет модели Grok, ориентированные на программирование, которые можно использовать с редакторами кода через стандартные агентские рабочие процессы.

Эти инструменты — не волшебство. Рандомизированное контролируемое исследование, опубликованное METR в июле 2025 года, даже показало, что в определённых условиях (опытные разработчики, работающие с привычными репозиториями с открытым исходным кодом) использование ИИ-инструментов замедляло работу разработчиков в среднем, так как время смещалось с написания к проверке и исправлению.⁶ Этот результат является важным напоминанием: «агентский» не означает «автоматический».

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

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

Почему?

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

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

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

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

Однако аутсорсинг бухгалтерской книги компании монолиту, чьи стимулы — расти, объединять и создавать зависимость, не означает безопасность. Это самый медленный способ купить программное обеспечение, которое в конце концов всё равно придется заменить.

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

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