Индивидуальная ERP или доработанная готовая ERP?

По мнению Mesterséges Intelligencia Központ Kft., компании по разработке программного обеспечения из Будапешта, готовая ERP подходит, если процессы можно подстроить под стандарт; индивидуальная ERP оправдана, если работа компании отличается или доработка уже поставила бы под угрозу обновления.

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

Что такое ERP?

ERP (enterprise resource planning, система управления предприятием) объединяет основные процессы компании в одной системе. Согласно определению Microsoft, ERP представляет собой ПО для управления бизнесом, которое помогает организациям интегрировать их основные процессы, например финансы, цепочку поставок, производство, управление персоналом, закупки и управление проектами (Microsoft: What is ERP?).

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

Три пути к ERP

Вопрос «индивидуальная или готовая» на деле означает выбор из трёх вариантов. Граница между ними нечёткая, но разница в стоимости, обновлениях и зависимости значительна.

Готовая ERP как есть

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

Готовая ERP с настройкой и расширениями

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

Конфигурирование (настройка): использование возможностей, заранее предусмотренных производителем, без программирования: рабочие процессы, уровни согласования, поля, печатные формы, права доступа.
Расширение (extension): новая функциональность через поддерживаемые и документированные производителем точки расширения и интерфейсы, без изменения собственного кода продукта.
Модификация (доработка ядра): переписывание собственного кода или объектов производителя либо их копирование и переписывание. Это даёт больше всего свободы, но, согласно собственной документации производителей, при обновлениях именно это несёт наибольший риск (см. ниже).

Индивидуальная ERP

Система строится на собственных процессах и модели данных компании, и создаётся только то, что действительно нужно. Нет ядра производителя, которое нужно было бы обновлять, а о дальнейшем развитии решает заказчик. Взамен нужно организовать разработку, эксплуатацию и сопровождение, силами собственной команды или разработчика по договору. Общему сопоставлению заказного и готового ПО посвящена статья Заказное ПО или готовое решение (SaaS)?

Почему многочисленные доработки затрудняют обновление?

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

SAP: согласно подходу «clean core» («чистое ядро»), расширения должны быть строго отделены от приложения SAP и работать через чётко определённые, устойчивые к обновлениям интерфейсы; прямое изменение или копирование стандартных объектов производитель считает более проблематичным, поскольку после каждого пакета исправлений или обновления оно может потребовать тщательного повторного тестирования (SAP Learning: Introducing the Clean Core Approach).
Microsoft Dynamics 365: для продуктов Finance, Supply Chain и Commerce производитель обосновывает модель, основанную на расширениях, тем, что облако и частые обновления требуют менее инвазивной доработки, так что обновления с меньшей вероятностью затрагивают индивидуальные решения; в этих продуктах расширение является единственным способом доработки, а переопределение кода приложения (overlayering) не поддерживается (Microsoft Learn: Extensibility home page).
Odoo: согласно документации, базу данных с индивидуальными модулями нельзя обновить, пока индивидуальные модули не будут подготовлены для целевой версии, а за совместимость отвечает тот, кто сопровождает индивидуальный модуль (Odoo: Upgrade).

Вывод у SAP и Microsoft одинаков: ядро должно оставаться нетронутым, а то, что уникально для компании, должно жить в обособленном расширении или в отдельном модуле, который общается с готовой системой через документированный интерфейс; у Odoo же именно сопровождение индивидуальных модулей определяет, когда систему можно обновить. Если необходимая уникальность настолько велика, что это уже нельзя решить чисто, это сильный сигнал в пользу индивидуальной ERP или индивидуального модуля.

Венгерская специфика: NAV Online Számla, выставление счетов, банки, интернет-магазин

ERP венгерской компании должна работать и с венгерскими системами. Важнейшая из них, NAV Online Számla, представляет собой онлайн-систему передачи данных о счетах венгерской налоговой службы (NAV): по информации NAV, с 4 января 2021 года обязательно передавать данные о каждом счёте, корректировочном и аннулирующем счёте, на которые распространяются правила выставления счетов венгерского закона об НДС (NAV: Online Számla).

Поддерживается версия 3.0 межсистемного (машинного) интерфейса (проверено 17 октября 2026 года). Согласно спецификации интерфейса, программа для выставления счетов должна передавать данные автоматически, без отдельного вмешательства человека в рамках процесса; NAV обрабатывает переданные данные асинхронно, и передача данных не считается выполненной, пока программа не убедилась в успешности обработки и не получила квитанцию по соответствующему счёту (NAV Online Számla: документация). NAV время от времени изменяет спецификацию (в августе 2026 года тоже была опубликована изменённая версия), поэтому подключение нужно сопровождать.

Что, как правило, должна уметь ERP венгерской компании и что мы подключаем:

NAV Online Számla: передача данных счетов через машинный интерфейс, запрос результата обработки и обработка ошибок.
Сервисы выставления счетов: если счета по-прежнему выставляются во внешнем сервисе, подключение идёт через его интерфейс.
Банки: загрузка банковских выписок и транзакций, сопоставление поступлений со счетами.
Интернет-магазин: синхронизация заказов, остатков и цен между интернет-магазином и ERP.
Курьерские службы и другие системы: отправка посылок, существующая CRM, электронная почта и календарь.

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

Таблица для выбора

Критерий	Готовая ERP как есть	Расширенная готовая ERP	Индивидуальная ERP
Соответствие процессам	компания подстраивается под стандартные процессы	большая часть стандарта подходит, отдельные моменты уникальны	работа компании существенно отличается от стандарта
Запуск	как правило, быстрый, если достаточно настройки	дольше из-за разработки расширений	требует времени на разработку, может проходить поэтапно
Обновления	поставляет производитель, с небольшим риском	расширения нужно проверять при каждом обновлении	планирует заказчик, выполняет разработчик
Уникальные процессы	только с помощью настроек	через точки расширения или в отдельном модуле	любая бизнес-логика
Интеграции	через коннекторы производителя и его партнёров	коннекторы и индивидуальные интеграции	с чем угодно, если доступен его интерфейс или данные
Структура затрат	плата за лицензию или подписку на условиях производителя	лицензия плюс разработка и сопровождение расширений	разработка, эксплуатация и дальнейшее развитие
Зависимость	от производителя и будущего продукта	от производителя и партнёра, разрабатывающего расширения	при наличии исходного кода развитие может продолжить другой разработчик
Кому подходит?	компании с типовыми процессами, которой нужен быстрый запуск	тем, для кого стандарт служит хорошей основой, но в отдельных моментах нужно иначе	тем, у кого уникальны процессы или интеграции

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

Переход со старой системы

ERP-проект редко начинается с чистого листа: есть старая программа, готовая система или набор таблиц, в которых хранятся данные за многие годы. Этапы перехода:

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

Не обязательно заменять всё сразу. Часто реалистичный путь такой: новый модуль сначала встаёт рядом со старой системой, и они обмениваются данными через интерфейс, пока старую часть не удастся заменить.

Риски и как их снизить

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

Где помогает искусственный интеллект в ERP?

Большие языковые модели (ChatGPT от OpenAI, Claude от Anthropic и Gemini от Google) полезны там, где раньше человек читал, копировал или составлял тексты:

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

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

Наш опыт

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

Частые вопросы

Когда стоит разрабатывать индивидуальную ERP?

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

Насколько можно доработать готовую ERP?

Многими способами, но важно, каким именно. Настройки (конфигурирование) и поддерживаемые производителем точки расширения мало влияют на обновления; изменение же кода производителя может создавать новую работу при каждом обновлении. Документация крупных производителей, SAP и Microsoft, рекомендует оставлять ядро нетронутым и обособлять расширения; согласно документации Odoo, сопровождение индивидуальных модулей является условием обновления.

Чем рискованны многочисленные доработки?

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

Как проходит переход со старой системы?

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

Подключаете ли вы NAV Online Számla?

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

Как мы можем помочь?

Mesterséges Intelligencia Központ Kft. разрабатывает индивидуальные ERP-, CRM- и учётные системы, создаёт для готовых систем индивидуальные модули и интеграции и связывает их с помощью искусственного интеллекта. Первая консультация бесплатна, и если готовой ERP достаточно, мы и об этом скажем. Функциональный размер разработки мы измеряем в функциональных точках COSMIC (ISO/IEC 19761), и на его основе составляются предложение и график работ; метод описан на странице Ценообразование. По запросу мы заключаем соглашение о неразглашении (NDA), а после передачи также берём на себя эксплуатацию и сопровождение. Вопросы исходного кода и прав на использование регулируются договором.

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