What belongs in an ERP core system, and what comes later?
Which core processes should run first on one data basis, and why extensions follow the flow, not module packages.
An ERP core system bundles the core flows without which master and transaction data in the company fall apart: partners and articles, quote and order, warehouse movements, purchasing, and the handoff to finance. What comes later depends on the next real process, not on a module catalog. Teams that activate everything at once overwhelm users and migration. Teams that start process-first secure data quality and acceptance before special logic is added.
What typically belongs in the core?
Not as “buy modules,” but as end-to-end flows on one data basis:
- Master data: customers, suppliers, articles, partner relationships
- Order management: quotes, orders, invoices, and status across the transaction
- Warehouse: stock, goods receipt, transfers, inventory
- Purchasing: purchase orders and goods receipts in the same dataset as stock
- Finance preparation: accounting handoff, DATEV, e-invoicing path
- HR-adjacent steps only when operationally needed (for example times on the order), not because they sit in the package
Benefit appears when these flows share the same truth. Duplicate entry between shop, spreadsheet, and accounting is exactly what the core system should replace. Fundamentals: What is ERP?.
What comes later on purpose?
Manufacturing depth, complex quality inspections, project business with special approvals, industry portals, or machine connectivity. Not because they are unimportant, but because they sit on clean master and stock data. Without a reliable order-warehouse-purchasing path, every special logic multiplies errors.
The guiding question is: Which flow is still missing on the existing transaction? Not: Which module do we book next? Deeper: process structure instead of module structure.
Why does the “everything at once” start fail?
Because implementation is a change project. Too many parallel processes create too many master-data decisions, too many trainings, and too many exception paths on day one. The result is shadow lists and low acceptance, even though a lot is “technically” activated.
Better: take core processes live, measure data quality (duplicates, open stock, missing documents), then attach the next flow. Extensions reuse the same master data. No system switch, no full re-import.
Cloud or on-premise operations do not change this sequence. Both paths need the same process cut. Industry specifics in manufacturing: ERP in manufacturing.
How do you decide scope and sequence?
- Which flow causes the largest break today (duplicate entry, schedule slip, missing documents)?
- Which master data must be reliable for that?
- Which integrations are mandatory for this flow (DATEV, e-invoicing, shop)?
- What can follow in a second step without blocking the first benefit?
- Who carries specialist ownership and who carries operations ownership?
These questions replace module comparison as the steering instrument. Individual ERP such as Nuclos Enterprise is built around your processes. Delivery claims such as ERP in 30 days apply only on agreed scope, which is exactly why a clean cut between core and later matters.
Which decisions come next?
Define the first end-to-end core process and what comes later on purpose. Check whether your current landscape already shares master data and stock, or whether island solutions block the start. Put integrations and compliance paths (e-invoicing, DATEV) into the same scope as the core flow.
Further reading: What is ERP? and process structure instead of module structure. For the mid-market context: ERP for mid-market companies.