Navigating an ERP of 60 modules without 57 menu items

The number is accurate: NG One spans roughly sixty domains — inventory, sub-ledgers, the VAT engine, payroll, DMS, MRP, CMMS — each a separate bounded context and a licensing unit. That is a fact about the architecture, and navigation does not change it. The decision, usually made by default, is that each domain has earned a menu entry.

The menu is not a table of contents for the architecture

The mistake is made quietly, with good intentions. The module registry is the only list a team has when it designs navigation, so navigation becomes a projection of it. Every module brings an entry, the menu grows with the backlog, and three years on the user holds a list describing how the system was split among teams — and nothing about how the company works. The team that built it does not pay; the salesperson hunting for a quote does.

• Three and four levels, because fifty entries do not pack any other way.
• One function in three places: Sales → Invoices, Finance → Outgoing invoices, Documents → Invoices — three entrances, eventually three behaviours.
• Padlocks on modules the tenant never bought — a standing reminder of what they lack.
• Search as an escape hatch: not because it is fast, but because the menu was abandoned.
• Documentation that opens with “go to module…”, because the screen cannot be described otherwise.

Under every symptom sits one wrong assumption: that the user wants a module. They want a document, a decision, an answer. An accountant does not think “open the receivables ledger” — they think “the customer says they paid and the item is still open”. A warehouse operator wants the lot that expires first under FEFO. Navigation that answers the first framing and not the second is technically correct and practically unusable.

Nine spaces instead of sixty entries

The first level is not a module but a business space, and there are exactly nine: My Work, Sales and Customers, Procurement and Suppliers, Inventory and Logistics, Production and Operations, Finance and Compliance, People and Organisation, Documents and Processes, and Insights, Automation and AI. Nine names hide no complexity — it stays in the domains; what is refused is publishing the engineering org chart as a map of the business. The mapping is many-to-one, with one rule: every business object has one canonical home. A delivery note belongs to Inventory and Logistics, because shipping is physical rather than commercial — yet it is fully reachable from the sales order.

The table looks like an agreement about names. It is one about ownership: who may change a document's status, who defines its controls, who answers when behaviour differs between two entrances. “Reachable from” is not duplication — same screen, same owner, same rules, different context of arrival. Duplication is cheap today and expensive in three years: once a document has two homes it acquires two behaviours, and the question of which is correct has no answer. It has a meeting.

Two levels, and not one more

The left rail allows two levels at most: the space, and beneath it five to seven shortcuts that matter for the role. Clicking a space opens that area's workspace rather than expanding a list. The constraint is deliberately uncomfortable, and nothing disappears: the rest is reached through the workspace, search, and Atlas. A workspace holds five sections at most — Today, Needs attention, Core processes, Quick actions, Insights and automation. The menu answers where I work; the workspace, what now.

Role-aware is not a filter over the same screen

Not all nine spaces are visible to everyone. A salesperson needs My Work, Sales and Customers, Inventory and Logistics, Documents and Processes, and Insights — five, not nine. A director sees everything, because the intersection is the job. And the role decides more than visibility:

1. which spaces appear at all,
2. the order they appear in,
3. which shortcuts hang beneath them,
4. which workspace opens at sign-in,
5. which KPIs are shown,
6. which perspective the Atlas opens by default.

A capability catalogue instead of padlocks

Modules a tenant has not switched on do not sit in the menu as locked entries. That pattern fails twice: as noise, because most users will never open the module and the padlock only lengthens their daily list; and as a sales channel, because it says something exists but not what it does. In its place stands the capability catalogue, with three states — active in this tenant, available within the licence and switched on by configuration, outside the current licence. Each entry leads to its own page: one page, business value, one illustration. Whoever opens it came to see what they get; whoever did not was never interrupted.

Behind the catalogue sits the navigation registry: one entry per module, carrying the module code, space, capability group, canonical owner, related end-to-end processes, roles, and licensing rule. Menu, workspaces, catalogue, and Atlas all render from that one entry — so a module cannot exist in the menu and be missing from the catalogue, nor carry two different names on two screens. The catalogue is not a marketing layer above the system; it is a second view of the same data. That difference becomes visible the third time a module gets renamed.

The Atlas: a map that carries state

A company's process diagram is usually a two-year-old PDF, roughly accurate, that nobody opens. The Atlas keeps the map inside the system, correct because it reads real state rather than because someone updated it. Two things it deliberately is not: a radial spider around a logo, and a single linear chain. A company is not linear — procurement does not always follow sales, production does not always follow stock, service begins when a customer calls. The view is parallel chains:

• Revenue — Lead-to-Cash: opportunity → quote → order → delivery → invoice → collection.
• Supply — Procure-to-Pay: need → approval → purchase order → receipt → invoice → payment.
• Operations — Plan-to-Fulfill: plan → materials → production → quality → stock → delivery.
• Finance — Record-to-Report: document → posting → controls → close → reporting.

The chains intersect at shared nodes — Stock and Invoice belong to two — and the intersection is the point, not the noise. Beneath them run support layers: People and Organisation, Documents and Processes, and AI crossing all of them. What separates the Atlas from a picture is state on the nodes: what is active, what waits, what is late. “12 quotes awaiting a reply”, “3 picking tasks running late” — figures from a demo tenant, though the principle is not: a node without a number is decoration. Colour is spent only on status, risk, and delay; a decorative colour per module would burn the map's only channel for saying something is wrong.

Cmd+K stays deterministic. AI sits beside it.

The most expensive mistake here is made out of enthusiasm: search gets “improved” by adding a model. From that moment the user no longer knows what they get. Cmd+K runs on muscle memory — type three characters, the second result is always the same screen, press Enter before the list renders. A system that occasionally reorders results “intelligently” has destroyed the only property worth learning it for. Hence two functions. Cmd+K is deterministic: find a screen, a document by number or partner, an item, a known action. When it does not know, it returns nothing — also information.

AI is the fourth layer: a contextual right-hand panel over the current screen and object, not an isolated chat module. It offers contextual actions instead of an empty field — on a supplier invoice: explain the posting, check the VAT treatment, find the matching goods receipt, check for a duplicate, draft a supplier message. Open questions (“draft a dunning letter for customers 30+ days late”) use the same panel. The difference from search is not the model but the contract: from Cmd+K you expect an exact route, from the panel a reasoned proposal.

Four rules that hold this together

1. 1

   The registry is the source; the menu is the consequence

   Every entry carries the module code, space, capability group, canonical owner, related end-to-end processes, roles, and licensing rule. The menu is a view over that registry, never the reverse — which is why two routes to the same delivery note cannot drift into two behaviours, however different the journeys look.

2. 2

   One workspace anatomy, nine times

   A workspace has one skeleton, not nine designs: Today, Needs attention, Core processes, Quick actions, Insights and automation. Finance uses the same layout as Inventory, with its own content and its own KPIs. Nine separate designs would be nine unfinished arguments about what a workspace is.

3. 3

   A node without a source is not on the map

   Every number on the Atlas resolves to a query over the tenant's real documents, under the permissions of the person looking — not a figure typed in beside an icon. A node that exists for symmetry and has nothing to count is an illustration, and it has no place on a map that claims to show state.

4. 4

   The catalogue carries scope; the menu carries orientation

   Scope grows in the domains and in the catalogue; the rail stays at nine spaces. Switching a module on for a tenant therefore does not add a menu entry — it changes what the workspace and the catalogue contain. It is the only way a system of sixty domains avoids eating its own navigation.

Under those nine names sits a system with no reason to apologise for its size: roughly sixty domains, eight end-to-end processes the Atlas draws, dimensional posting from the first line, the SEF channel in both directions, POPDV and the PP PDV return, payroll with PPP-PD, a WMS with bin locations and directed picking, administration with six-layer authorisation. Navigation is what keeps that mass inside nine names and two levels — the only reason the scope reads as capability rather than weight. The measure is not a click count but the sentence a user says after a demonstration: if it is “this ERP has a lot of modules”, the navigation failed. If it is “I can see where my work is”, it did not.