2. Модель данных и вычислений
Этот раздел — про фундамент: как в ERP устроены данные и вычисления
и какие ограничения закладываются ещё до кода, форм и интеграций.
Именно здесь определяется, можно ли выразить бизнес-правила как единую модель
или они неизбежно будут расползаться по системе.
2.1 Объекты: справочники, документы и т.д.
Как это обычно реализовано в ERP
Большинство ERP строятся вокруг объектной модели:
справочники, документы, строки, движения.
Бизнес-логика привязывается к жизненному циклу объекта
(создание, редактирование, проведение),
а не описывается как отдельная система правил.
1С
Метаданные (Справочники, Документы, Регистры) — основа архитектуры.
Проверки и расчёты распределяются между проведением,
модулями форм и служебными обработчиками.
SAP
Объектная модель дополняется настройками и расширениями,
но правило часто оказывается композицией стандартного объекта,
кастомного кода и процессного слоя.
Microsoft Dynamics
Entities служат точкой входа,
но логика распределяется между плагинами,
автоматизациями и клиентскими правилами.
Odoo
ORM-модели выглядят целостно,
но при росте кастомизации логика распределяется
между моделями, computed fields и модулями.
Эксплуатационный симптом:
одно бизнес-правило реализовано в нескольких объектах и слоях;
объяснение «почему система так посчитала» требует знания истории внедрения.
Как проверить:
попросить показать одно правило
и все объекты, где оно реализовано или влияет на поведение.
2.2 Неэффективное получение данных объектов
Как это обычно реализовано в ERP
Объекты удобны для транзакций,
но плохо подходят для сложных вычислений.
В итоге данные извлекаются частично запросами,
частично через объекты,
а расчёт собирается процедурно.
1С
Типовой сценарий: запрос + чтение объектов + циклы.
Производительность зависит от дисциплины разработчика.
SAP
Данные доступны через несколько уровней модели,
что усложняет контроль фактических выборок.
Dynamics
ORM/API легко порождают множество обращений
вместо одной оптимальной выборки.
Odoo
ORM скрывает реальные запросы;
проблемы проявляются при росте данных.
Эксплуатационный симптом:
система деградирует по производительности
не сразу, а «вдруг» — при росте объёма.
2.3 Таблицы и представления: регистры
Как это обычно реализовано в ERP
Для аналитики вводится отдельный слой:
агрегаты, движения, представления.
Возникает второй источник истины,
отличающийся от транзакционных данных.
1С
Регистры — ключевой механизм,
но логика расчёта часто частично остаётся в коде.
SAP
Аналог — сочетание движений,
агрегатов и аналитических представлений.
Dynamics
Агрегаты часто выносятся в BI или витрины.
Odoo
Типовые агрегаты есть,
но при росте требований появляются SQL views и внешняя аналитика.
Эксплуатационный симптом:
операции и отчёты расходятся,
пересчёты требуют специальных процедур.
2.4 Регистры поддерживаются в очень частных случаях
Что имеется в виду
Аналитический слой (регистры/агрегаты/витрины) хорошо работает, пока бизнес-правило укладывается
в «типовой» паттерн: остатки, обороты, простые разрезы, стандартные периоды.
Как только появляется нетиповая семантика (исключения, условные правила, альтернативные источники,
исторические «как было на дату» по нестандартному признаку), часть логики перестаёт выражаться
в модели и уходит в код/обработки/интеграции.
Как это проявляется в стандартных ERP
1С
Регистры (накопления/бухгалтерии/сведений) покрывают множество сценариев,
но реальная логика часто распадается: часть — в движениях при проведении,
часть — в запросах отчётов (СКД), часть — в обработках пересчёта.
Как только нужен «нештатный» алгоритм (условные перерасчёты, сложные исключения, альтернативная оценка),
он уходит в процедурный код и перестаёт быть частью единой модели.
SAP
Типовые учёты и аналитика держатся на богатой модели и механизмах расширения,
но «нестандарт» часто реализуется смесью настроек + расширений + отдельной аналитической модели
(или выносом в отдельный слой аналитики). В итоге правило существует сразу в нескольких местах,
а синхронизация становится проектом.
Microsoft Dynamics
В типовом контуре показатели часто «разводятся» по слоям: транзакционные сущности,
правила/плагины, отчётные представления и внешняя аналитика. Нестандартные правила
почти неизбежно оказываются в комбинации: код + low-code автоматизации + витрина/BI.
Odoo
Базовые агрегаты и computed-поля работают до определённой сложности.
Дальше появляются: отдельные модели для «производных» показателей, SQL views,
фоновые пересчёты и внешняя аналитика. Правило перестаёт быть «частью модели»
и превращается в набор реализаций.
Эксплуатационный симптом:
часть правил живёт в «модели» (регистры/агрегаты), часть — в «особых обработках».
Малое изменение начинает требовать правок в нескольких местах, а объяснимость
«почему так посчиталось» падает.
Как проверить на демо/пилоте:
попросить взять один показатель (например, доступный остаток/маржа/лимит) и добавить
2–3 исключения (по типу клиента, складу, дате, альтернативному источнику цены).
Смотри, сохраняется ли единый механизм (одно место/один тип механизма) или правило «расползается»
на код + отчёт + пересчёт + интеграцию.
2.5 Отсутствие ограничений и событий для значений регистров
Что имеется в виду
Во многих ERP ограничения и события хорошо определены для операций (документ/проведение/запись),
но плохо определены для вычисленных/агрегированных значений (остатки, лимиты, рейтинги, риск).
То есть платформа не даёт нативного механизма уровня:
«если агрегат стал таким — запрети/оповести/запусти реакцию», как часть модели.
Поэтому контроль реализуют процедурно: проверками при проведении, фоновыми проверками,
отчётами-валидаторами и ручными регламентами.
Как это проявляется в стандартных ERP
1С
Типовой путь — проверять «по месту» при проведении документа или в форме.
Но агрегат (например, лимит/остаток/оборачиваемость) может меняться не только из одного документа:
из нескольких видов операций, ретро-изменений, пересчётов, обменов. Тогда контроль начинает дублироваться,
а «когда именно сработает запрет» зависит от сценария.
SAP
Контроль часто строят через статусы/процессы/проверки в транзакциях,
а мониторинг агрегатов — отдельными механизмами (процедуры контроля, отчёты, workflow).
Формально это мощно, но правило чаще становится процессной конструкцией,
а не декларативным ограничением на значение.
Microsoft Dynamics
Бизнес-правила и плагины удобно вешать на событие изменения сущности,
но агрегаты обычно считаются отдельно (фон, интеграция, отчётный слой).
В итоге «ограничение на агрегат» реализуется как набор проверок + автоматизаций,
и его трудно доказуемо сделать полным (без дыр).
Odoo
Есть constraints и onchange на уровне моделей, но агрегаты часто живут в computed fields,
которые могут пересчитываться лениво/по триггерам/по крону. Поэтому контроль по агрегату
легко становится недетерминированным: «иногда ловит, иногда нет», если не выстроить строгую дисциплину.
Эксплуатационный симптом:
запреты и контроль работают «не всегда одинаково»:
один пользователь ловит ограничение сразу, другой — позже;
часть нарушений обнаруживается отчётом/проверкой после факта.
Появляются регламенты «проверяйте вручную».
Как проверить на демо/пилоте:
попросить сделать ограничение на агрегат:
«нельзя отгружать, если суммарный риск/лимит по клиенту > X, с учётом всех документов и корректировок».
Затем попросить показать 3 пути изменения агрегата (документ, корректировка задним числом, интеграция/импорт)
и убедиться, что ограничение срабатывает одинаково во всех трёх сценариях.
2.6 В параметрах виртуальных таблиц можно использовать только константы
Что имеется в виду
Когда аналитический слой можно параметризовать только константами (или очень ограниченно),
система не умеет «подстраивать» вычисление под контекст операции.
В итоге приходится:
(1) выбирать данные «шире, чем нужно», а затем фильтровать в коде/форме,
(2) создавать копии запросов/отчётов под разные варианты,
(3) выносить часть логики из модели в процедурные слои.
Это тихо увеличивает стоимость изменений: любое новое условие порождает новые копии.
Как это проявляется в стандартных ERP
1С
Типовой эффект: отчёт/запрос «универсальный» только на словах.
Как только появляются условия «зависящие от контекста» (текущий пользователь, роль, состояние документа,
параметры формы), часть фильтрации уходит в код, а запросы копируются.
Со временем возникает «зоопарк» вариантов почти одинаковых отчётов/выборок.
SAP
Контекстные условия часто решаются настройками, параметрами представлений и процессными слоями,
но при росте вариативности появляется тот же паттерн: разные варианты представлений/запросов/ролей
вместо одного описанного правила. Цена — сложность сопровождения и риск расхождения логики.
Microsoft Dynamics
Ограничения выражений и контекста приводят к размножению представлений/запросов/flows:
«для этой роли одно», «для этой формы другое». Когда бизнес меняет правило,
приходится искать все копии и синхронно править.
Odoo
ORM удобен, но сложный контекст часто приводит к:
доменам/контекстам на уровне UI + отдельным методам выборки в коде + SQL для тяжёлых случаев.
Вариативность фильтров быстро порождает дубли и «локальные решения».
Эксплуатационный симптом:
появляются «почти одинаковые» отчёты, списки и выборки.
Малое изменение условия (ещё один фильтр/исключение) превращается в серию правок:
запрос, код формы, права, отдельный отчёт, отдельная обработка.
Как проверить на демо/пилоте:
попросить реализовать один и тот же список/отчёт с 3 контекстами:
(1) для бухгалтера, (2) для менеджера, (3) для руководителя — с разными фильтрами и колонками,
но с одним источником правила. Затем попросить изменить правило (добавить исключение)
и посмотреть, меняют ли это в одном месте или в нескольких копиях.
3. Запросный слой и работа с данными
Этот раздел — про то, насколько запросы являются управляемой частью архитектуры ERP.
Здесь становится видно, можно ли выражать бизнес-логику декларативно
и предсказуемо менять её стоимость,
или же любые изменения превращаются в риск по производительности и регрессу.
3.1 Запросы как самостоятельный слой системы
Как это обычно реализовано в стандартных ERP
В большинстве ERP запросы предназначены для чтения данных и отчётности.
Бизнес-правила (валидации, расчёты, ограничения)
реализуются в прикладной логике:
в коде объектов, обработчиках, workflow и автоматизациях.
Запросный слой не считается источником истины для правил.
1С
Запросы активно используются в отчётах и аналитике (СКД),
но проведение документов и контроль выполняются в коде.
Один и тот же показатель часто считается:
один раз в запросе, второй — в обработчике.
SAP
Расчёты распределяются между CDS View, ABAP-кодом и настройками.
Эти уровни мощные, но не образуют единого языка правил.
Microsoft Dynamics
Views и FetchXML — для чтения,
бизнес-правила — в плагинах, flows и клиентских скриптах.
Запрос не является носителем логики.
Odoo
ORM-запросы используются для выборок,
а логика реализуется в Python-коде и computed fields.
Эксплуатационный симптом:
невозможно однозначно ответить,
где именно считается показатель и какая версия формулы «главная».
Как проверить:
попросить показать все места,
где используется один и тот же расчёт,
и как обеспечивается их идентичность.
3.2 Запросы в строках
Как это обычно реализовано в стандартных ERP
Запросы и условия часто задаются в виде строк:
текст SQL, выражения фильтров, формулы в настройках.
Платформа не может анализировать их структуру
и проверять влияние изменений.
1С
Запросы — строковые.
Ошибки и зависимости выявляются только в рантайме.
SAP
В стандартных слоях контроль выше,
но кастом и интеграции быстро приводят к текстовым конструкциям.
Microsoft Dynamics
Условия и выражения в flows и настройках
формально no-code, но по сути строковые.
Odoo
Raw SQL решает задачи,
но ломает анализ зависимостей и обновления.
Эксплуатационный симптом:
изменение схемы данных приводит к ошибкам «постфактум»,
появляется правило «лучше не трогать».
3.3 Отсутствие предсказуемой оптимизации как части модели правил
Как это обычно реализовано в стандартных ERP
Производительность запросов не выводится из модели правил.
Она достигается за счёт ручной оптимизации,
индексов и опыта разработчиков.
1С
Запрос может быть логически корректным,
но физически неэффективным.
SAP
Сильная СУБД помогает,
но сложные модели дают неожиданные планы выполнения.
Microsoft Dynamics
Сложную аналитику часто выносят в BI,
а не оптимизируют внутри ERP.
Odoo
ORM скрывает реальные планы выполнения,
оптимизация становится «искусством».
Эксплуатационный симптом:
отчёты «летят» на тесте и деградируют на реальных данных.
3.4 Отсутствие расширенных SQL-возможностей
Как это обычно реализовано в стандартных ERP
Поддержка оконных функций, CTE и условных агрегатов
либо ограничена, либо требует обходов.
В итоге расчёты распадаются на несколько шагов и код.
Эксплуатационный симптом:
одинаковые формулы дублируются,
сложно понять, где именно считается показатель.
Как проверить:
попросить показать сложный управленческий расчёт
без циклов и временных таблиц.
3.5 Отсутствие запросов на изменение (UPDATE / DELETE / MERGE)
Как это обычно реализовано в стандартных ERP
Массовые изменения данных
не считаются штатной частью языка запросов.
Используются циклы, обработки или внешние инструменты.
1С
Массовые изменения = перебор объектов и перепроведение.
SAP
Массовые операции возможны,
но требуют высокой квалификации и осторожности.
Microsoft Dynamics
Массовые изменения часто выносятся в ETL и Dataflows.
Odoo
ORM медленный для массовых операций,
raw SQL рискован по поддержке.
Эксплуатационный симптом:
пересчёты выполняются ночью,
считаются опасными и редкими.
4. Поток выполнения и гарантии консистентности данных
Этот раздел — про гарантии, а не про удобство.
Про то, можно ли формально определить момент завершения операции,
источник истины и порядок применения бизнес-правил.
Именно отсутствие формальных гарантий приводит к ошибкам,
которые «невозможно воспроизвести» и подрывают доверие к данным.
4.1 Отказ от автоматических блокировок
Суть ограничения
Многие ERP жертвуют строгими блокировками ради отзывчивости интерфейса.
В результате платформа не гарантирует атомарность бизнес-операции:
несколько пользователей или процессов могут изменить связанные данные
без единой точки синхронизации.
Гарантия, которой нет
Нет формального утверждения:
«в момент X данные были согласованы и не могли измениться конкурентно».
Эксплуатационный симптом:
редкие, нерегулярные ошибки,
которые невозможно стабильно воспроизвести;
объяснение сводится к «одновременным действиям».
Как проверить:
попросить показать,
что происходит при одновременном изменении
одного и того же объекта несколькими пользователями
и где именно фиксируется конфликт.
4.2 Отказ от единого потока выполнения
Суть ограничения
Бизнес-логика распределяется между клиентом,
сервером, фоновыми процессами и интеграциями.
В системе отсутствует единый детерминированный поток выполнения.
Гарантия, которой нет
Нельзя формально ответить:
«какие проверки и расчёты были применены именно к этой операции».
Эксплуатационный симптом:
пользователь видит одно поведение,
а итоговое состояние данных отличается;
возникают «непонятные» отказы и откаты.
Как проверить:
попросить показать,
какие проверки выполняются гарантированно на сервере,
какие — только в UI,
и что произойдёт при обходе интерфейса.
4.3 Отказ от синхронности и чёткого commit point
Суть ограничения
Ради скорости операции выполняются асинхронно:
расчёты, интеграции, пересчёты показателей.
Пользователь получает подтверждение,
но бизнес-операция ещё не завершена логически.
Гарантия, которой нет
Отсутствует чёткий commit point —
момент, после которого можно утверждать,
что операция завершена и её эффект окончателен.
Эксплуатационный симптом:
дубли операций,
«отложенные ошибки»,
ручные проверки и повторные действия пользователей.
Как проверить:
спросить,
в какой момент операция считается завершённой,
какие действия выполняются после подтверждения
и возможны ли откаты задним числом.
Этот раздел — про то, как пользователь взаимодействует с моделью данных
и какие архитектурные последствия возникают,
когда интерфейс перестаёт быть прямым отражением бизнес-логики.
Здесь ошибки выглядят как «человеческий фактор»,
но их причина — в устройстве системы.
5.1 Формы как отдельный слой логики
Как это обычно реализовано в стандартных ERP
Формы в ERP редко являются просто отображением данных.
В них добавляется логика:
проверки, вычисления, скрытие полей,
автозаполнение, реакции на события.
Со временем форма становится ещё одним местом,
где живут бизнес-правила.
1С
Значительная часть логики реализуется в модулях форм:
проверки при изменении полей,
пересчёты, управление доступностью.
Эта логика не всегда дублируется на сервере.
SAP
UI-логика распределяется между экранными сценариями,
backend-проверками и процессными правилами.
Microsoft Dynamics
Клиентские скрипты и бизнес-правила в интерфейсе
дополняют серверные плагины,
создавая несколько уровней поведения.
Odoo
Формы относительно просты,
но при кастомизации логика начинает дублировать backend.
Эксплуатационный симптом:
поведение зависит от того,
как именно пользователь вводит данные,
через какую форму или сценарий.
Как проверить:
попросить показать,
какие проверки выполняются только в форме
и что произойдёт при загрузке данных в обход UI.
5.2 Отказ от WYSIWYG: разделение интерфейса на запись и чтение
Как это обычно реализовано в стандартных ERP
Режимы просмотра и редактирования
реализуются по-разному:
разные события, разные проверки,
разные вычисления.
Пользователь видит одно,
а система сохраняет другое.
1С
Разные режимы формы и события
приводят к расхождениям
между отображением и сохранением.
SAP
Многошаговые экраны и статусы
усложняют понимание,
что именно зафиксировано.
Microsoft Dynamics
Часть полей вычисляется или обновляется асинхронно,
что создаёт эффект «визуальной фиксации».
Odoo
Базово WYSIWYG соблюдён,
но при усложнении форм появляются расхождения.
Эксплуатационный симптом:
пользователь уверен, что данные сохранены,
но система позже их меняет или откатывает.
Как проверить:
попросить показать,
совпадает ли значение поля на экране
с тем, что реально записано в базе
в момент сохранения.
5.3 Невозможность обращаться в списках к реквизитам форм и текущим значениям других списков
Как это обычно реализовано в стандартных ERP
Списки и формы живут в разных контекстах.
Логика списка ограничена доступными полями данных,
а текущие значения формы или других списков
недоступны напрямую.
Следствие
Контекстные правила (зависящие от текущего выбора,
состояния формы, связанных списков)
реализуются обходными путями или дублируются.
Эксплуатационный симптом:
интерфейс не может корректно отразить
реальные ограничения и правила,
появляются «непонятные» запреты.
Как проверить:
попросить реализовать правило,
зависящее от состояния нескольких списков,
без дополнительного кода и обходов.
5.4 Избыточные уровни абстракции в UI
Как это обычно реализовано в стандартных ERP
Для универсальности и расширяемости
интерфейс строится через несколько уровней:
метаданные → формы → конфигурации → сценарии.
Каждый уровень добавляет гибкость,
но снижает прозрачность.
Эксплуатационный симптом:
простое изменение поведения формы
требует понимания нескольких уровней абстракции
и затрагивает больше мест, чем ожидается.
Как проверить:
попросить показать,
через какие слои проходит изменение
одного UI-правила
и где именно оно зафиксировано.
6. Архитектура языка и расширяемость
Этот раздел — про то, насколько ERP вообще является инженерной платформой,
а не набором инструментов для конфигурации.
Здесь определяется, можно ли развивать систему как кодовую базу
с предсказуемыми изменениями,
или она неизбежно превращается в артефакт внедрения,
зависящий от конкретных людей и договорённостей.
6.1 Отсутствие наследования и полиморфизма
Как это обычно реализовано в стандартных ERP
ERP почти всегда работает с семействами сущностей:
договоры, заказы, услуги, проекты.
Однако во многих платформах
нет полноценной модели наследования бизнес-сущностей.
В результате схожая логика копируется,
а различия реализуются через условия.
1С
Наследование ограничено.
Типовой подход — копирование объектов
с последующими доработками.
SAP
Возможности шире,
но сложность модели приводит к тому,
что логика базовых и производных сущностей
расходится по расширениям.
Microsoft Dynamics
Расширение сущностей возможно,
но полиморфизм чаще имитируется
через плагины и условия.
Odoo
Наследование — сильная сторона,
но при активных override'ах
важно контролировать точки изменения поведения.
Эксплуатационный симптом:
правила дублируются,
изменения в «базовой логике»
требуют ручной синхронизации.
6.2 Отсутствие явной типизации в коде
Как это обычно реализовано в стандартных ERP
Явная типизация часто отсутствует
или ослаблена ради гибкости.
Ошибки выявляются в рантайме,
а анализ логики возможен
только опытным путём.
1С
Слабая типизация затрудняет анализ
больших конфигураций
и безопасный рефакторинг.
SAP
Типизация сильнее,
но цена — высокая сложность
и требования к квалификации команды.
Microsoft Dynamics
Типы есть,
но при смешении low-code и плагинов
контракт поведения размывается.
Odoo
Динамический Python
требует строгих соглашений,
иначе ошибки проявляются поздно.
Эксплуатационный симптом:
изменения проверяются «на глаз»,
растёт число регрессионных ошибок.
6.3 Отсутствие модульности
Как это обычно реализовано в стандартных ERP
Формальное разделение на модули
не гарантирует архитектурной изоляции.
Зависимости становятся неявными,
а изменение одного блока
затрагивает смежные.
1С
Общие модули разрастаются,
границы ответственности размываются.
SAP
Модульность есть на уровне процессов,
но настройки и расширения
размывают границы.
Microsoft Dynamics
Композиционность работает
до определённого масштаба,
затем локальность изменений теряется.
Odoo
Модульность изначально сильная,
но слабый контроль зависимостей
превращает обновления в проект.
Эксплуатационный симптом:
«маленькие» изменения
перестают быть маленькими,
растёт объём регресса.
6.4 Ставка на визуальное программирование
Как это обычно реализовано в стандартных ERP
Low-code и визуальные схемы
ускоряют старт,
но плохо масштабируются
как носитель бизнес-логики.
Зависимости трудно анализировать,
правила сложно тестировать.
1С
Визуальные механизмы
смешиваются с кодом,
логика распыляется.
SAP
Workflow и настройки мощные,
но трассировка «почему сработало»
становится нетривиальной.
Microsoft Dynamics
Flows удобны,
но при росте превращаются
в трудноуправляемый набор сценариев.
Odoo
Визуальные инструменты менее агрессивны,
но перенос логики из кода в настройки
даёт те же эффекты.
Эксплуатационный симптом:
правила существуют как «схемы»,
а не как единая модель,
сопровождение зависит от конкретных людей.
7. Физическая модель и открытость системы
Этот раздел — про то, насколько ERP прозрачна как инженерная система.
Даже при аккуратной логике, хороших формах и дисциплине разработки
закрытая или негибкая физическая модель данных
резко увеличивает стоимость изменений, диагностики и интеграций.
Здесь появляются ограничения, которые невозможно «обойти аккуратным кодом» —
они определяются самим устройством платформы.
7.1 Закрытая физическая модель данных
Как это обычно реализовано в стандартных ERP
Во многих ERP физическая модель данных либо скрыта,
либо доступна только через абстракции платформы.
Разработчик работает с логической моделью,
не имея полного контроля над тем,
как данные реально хранятся и связаны.
1С
Физическая структура БД формируется платформой.
Прямой анализ и оптимизация возможны,
но не считаются штатным способом работы.
SAP
Модель данных формально открыта,
но чрезвычайно сложна.
Без глубокой экспертизы вмешательство рискованно.
Microsoft Dynamics
В SaaS-модели физическая БД скрыта.
Работа ведётся через Dataverse, API и витрины.
Odoo
Физическая модель доступна,
но модули и кастомизация
быстро усложняют реальную картину.
Эксплуатационный симптом:
диагностика проблем и анализ последствий изменений
требуют специальных знаний или доступа,
который есть не у команды, а у вендора или интегратора.
Как проверить:
спросить,
можно ли без обходных путей
проанализировать реальные таблицы,
индексы и связи для конкретного расчёта.
7.2 Статичная физическая модель данных
Как это обычно реализовано в стандартных ERP
Физическая модель оптимизирована под типовые сценарии.
Изменение структуры данных
либо невозможно,
либо требует сложных миграций и согласований.
1С
Изменения структуры возможны,
но на больших объёмах данных
превращаются в отдельные проекты.
SAP
Изменения допустимы,
но затрагивают множество зависимых объектов
и требуют строгой процедуры.
Microsoft Dynamics
Расширение схемы возможно,
но в рамках ограничений SaaS-платформы.
Odoo
Модель можно менять,
но это влияет на обновляемость и совместимость модулей.
Эксплуатационный симптом:
изменение модели данных откладывается,
накапливаются «временные» решения и дополнительные таблицы.
Как проверить:
попросить показать,
как добавляется новое измерение или сущность
с учётом исторических данных.
7.3 Закрытые исходники и лицензии
Как это обычно реализовано в стандартных ERP
Исходный код и внутренние механизмы
частично или полностью закрыты.
Возможности анализа и изменения
ограничены условиями лицензии.
1С
Платформа закрыта,
поведение многих механизмов нельзя изучить напрямую.
SAP
Код доступен ограниченно,
изменения требуют соблюдения строгих правил.
Microsoft Dynamics
SaaS-модель усиливает зависимость от вендора
и ограничивает низкоуровневый контроль.
Odoo
Open-source ядро снижает барьер,
но коммерческие модули и экосистема
могут создавать новый lock-in.
Эксплуатационный симптом:
команда не может самостоятельно разобраться
в причинах поведения системы
и вынуждена полагаться на поддержку или партнёров.
Как проверить:
спросить,
какие части системы можно анализировать,
отлаживать и менять без участия вендора.
8. Эксплуатационные и культурные ограничения
Этот раздел — про ограничения, которые формально не относятся к архитектуре,
но на практике определяют, какой архитектурой система может быть.
Лицензирование, правила использования и позиция вендора
напрямую влияют на тестирование, автоматизацию,
скорость изменений и зависимость от внешних участников.
8.1 Неуважительные по отношению к разработчикам лицензирование и брендирование
Как это обычно реализовано в стандартных ERP
Лицензирование часто строится вокруг пользователей,
окружений и отдельных компонентов.
Это ограничивает количество тестовых стендов,
усложняет CI/CD и делает эксперименты дорогими.
Брендирование и жёсткие правила использования
подчёркивают зависимость от вендора.
1С
Лицензии на пользователей и серверы
ограничивают количество полноценных контуров.
Часто существует один «живой» стенд,
где и тестируют изменения.
SAP
Стоимость лицензий и окружений
делает каждый дополнительный стенд предметом согласования.
Автоматизация тестирования ограничена.
Microsoft Dynamics
SaaS-лицензирование ограничивает доступ
к низкоуровневым механизмам
и усложняет изоляцию экспериментов.
Odoo
Open-source снижает барьер входа,
но коммерческие модули и сервисы
могут накладывать схожие ограничения.
Эксплуатационный симптом:
меньше тестовых контуров,
правки проверяются «на проде»,
изменения выкатываются реже и осторожнее,
чем требует бизнес.
Как проверить:
спросить,
сколько полноценных окружений
можно держать без дополнительных лицензий
и какие из них подходят для автоматических тестов.
8.2 Фатальный недостаток как сумма архитектурных решений
Ни одно из описанных ограничений
не является фатальным само по себе.
Проблема возникает,
когда они накладываются друг на друга.
- правила размазаны по объектам, формам и запросам;
- запросный слой не является источником истины;
- нет чётких гарантий потока выполнения;
- модель данных закрыта или негибка;
- эксперименты и тестирование дороги.
В такой системе любое изменение —
даже логически простое —
превращается в проект:
с анализом последствий,
ручным регрессом
и зависимостью от конкретных людей.
Эксплуатационный симптом:
команда избегает изменений,
бизнес перестаёт задавать вопросы «а можно ли иначе»,
ERP фиксирует текущий способ работы
вместо того, чтобы поддерживать развитие.
9. Как проверять архитектурные ограничения на демо и пилоте
Архитектурные ограничения почти никогда не видны
в презентациях и типовых сценариях.
На демо показывают «что система умеет»,
но не «сколько стоит изменение правил».
Единственный надёжный способ —
проверять ERP не по функциям,
а по реакции на изменения.
9.1 Три изменения, которые стоит попросить показать
Для проверки достаточно трёх сценариев.
Важно не то, что «получилось»,
а как именно это делалось.
-
Изменение правила с исключениями
Например: скидка или лимит,
зависящие от нескольких условий
(тип клиента, оборот, риск, история).
-
Изменение процесса
Согласование не «по должности»,
а по данным:
сумма, маржа, риск, отклонение от нормы.
-
Добавление нового типа сущности
Новый договор, услуга или модель расчёта,
которая должна:
участвовать в транзакциях,
попадать в отчёты
и подчиняться тем же правилам контроля.
Эти сценарии затрагивают:
модель данных,
расчёты,
формы,
запросы,
контроль и интеграции —
именно там и проявляются ограничения.
9.2 На что смотреть во время демонстрации
-
Сколько слоёв пришлось менять
Один модуль или форма —
это изменение правила.
Несколько слоёв —
изменение системы.
-
Где именно описано правило
Можно ли показать одно место,
или логика распределена
между кодом, формами и запросами.
-
Как объясняется влияние на отчёты
Есть ли чёткий ответ,
какие показатели изменятся
и почему.
-
Есть ли проверка регресса
Тест, сценарий или хотя бы формальный чек-лист,
а не «после посмотрим».
9.3 Типовые «красные флаги»
- «Это лучше делать после внедрения»
- «В реальном проекте мы бы сделали иначе»
- «Здесь много нюансов, на демо не показать»
- «Это делается, но нужен отдельный проект»
- «Нужно посмотреть, как это повлияет на отчёты»
Эти фразы не означают,
что система плохая.
Они означают,
что стоимость изменений
пока неизвестна и неконтролируема.
9.4 Что считать хорошим результатом пилота
Хороший результат —
не «мы всё сделали»,
а следующее:
- правило описано в одном месте или одном типе механизма;
- видно, какие данные и расчёты оно затрагивает;
- понятно, как проверить регресс;
- изменение не требует «особого знания» конкретного человека.
Если после пилота можно ответить на вопрос
«сколько стоит следующее изменение»,
значит архитектура поддаётся управлению.
10. Заключение
Этот разбор не про «хорошие» и «плохие» ERP.
1С, SAP, Microsoft Dynamics и Odoo успешно работают в тысячах компаний.
Проблемы начинаются не на этапе внедрения,
а в момент, когда бизнес начинает менять правила.
Архитектурные ограничения редко выглядят критичными по отдельности.
Они накапливаются:
через дополнительные проверки,
частные доработки,
исключения и временные обходы.
Со временем именно они определяют реальную стоимость изменений.
Ключевой вывод:
дорогими становятся не сложные правила, а плохо формализованные.
Когда логика распылена между объектами, формами, запросами,
визуальными сценариями и интеграциями,
система перестаёт быть управляемой как единое целое.
В такой архитектуре возникает практический lock-in —
не столько от вендора,
сколько от конкретных людей,
которые «помнят, как всё работает».
Часто ожидается, что AI или low-code решат эту проблему.
На практике происходит обратное:
AI лишь ускоряет работу с уже существующим хаосом,
если правила не описаны формально и однозначно.
AI становится реальным активом только тогда,
когда бизнес-логика выражена
в структурированном, типизированном и логичном языке,
подкреплённом документацией.
В этом случае внутренняя команда может использовать AI
для анализа правил, генерации процессов,
оценки последствий изменений и сопровождения системы —
без постоянной зависимости от вендора или отдельных специалистов.
Итог
Устойчивая ERP — это не та, где «всё можно настроить»,
а та, где стоимость следующего изменения
можно объяснить, проверить и спрогнозировать заранее.
Источники и ссылки
Похожие статьи
Продолжить чтение:
Если важны практические последствия архитектуры ERP и снижение зависимости от подрядчиков —
вот ещё материалы на DevLab Blog: