ERP That Doesn’t Turn Into an Expensive Brake
Why ERP systems break in the same ways: architectural limitations of 1C, SAP, Microsoft Dynamics, Odoo and other ERP platforms — and how they behave when business rules change.
Based on technical articles on Habr: “Why lsFusion and not 1C?” and “Why not 1C?” . Then — an engineering “decode”: mechanisms, symptoms, pilot diagnostics, and ways to reduce risk.
1.1 Why ERP architectural limitations show up in the same way
Most ERPs (1C, SAP, Microsoft Dynamics, Odoo) look stable at the start: little data, simplified processes, rare exceptions, “thin” integrations. Architectural limitations are almost invisible at this point.
Problems appear later — when a company starts changing the rules. The reason is not a “bad system”, but the fact that typical ERPs are built around similar trade-offs: an object model, a separate reporting layer, split logic (form/server/integrations), plus limitations of the query layer and mass operations. As data volume and exceptions grow, these trade-offs produce the same symptoms regardless of the vendor.
This material does not answer “which ERP is better”. It answers a different question: where and why changing rules becomes expensive, and how to spot it before going live.
1.2 What counts as a “rule change”, not a customization
A “rule change” is not “add a field” and not “build a new report”. It’s a change that simultaneously:
- changes transaction behavior (validations, posting, statuses, constraints);
- changes metrics (margin, cost, limits, stock, risk);
- changes control (locks, approvals, condition-based prohibitions);
- must not break reporting and integrations (CRM/WMS/marketplaces/BI).
If the platform can’t hold this as a single model (data + calculations + control), the rule will inevitably be implemented in multiple places. Then the cost of change is driven not by the formula complexity, but by the number of layers that must be changed and verified in sync.
1.3 How to read this breakdown and what it gives you in practice
Next come specific architectural points (objects, registers, queries, forms, locks, typing, etc.). For each point we use the same format:
- What it means — the limitation without vague wording;
- How it shows up in 1C / SAP / Dynamics / Odoo (typical mechanisms, not “it’s hard in general”);
- What symptom you’ll see in operations (what actually hurts);
- How to test on a demo/pilot — a question or scenario that exposes the problem.
After this breakdown you’ll quickly distinguish: “editing a rule” (predictable work in one place) from “editing the system” (multi-layer changes with expensive regression), and you’ll understand in advance where dependency on the vendor or a few specialists appears.
-
One rule — one place?
Ask them to show where a specific rule lives (e.g., limit/margin/stock) and how many layers it touches. If it’s code + form + report + batch job — changes will be expensive. -
Is there a “completion moment” for an operation?
Ask when an operation is considered final (commit point) and what happens asynchronously after “success”. If the answer is fuzzy — expect “delayed errors” and manual checks. -
Exception handling check
Add 2–3 exceptions to a standard flow. If “special-case handlers” appear immediately — the model can’t hold variability. -
Is regression under control?
Ask how they verify that a rule change didn’t break reports/integrations. If it’s “we’ll eyeball it” — it will hurt. -
Can you predict the cost of the next change?
Good architecture lets you say in advance: “this change affects N mechanisms and is verified by these tests.” Bad architecture turns every change into an investigation.
2. Data and computation model
This section is about the foundation: how data and computations are built in an ERP and what limitations are baked in even before code, forms, and integrations. This is where it’s decided whether business rules can be expressed as a single model or whether they will inevitably spread across the system.
2.1 Objects: catalogs, documents, etc.
How it’s usually implemented in ERPs
Most ERPs are built around an object model: catalogs, documents, lines, movements. Business logic is tied to the object lifecycle (create, edit, post), rather than described as a separate rule system.
1C
Metadata (Catalogs, Documents, Registers) is the core architecture. Checks and calculations are spread across posting, form modules, and service handlers.
SAP
The object model is complemented with configuration and extensions, but a rule often becomes a composition of a standard object, custom code, and a process layer.
Microsoft Dynamics
Entities are the entry point, but logic is spread across plugins, automations, and client-side rules.
Odoo
ORM models look cohesive, but as customization grows, logic spreads across models, computed fields, and modules.
Operational symptom: one business rule is implemented across multiple objects and layers; explaining “why the system calculated it this way” requires knowing the implementation history.
How to test: ask them to show one rule and all objects where it is implemented or affects behavior.
2.2 Inefficient retrieval of object data
How it’s usually implemented in ERPs
Objects are convenient for transactions, but poor for complex computations. As a result, data is fetched partly by queries, partly through objects, and the calculation is assembled procedurally.
1C
Typical scenario: query + object reads + loops. Performance depends on developer discipline.
SAP
Data is available through multiple model layers, which complicates control over the actual fetches.
Dynamics
ORM/API can easily generate many calls instead of a single optimal query.
Odoo
The ORM hides real SQL; issues appear as data grows.
Operational symptom: performance degrades not gradually, but “suddenly” — once volume crosses a threshold.
2.3 Tables and views: registers
How it’s usually implemented in ERPs
For analytics, a separate layer is introduced: aggregates, movements, views. A second source of truth appears, different from transactional data.
1C
Registers are a key mechanism, but calculation logic often partly remains in code.
SAP
An analog is a mix of movements, aggregates, and analytical views.
Dynamics
Aggregates are often moved to BI or data marts.
Odoo
There are typical aggregates, but as requirements grow, SQL views and external analytics appear.
Operational symptom: operations and reports diverge, recalculations require special procedures.
2.4 Registers are supported only in very specific cases
What it means
The analytical layer (registers/aggregates/marts) works well as long as a business rule fits a “standard” pattern: stock balances, turnovers, simple dimensions, standard periods. Once non-standard semantics appear (exceptions, conditional rules, alternative sources, historical “as of date” by a non-standard attribute), part of the logic can no longer be expressed in the model and moves into code/batch jobs/integrations.
How it shows up in standard ERPs
1C
Registers (accumulation/accounting/information) cover many scenarios, but real logic often splits: part in posting movements, part in report queries (DCS), part in recalculation jobs. As soon as you need a “non-standard” algorithm (conditional recalcs, complex exceptions, alternative valuation), it moves into procedural code and stops being part of a single model.
SAP
Standard accounting and analytics rely on a rich model and extension mechanisms, but “non-standard” is often implemented as a mix of configuration + extensions + a separate analytics model (or moved into a separate analytics layer). The rule ends up living in several places, and synchronization becomes its own project.
Microsoft Dynamics
In a typical landscape, metrics are often spread across layers: transactional entities, rules/plugins, reporting views, and external analytics. Non-standard rules almost inevitably become a combination: code + low-code automations + mart/BI.
Odoo
Basic aggregates and computed fields work up to a certain complexity. After that you see: separate models for derived metrics, SQL views, background recalculations, and external analytics. The rule stops being “part of the model” and turns into a set of implementations.
Operational symptom: part of the rules live in the “model” (registers/aggregates), part in “special-case jobs”. A small change starts requiring edits in multiple places, and explainability (“why did it calculate like this?”) drops.
How to test on a demo/pilot: take one metric (e.g., available stock/margin/limit) and add 2–3 exceptions (by customer type, warehouse, date, alternative price source). See whether a single mechanism is preserved (one place/one mechanism type) or whether the rule “spreads” into code + report + recalculation + integration.
2.5 No constraints and events for register values
What it means
In many ERPs, constraints and events are well-defined for operations (document/posting/write), but poorly defined for computed/aggregated values (balances, limits, ratings, risk). In other words, the platform doesn’t provide a native model-level mechanism like: “if the aggregate becomes X — block/notify/trigger a reaction” as part of the model. So control is implemented procedurally: checks during posting, background checks, validator reports, and manual procedures.
How it shows up in standard ERPs
1C
A typical approach is “check locally” during document posting or in the form. But an aggregate (e.g., limit/stock/turnover) can change not only from one document: from multiple operation types, retro-changes, recalculations, exchanges. Then control starts duplicating, and “when exactly the restriction triggers” depends on the scenario.
SAP
Control is often built via statuses/processes/transaction checks, while aggregate monitoring uses separate mechanisms (control procedures, reports, workflow). Formally it’s powerful, but the rule often becomes a process construct, not a declarative constraint on a value.
Microsoft Dynamics
Business rules and plugins are easy to attach to entity-change events, but aggregates are usually computed elsewhere (background, integration, reporting layer). So a “constraint on an aggregate” becomes a set of checks + automations, and it’s hard to make it provably complete (without holes).
Odoo
There are constraints and onchange at the model level, but aggregates often live in computed fields, which can be recomputed lazily/by triggers/by cron. That makes aggregate-based control easily non-deterministic (“sometimes it catches it, sometimes it doesn’t”) unless strict discipline is enforced.
Operational symptom: restrictions and control don’t work “the same way every time”: one user hits a constraint immediately, another only later; some violations are discovered by a report/check after the fact. Procedures like “please check manually” appear.
How to test on a demo/pilot: ask them to implement an aggregate constraint: “you may not ship if total risk/credit limit for the customer > X, considering all documents and adjustments.” Then ask them to show 3 ways the aggregate changes (document, backdated correction, integration/import) and verify the constraint triggers identically in all three scenarios.
2.6 Only constants can be used in virtual table parameters
What it means
When the analytical layer can only be parameterized by constants (or very narrowly), the system can’t “adapt” computation to the operation context. As a result you have to: (1) fetch data “wider than needed” and then filter in code/form, (2) create copies of queries/reports for different variants, (3) move part of the logic out of the model into procedural layers. This quietly raises change cost: every new condition spawns new copies.
How it shows up in standard ERPs
1C
Typical effect: a report/query is “universal” only in words. Once context-dependent conditions appear (current user, role, document state, form parameters), part of filtering moves into code, and queries get copied. Over time, you get a “zoo” of nearly identical reports/selection variants.
SAP
Context conditions are often handled via configuration, view parameters, and process layers, but as variability grows you get the same pattern: multiple variants of views/queries/roles instead of one described rule. The cost is maintenance complexity and logic divergence risk.
Microsoft Dynamics
Expression/context limitations lead to proliferation of views/queries/flows: “one for this role”, “another for this form”. When business changes the rule, you have to find all copies and update them in sync.
Odoo
The ORM is convenient, but complex context often leads to: UI-level domains/contexts + separate fetch methods in code + SQL for heavy cases. Filter variability quickly produces duplication and “local fixes”.
Operational symptom: “almost identical” reports, lists, and selections appear. A small condition change (one more filter/exception) turns into a series of edits: query, form code, permissions, a separate report, a separate batch job.
How to test on a demo/pilot: ask them to implement the same list/report with 3 contexts: (1) accountant, (2) manager, (3) executive — different filters and columns, but a single rule source. Then ask to change the rule (add an exception) and see whether it’s changed in one place or across multiple copies.
3. Query layer and working with data
This section is about whether queries are a managed part of ERP architecture. Here you can see whether business logic can be expressed declaratively and its cost changed predictably, or whether any change becomes a performance/regression risk.
3.1 Queries as an independent system layer
How it’s usually implemented in standard ERPs
In most ERPs, queries are for reading data and reporting. Business rules (validations, calculations, constraints) are implemented in application logic: in object code, handlers, workflows, and automations. The query layer is not treated as the source of truth for rules.
1C
Queries are heavily used in reports and analytics (DCS), but posting and control are done in code. The same metric is often calculated twice: once in a query, and again in a handler.
SAP
Calculations are split across CDS Views, ABAP code, and configuration. These layers are powerful, but don’t form a single rule language.
Microsoft Dynamics
Views and FetchXML are for reading, business rules live in plugins, flows, and client scripts. The query is not the carrier of logic.
Odoo
ORM queries are used for selections, while logic lives in Python code and computed fields.
Operational symptom: you can’t answer unambiguously where a metric is calculated and which formula version is “the main one”.
How to test: ask them to show all places where the same calculation is used, and how identity between them is enforced.
3.2 Queries as strings
How it’s usually implemented in standard ERPs
Queries and conditions are often defined as strings: SQL text, filter expressions, formulas in settings. The platform can’t analyze their structure and verify change impact.
1C
Queries are string-based. Errors and dependencies show up only at runtime.
SAP
Control is higher in standard layers, but custom code and integrations quickly lead to textual constructs.
Microsoft Dynamics
Conditions and expressions in flows and settings are formally no-code, but essentially string-based.
Odoo
Raw SQL can solve tasks, but breaks dependency analysis and upgrades.
Operational symptom: schema changes lead to “after-the-fact” errors, and a rule appears: “better not touch it”.
3.3 Lack of predictable optimization as part of the rule model
How it’s usually implemented in standard ERPs
Query performance is not derived from the rule model. It is achieved via manual optimization, indexes, and developer experience.
1C
A query may be logically correct, but physically inefficient.
SAP
A strong DB helps, but complex models produce surprising execution plans.
Microsoft Dynamics
Complex analytics are often moved to BI instead of optimized inside the ERP.
Odoo
ORM hides real execution plans, and optimization becomes “an art”.
Operational symptom: reports fly on test data and degrade on real data.
3.4 Lack of advanced SQL features
How it’s usually implemented in standard ERPs
Support for window functions, CTEs, and conditional aggregates is either limited or requires workarounds. As a result, calculations split into multiple steps and code.
Operational symptom: the same formulas get duplicated, and it’s hard to understand where a metric is actually calculated.
How to test: ask them to show a complex management calculation without loops and temp tables.
3.5 No queries for changes (UPDATE / DELETE / MERGE)
How it’s usually implemented in standard ERPs
Mass data changes are not treated as a first-class part of the query language. Loops, batch jobs, or external tools are used instead.
1C
Mass changes = iterating objects and reposting.
SAP
Mass operations are possible, but require high expertise and caution.
Microsoft Dynamics
Mass changes are often moved into ETL and Dataflows.
Odoo
ORM is slow for mass ops, raw SQL is risky for maintainability.
Operational symptom: recalculations run at night, and are considered dangerous and rare.
4. Execution flow and data consistency guarantees
This section is about guarantees, not convenience. About whether you can formally define the completion moment of an operation, the source of truth, and the order business rules are applied. The lack of formal guarantees leads to errors that are “impossible to reproduce” and undermine trust in the data.
4.1 Dropping automatic locks
The essence of the limitation
Many ERPs sacrifice strict locking for UI responsiveness. As a result, the platform does not guarantee business-operation atomicity: multiple users or processes can change related data without a single synchronization point.
The missing guarantee
There is no formal statement: “at moment X, the data was consistent and could not be changed concurrently”.
Operational symptom: rare, irregular bugs that can’t be reproduced consistently; the explanation collapses into “simultaneous actions”.
How to test: ask them to show what happens when multiple users concurrently edit the same object, and where exactly the conflict is fixed.
4.2 Dropping a single execution flow
The essence of the limitation
Business logic is split across client, server, background processes, and integrations. The system lacks a single deterministic execution flow.
The missing guarantee
You can’t formally answer: “which checks and calculations were applied to this exact operation”.
Operational symptom: the user sees one behavior, but the final data state differs; “mysterious” failures and rollbacks appear.
How to test: ask them to show which checks are guaranteed on the server, which are only in the UI, and what happens if the UI is bypassed.
4.3 Dropping synchronicity and a clear commit point
The essence of the limitation
For speed, operations are performed asynchronously: calculations, integrations, metric recalculations. The user gets a confirmation, but the business operation is not yet logically complete.
The missing guarantee
There is no clear commit point — a moment after which you can state that the operation is complete and its effect is final.
Operational symptom: duplicate operations, “delayed errors”, manual checks and users repeating actions.
How to test: ask when an operation is considered complete, what runs after the confirmation, and whether backdated rollbacks are possible.
5. Forms and data presentation
This section is about how users interact with the data model and what architectural consequences appear when the UI stops being a direct reflection of business logic. Here issues look like “human error”, but the root cause is the system design.
5.1 Forms as a separate logic layer
How it’s usually implemented in standard ERPs
Forms in ERPs are rarely just data presentation. Logic is added: validations, computations, hiding fields, auto-fill, event reactions. Over time, a form becomes yet another place where business rules live.
1C
A significant share of logic is implemented in form modules: checks on field change, recalculations, availability control. This logic is not always duplicated on the server.
SAP
UI logic is split across screen scenarios, backend checks, and process rules.
Microsoft Dynamics
Client scripts and UI business rules complement server plugins, creating multiple behavior layers.
Odoo
Forms are relatively simple, but with customization logic begins to duplicate the backend.
Operational symptom: behavior depends on how the user enters data, via which form or scenario.
How to test: ask them to show which checks exist only in the form, and what happens when data is loaded bypassing the UI.
5.2 Moving away from WYSIWYG: separating UI into write and read
How it’s usually implemented in standard ERPs
View and edit modes are implemented differently: different events, different checks, different computations. The user sees one thing, but the system saves another.
1C
Different form modes and events lead to divergence between what’s displayed and what’s saved.
SAP
Multi-step screens and statuses make it harder to understand what is actually fixed.
Microsoft Dynamics
Some fields are computed or updated asynchronously, creating a “visual fixation” effect.
Odoo
WYSIWYG is mostly preserved by default, but as forms get more complex, mismatches appear.
Operational symptom: the user is sure the data is saved, but the system later changes it or rolls it back.
How to test: ask them to show whether the on-screen field value matches what is actually stored in the DB at the moment of save.
5.3 Inability to reference form attributes and current values of other lists inside lists
How it’s usually implemented in standard ERPs
Lists and forms live in different contexts. List logic is limited to available data fields, while current form values or other list states are not directly accessible.
Consequence
Contextual rules (depending on current selection, form state, related lists) are implemented via workarounds or duplicated.
Operational symptom: the UI can’t correctly reflect real constraints and rules, and “mysterious” prohibitions appear.
How to test: ask them to implement a rule depending on the state of multiple lists, without extra code and workarounds.
5.4 Excess abstraction layers in the UI
How it’s usually implemented in standard ERPs
For universality and extensibility, the UI is built through multiple layers: metadata → forms → configuration → scenarios. Each layer adds flexibility, but reduces transparency.
Operational symptom: a simple behavior change in a form requires understanding multiple abstraction layers and touches more places than expected.
How to test: ask them to show which layers are involved in changing one UI rule and where exactly it is defined.
6. Language architecture and extensibility
This section is about whether an ERP is an engineering platform at all, and not just a set of configuration tools. This determines whether you can evolve the system as a codebase with predictable changes, or whether it inevitably becomes an implementation artifact, dependent on specific people and agreements.
6.1 No inheritance and polymorphism
How it’s usually implemented in standard ERPs
ERPs almost always deal with entity families: contracts, orders, services, projects. Yet many platforms don’t have a full inheritance model for business entities. As a result, similar logic is copied, and differences are implemented via conditions.
1C
Inheritance is limited. The typical approach is copying objects with subsequent customization.
SAP
Capabilities are broader, but model complexity causes base and derived entity logic to split across extensions.
Microsoft Dynamics
Entity extension is possible, but polymorphism is more often simulated via plugins and conditions.
Odoo
Inheritance is a strength, but with heavy overrides you must control the behavior-change points.
Operational symptom: rules are duplicated, and changes to “base logic” require manual synchronization.
6.2 No explicit typing in code
How it’s usually implemented in standard ERPs
Explicit typing is often missing or weakened for flexibility. Errors are discovered at runtime, and logic analysis is possible only through experience.
1C
Weak typing makes it harder to analyze large configurations and refactor safely.
SAP
Typing is stronger, but the cost is higher complexity and stricter team skill requirements.
Microsoft Dynamics
Types exist, but mixing low-code and plugins blurs behavior contracts.
Odoo
Dynamic Python requires strict conventions, otherwise errors show up late.
Operational symptom: changes are validated “by eye”, and the number of regression bugs grows.
6.3 No real modularity
How it’s usually implemented in standard ERPs
Formal module separation doesn’t guarantee architectural isolation. Dependencies become implicit, and changing one block affects adjacent ones.
1C
Shared modules grow, responsibility boundaries blur.
SAP
Modularity exists at the process level, but configuration and extensions blur boundaries.
Microsoft Dynamics
Composition works up to a certain scale, then change locality is lost.
Odoo
Modularity is strong by design, but weak dependency control turns upgrades into a project.
Operational symptom: “small” changes stop being small, and regression scope grows.
6.4 Betting on visual programming
How it’s usually implemented in standard ERPs
Low-code and visual flows speed up the start, but scale poorly as business-logic carriers. Dependencies are hard to analyze, and rules are difficult to test.
1C
Visual mechanisms mix with code, and logic gets scattered.
SAP
Workflows and configuration are powerful, but tracing “why it triggered” becomes non-trivial.
Microsoft Dynamics
Flows are convenient, but as they grow they become a hard-to-manage set of scenarios.
Odoo
Visual tools are less aggressive, but moving logic from code into settings creates the same effects.
Operational symptom: rules exist as “schemes”, not as a single model, and maintenance depends on specific people.
7. Physical model and system openness
This section is about how transparent an ERP is as an engineering system. Even with careful logic, good forms, and disciplined development, a closed or inflexible physical data model sharply increases the cost of changes, diagnostics, and integrations.
Here you meet limitations that can’t be “worked around with careful code” — they are defined by the platform itself.
7.1 Closed physical data model
How it’s usually implemented in standard ERPs
In many ERPs, the physical data model is either hidden, or only accessible through platform abstractions. Developers work with the logical model without full control over how data is actually stored and linked.
1C
The physical DB structure is generated by the platform. Direct analysis and optimization are possible, but are not considered a standard way of working.
SAP
The data model is formally open, but extremely complex. Without deep expertise, intervention is risky.
Microsoft Dynamics
In SaaS, the physical DB is hidden. Work is done via Dataverse, APIs, and data marts.
Odoo
The physical model is accessible, but modules and customization quickly complicate the real picture.
Operational symptom: diagnosing issues and analyzing change impact require special knowledge or access held by the vendor or integrator rather than the team.
How to test: ask whether the real tables, indexes, and relationships for a specific calculation can be analyzed without workarounds.
7.2 Static physical data model
How it’s usually implemented in standard ERPs
The physical model is optimized for standard scenarios. Changing the data structure is either impossible or requires complex migrations and approvals.
1C
Structure changes are possible, but with large data volumes they become separate projects.
SAP
Changes are allowed, but affect many dependent objects and require strict procedures.
Microsoft Dynamics
Schema extension is possible, but within SaaS platform constraints.
Odoo
You can change the model, but it affects upgradability and module compatibility.
Operational symptom: data model changes get postponed, “temporary” solutions and extra tables accumulate.
How to test: ask them to show how a new dimension or entity is added while preserving historical data.
7.3 Closed source and licensing
How it’s usually implemented in standard ERPs
Source code and internal mechanisms are partially or fully closed. Analysis and change capabilities are limited by license terms.
1C
The platform is closed, and many mechanisms cannot be studied directly.
SAP
Code access is limited, and changes require strict compliance.
Microsoft Dynamics
The SaaS model increases vendor dependency and limits low-level control.
Odoo
An open-source core lowers the barrier, but commercial modules and the ecosystem can create a new lock-in.
Operational symptom: the team cannot figure out system behavior independently and must rely on support or partners.
How to test: ask which parts of the system can be analyzed, debugged, and changed without vendor involvement.
8. Operational and cultural constraints
This section is about limitations that formally aren’t “architecture”, but in practice define what architecture the system can have. Licensing, usage rules, and vendor posture directly affect testing, automation, change speed, and dependency on external parties.
8.1 Developer-hostile licensing and branding
How it’s usually implemented in standard ERPs
Licensing often revolves around users, environments, and separate components. This limits the number of test environments, complicates CI/CD, and makes experiments expensive. Branding and strict usage rules reinforce vendor dependency.
1C
Per-user and server licensing limits the number of full environments. Often there’s one “live” test stand where changes are tested.
SAP
The cost of licenses and environments makes every extra stand a subject of approvals. Test automation is constrained.
Microsoft Dynamics
SaaS licensing limits access to low-level mechanisms and makes experiment isolation harder.
Odoo
Open-source lowers entry barriers, but commercial modules and services can impose similar constraints.
Operational symptom: fewer test environments, changes tested “on prod”, releases happen less frequently and more cautiously than the business needs.
How to test: ask how many full environments can be maintained without extra licenses and which are suitable for automated tests.
8.2 A fatal flaw as the sum of architectural decisions
None of the limitations above is fatal on its own. The problem appears when they stack.
- rules are smeared across objects, forms, and queries;
- the query layer is not the source of truth;
- there are no clear execution-flow guarantees;
- the data model is closed or inflexible;
- experiments and testing are expensive.
In such a system, any change — even logically simple — becomes a project: with impact analysis, manual regression, and dependence on specific people.
Operational symptom: the team avoids changes, the business stops asking “can we do it differently?”, the ERP freezes the current way of working instead of supporting evolution.
9. How to test architectural limitations in a demo and pilot
Architectural limitations are almost never visible in presentations and standard scenarios. Demos show “what the system can do”, not “how much changing rules costs”.
The only reliable way — test an ERP not by features, but by its reaction to change.
9.1 Three changes you should ask them to show
Three scenarios are enough. What matters is not that it “worked”, but how exactly it was done.
-
A rule change with exceptions
For example: a discount or limit depending on multiple conditions (customer type, turnover, risk, history). -
A process change
Approval not “by job title”, but by data: amount, margin, risk, deviation from the norm. -
Adding a new entity type
A new contract, service, or calculation model that must: participate in transactions, appear in reports, and follow the same control rules.
These scenarios touch: data model, calculations, forms, queries, control, and integrations — exactly where limitations show up.
9.2 What to watch during the demo
-
How many layers had to change
One module or one form — that’s a rule change. Multiple layers — that’s a system change. -
Where the rule is described
Can they show one place, or is logic spread across code, forms, and queries? -
How impact on reports is explained
Is there a clear answer which metrics will change and why? -
Is there a regression check
A test, scenario, or at least a formal checklist — not “we’ll see later”.
9.3 Typical “red flags”
- “Better do this after implementation”
- “In a real project, we’d do it differently”
- “There are lots of nuances — can’t show on a demo”
- “It’s possible, but it’s a separate project”
- “We need to see how this will affect reports”
These phrases don’t mean the system is bad. They mean the cost of change is still unknown and uncontrolled.
9.4 What counts as a good pilot result
A good result is not “we implemented everything”, but this:
- the rule is described in one place or one mechanism type;
- it’s visible which data and calculations it touches;
- it’s clear how to check regression;
- the change doesn’t require “special knowledge” of a specific person.
If after the pilot you can answer “how much does the next change cost?”, the architecture is manageable.
10. Conclusion
This breakdown is not about “good” and “bad” ERPs. 1C, SAP, Microsoft Dynamics, and Odoo successfully run in thousands of companies. Problems start not during implementation, but at the moment the business begins to change the rules.
Architectural limitations rarely look critical in isolation. They accumulate: through extra checks, special-case customizations, exceptions, and temporary workarounds. Over time, they determine the real cost of change.
The key takeaway: what becomes expensive is not complex rules, but poorly formalized ones. When logic is scattered across objects, forms, queries, visual scenarios, and integrations, the system stops being manageable as a single whole.
In such an architecture, practical lock-in appears — not so much to the vendor, but to the specific people who “remember how it all works”.
In ERP contexts, AI is often understood too superficially — as a tool for hints, code generation, or speeding up individual tasks. But its real architectural effect shows up elsewhere.
AI becomes a strategic asset when the platform allows you to train a model on your own business logic, rather than using it merely as an external assistant.
If an ERP’s language and data model are structured enough, compact, and unambiguous, a company can train AI on its own code and rules — and then evolve the system with its internal team, without постоянной зависимости от вендора или узких специалистов.
For this, a platform needs several critical properties:
- High meaning density — business rules are expressed compactly, without excessive code.
- Declarativeness — rules describe “what should be”, not “how to execute it”.
- A single model — data, rules, and computations are expressed in one formalism.
- No “magic” — minimal implicit handlers, events, and exceptions.
In such a system, AI trains faster and more accurately: it doesn’t have to analyze thousands of lines of procedural code, scattered forms, string-based queries, and visual scenarios. The model sees the structure of rules, not the implementation history.
The practical consequence of this approach — a sharp drop in the “cost of owning knowledge”:
- fewer tokens and compute for training and maintaining models,
- higher accuracy in analyzing changes and impacts,
- less dependence on specific people and contractors,
- the ability to maintain and evolve the ERP with an internal team.
In the opposite case — when business logic is smeared across objects, forms, string-based queries, visual flows, and historical exceptions — AI does not become a strategic asset. It only speeds up work with a chaotic system, but doesn’t reduce its cost.
Architecture that is readable not only to humans but also to machines is not a “trend” or marketing. It’s a direct path to reducing vendor lock-in and ensuring the ERP evolves with the business, rather than requiring outside intervention every time.
Quick feedback
A quick signal helps us prioritize follow-ups.
Sources and links
Related posts
If you care about the practical consequences of ERP architecture and reducing dependency on contractors — here are more materials on DevLab Blog: