ERPs Need Maps of Work, Not Maps of Power
This article is in reference to:
Stop Modeling Your Org Chart in Your ERP
As seen on: cfcx.work
When “random” ERP failures aren’t random at all
The original post is aimed at a familiar kind of leadership discomfort: money and time leaking out of the business through an ERP that never quite behaves, without anyone being able to say why. Projects close, training is completed, dashboards look polished—yet everyday transactions still fail in ways that feel arbitrary and expensive.
The deeper claim is that this pain is not about bad users or bad software. It is the predictable cost of a core modeling mistake: encoding the org chart into the ERP and assuming that because the hierarchy looks tidy, the system will behave. As long as the digital model of the company is anchored to lines of authority instead of to where work is actually executed, leaders are quietly compounding design debt they never intended to take on.
Seen from that angle, the story is not about hunting down isolated errors at all. It is about changing the governing question from, “Who broke this step?” to, “What reality did we encode into this system, and does it match how we really run the business?”
Org charts vs. execution domains
At the center of the piece is a distinction most teams never make explicit: the difference between the org chart and the execution domain.
Org charts are built for legibility. They explain who reports to whom, how entities relate, how power and responsibility are distributed. They are a communication tool for humans, optimized for narrative and governance.
Execution domains are built for invariants. They define where work actually happens, where constraints apply, and where automation can safely assume certain rules will hold: a child-most subsidiary where transactions post, the specific warehouse where goods are stored, the legal entity that owns a ledger.
The article’s core “why” is to make leaders see that ERPs care about execution domains, not organizational aesthetics. When a team models locations, items, or vendors as if the org chart is the system boundary, they trade conceptual neatness for operational stability. It looks coherent on a slide; it behaves incoherently in production.
This is why the author fixates on examples like a location tied to the holding company instead of the operating subsidiary. It is a near-match that passes every casual human check but violates the execution boundary the ERP depends on. The system accepts it, then quietly enforces rules that no longer line up with how the team thinks about the record.
The pattern: near-matches as a systemic failure mode
The article is not really about locations or subsidiaries; it is about a recurring failure pattern in complex systems: the near-match.
A near-match is a configuration that is close enough to seem correct, but just far enough off to invalidate the assumptions that surround it. In ERPs, near-matches often show up as records scoped one level too high or too broad: a parent entity instead of a child, a shared vendor instead of a domain-specific one, a department standing in for a legal entity.
The system dutifully maintains relational integrity. References resolve, validations pass, IDs exist. From the platform’s perspective, nothing is clearly broken. But downstream, everything that depends on a tight execution domain starts to fray:
- Posting rules and accounting behavior do not line up with expectations.
- Permissions either hide or reveal records in ways no one anticipates.
- Scripts and workflows branch incorrectly or not at all.
- Integrations lose their sense of uniqueness and scope. The author is highlighting an important asymmetry: systems are very good at preserving structure and very bad at revealing semantic misalignment. They do not announce, “This object is modeled at the wrong boundary.” They simply execute their rules and let humans experience the misfit as chaos.
The purpose behind the post is to reframe that chaos as an expected outcome of subtle modeling choices, not as a collection of unrelated issues. Once the pattern is seen, it becomes diagnosable and, more importantly, designable against.
What this reveals about how teams really work
The article also surfaces a quiet tension between how teams operate under pressure and what stable systems require.
On one side is convenience drift. Under time pressure, people clone existing records, adjust visible fields, and assume surrounding context is “close enough.” Across months and years, this accumulates into inconsistent external IDs, ambiguous scopes, and records whose history no one fully understands. The platform appears to hold together, but only because its integrity checks do not reach the level where execution domains matter.
On the other side is discipline around boundaries. Stable automation requires clear, enforced lines: which entity owns this transaction, which scope guarantees uniqueness, which records scripts are allowed to touch. The article’s guardrails are less about technical hygiene and more about cultivating that discipline in environments that typically reward speed over rigor.
By insisting that fixes are migrations, not field edits, the author is pushing back against the instinct to treat mis-scoped records as cosmetic. A record tied to the wrong domain is not a typo; it is contaminated context. Other objects, processes, and external systems have already learned to depend on it. Changing it in place is like altering a foundational assumption in a running simulation and assuming nothing else will move.
Signals for leaders: the deeper warnings
Beneath the implementation detail, the piece sends several signals to executives, architects, and operations leaders.
1. “Random” operational pain is often design debt
The most expensive problems rarely present themselves as architecture questions. They show up as scattered pain: a receiving team that cannot post, a finance team reconciling odd balances, a data team fighting inexplicable discrepancies.
By tying these symptoms back to a single design error—modeling by org chart instead of execution boundary—the article encourages leaders to treat operational noise as a clue that something more foundational is misaligned.
2. Naming is not decoration; it is infrastructure
External IDs, naming conventions, and scoping rules are treated as central, not cosmetic. How a company names and scopes things constrains what it can safely automate later.
The emphasis on “unique enough” domains for IDs and on explicit execution context in names reflects an understanding that future integrations, workflows, and reporting will lean on those decisions. Loosely governed naming is a promise of future rework.
3. Guardrails beat training
The piece downplays the idea that more training will fix the issue. Instead, it advocates for small, structural changes: simple creation standards, validations that block unsafe combinations, searches that flag suspect records, and a no-reuse policy for IDs.
This is a shift from expecting individuals to remember invisible rules, to embedding those rules so that the correct choice is the path of least resistance. Sustainable reliability comes from design, not heroics.
In the end: modeling the reality you want to run
Ultimately, the article is a push to align the digital model of the company with where work actually happens, rather than with how the company prefers to narrate itself. Org charts tell a story about authority and reporting. ERPs need a map of execution and constraint.
The author is making a quiet argument about truthfulness in systems: if the internal representation of the business is even slightly untrue at the boundaries that matter, the system will enforce that untruth relentlessly. The result is not a visible crash but a slow cascade of mismatches that people experience as “random errors.”
Looking ahead, the practical invitation is simple: before creating, cloning, or reclassifying an object in a core system, pause and ask one question—where does the work actually execute? If teams build around that boundary, the ERP can become a reliable engine instead of a mysterious constraint.
For leaders, the next step is to treat this not as an isolated technical tip, but as a design principle for the whole operating model. Make execution domains explicit. Protect them with guardrails, not just documentation. Accept that system honesty may look less tidy than the org chart, and value it anyway.
That is the deeper purpose behind the original post: to move organizations from modeling how they look on paper to modeling how they really work—and, in doing so, to convert scattered operational friction into a tractable, structural design problem.