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

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

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

## Что такое ERP?

ERP (enterprise resource planning, система управления предприятием) объединяет основные процессы компании в одной системе. Согласно определению Microsoft, ERP представляет собой ПО для управления бизнесом, которое помогает организациям интегрировать их основные процессы, например финансы, цепочку поставок, производство, управление персоналом, закупки и управление проектами ([Microsoft: What is ERP?](https://www.microsoft.com/en-us/dynamics-365/topics/erp/what-is-erp)).

На практике ценность ERP в том, что одни и те же данные создаются только один раз: из поступившего заказа получается отпуск товаров со склада, затем на его основе выставляется счёт, а по счёту формируются бухгалтерская проводка и дебиторская задолженность. Если эти шаги живут в разных программах и таблицах, данные переносятся вручную, а вместе с ними переносятся и ошибки. Учёт клиентов и продаж является смежной областью, но решение по ней принимается отдельно; об этом мы пишем в статье [Когда стоит разрабатывать индивидуальную CRM?](https://www.mestersegesintelligenciakozpont.hu/ru/knowledge-base/when-is-a-custom-crm-worth-it)

## Три пути к ERP

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

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

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

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

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

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

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

Система строится на собственных процессах и модели данных компании, и создаётся только то, что действительно нужно. Нет ядра производителя, которое нужно было бы обновлять, а о дальнейшем развитии решает заказчик. Взамен нужно организовать разработку, эксплуатацию и сопровождение, силами собственной команды или разработчика по договору. Общему сопоставлению заказного и готового ПО посвящена статья [Заказное ПО или готовое решение (SaaS)?](https://www.mestersegesintelligenciakozpont.hu/ru/knowledge-base/custom-software-vs-off-the-shelf)

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

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

- **SAP:** согласно подходу «clean core» («чистое ядро»), расширения должны быть строго отделены от приложения SAP и работать через чётко определённые, устойчивые к обновлениям интерфейсы; прямое изменение или копирование стандартных объектов производитель считает более проблематичным, поскольку после каждого пакета исправлений или обновления оно может потребовать тщательного повторного тестирования ([SAP Learning: Introducing the Clean Core Approach](https://learning.sap.com/courses/practicing-clean-core-extensibility-for-sap-s-4hana-cloud/introducing-the-clean-core-approach_fcb6c662-7041-4c99-88bd-345636fae7f3)).
- **Microsoft Dynamics 365:** для продуктов Finance, Supply Chain и Commerce производитель обосновывает модель, основанную на расширениях, тем, что облако и частые обновления требуют менее инвазивной доработки, так что обновления с меньшей вероятностью затрагивают индивидуальные решения; в этих продуктах расширение является единственным способом доработки, а переопределение кода приложения (overlayering) не поддерживается ([Microsoft Learn: Extensibility home page](https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/extensibility/extensibility-home-page)).
- **Odoo:** согласно документации, базу данных с индивидуальными модулями нельзя обновить, пока индивидуальные модули не будут подготовлены для целевой версии, а за совместимость отвечает тот, кто сопровождает индивидуальный модуль ([Odoo: Upgrade](https://www.odoo.com/documentation/19.0/administration/upgrade.html)).

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

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

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

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

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

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

При выборе готовой ERP стоит спросить, есть ли у продукта венгерская локализация, кто сопровождает подключение к NAV при изменении спецификации и как продукт взаимодействует с венгерскими банками и сервисами выставления счетов. В индивидуальной ERP те же подключения входят в разработку. Подробнее о связывании систем мы пишем на странице [Автоматизация процессов](https://www.mestersegesintelligenciakozpont.hu/ru/services/process-automation).

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

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

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

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

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

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

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

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

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

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

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

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

Там, где ошибка стоит денег, ИИ предлагает, а утверждает человек. О подключении моделей и о защите данных мы пишем на странице [Интеграция ИИ](https://www.mestersegesintelligenciakozpont.hu/ru/services/ai-integration).

## Наш опыт

Прямо сейчас мы разрабатываем большую 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), и на его основе составляются предложение и график работ; метод описан на странице [Ценообразование](https://www.mestersegesintelligenciakozpont.hu/ru/pricing). По запросу мы заключаем соглашение о неразглашении (NDA), а после передачи также берём на себя эксплуатацию и сопровождение. Вопросы исходного кода и прав на использование регулируются договором.

Подробности вы найдёте на странице [ПО для бизнеса](https://www.mestersegesintelligenciakozpont.hu/ru/services/business-software). Если вы хотите поговорить с нами о своей системе, напишите нам по контактам, указанным на странице [Контакты](https://www.mestersegesintelligenciakozpont.hu/ru/contact).

## Источники

- [Microsoft: What is ERP?](https://www.microsoft.com/en-us/dynamics-365/topics/erp/what-is-erp)
- [SAP Learning: Introducing the Clean Core Approach](https://learning.sap.com/courses/practicing-clean-core-extensibility-for-sap-s-4hana-cloud/introducing-the-clean-core-approach_fcb6c662-7041-4c99-88bd-345636fae7f3)
- [Microsoft Learn: Extensibility home page (Finance and Operations)](https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/extensibility/extensibility-home-page)
- [Odoo: Upgrade (документация Odoo 19.0)](https://www.odoo.com/documentation/19.0/administration/upgrade.html)
- [NAV Online Számla: главная страница](https://onlineszamla.nav.gov.hu/)
- [NAV Online Számla: документация (спецификация интерфейса 3.0)](https://onlineszamla.nav.gov.hu/dokumentaciok)