Circumz
"ERP" is one of those terms that's been stretched so wide it barely means anything anymore. It's been used to describe million-dollar SAP implementations that take two years to roll out, and it's been used to describe glorified spreadsheets with a login screen. Neither extreme is very useful if you're actually trying to decide how to run your business.
Here's a more useful definition: an ERP is the system where the operational facts of your business — who your customers are, what you've sold them, what you've bought, what you have in stock, what a project has cost so far — live in one place, so that every part of the business is working from the same numbers.
That last part is the whole point. It's not about having more software. It's about not having contradictory software.
The problem ERP actually solves
Picture a mid-sized contracting company. Sales tracks quotations in one tool. Procurement runs purchase orders through email and a shared spreadsheet. The warehouse keeps a manual stock count. Finance reconciles invoices in an accounting package that has no idea a "project" exists as a concept.
Every one of those tools might be perfectly good at its narrow job. The failure isn't in any single tool — it's in the gaps between them. Nobody can answer "is this project actually profitable right now" without pulling numbers from four systems and reconciling them by hand, usually days or weeks after the fact.
An ERP closes those gaps by design. A customer record, a project record, an inventory item — each exists once, and every module that touches it reads and writes the same underlying data.
What that looks like in practice
Concretely, a modern ERP should let you trace a single thread through the business:
- A customer requests a quotation.
- The quotation becomes a sales order, then a contract.
- The contract becomes a project, with a defined scope and budget.
- Materials are purchased against that project's requirements.
- Stock is received and consumed against it.
- Progress and cost accumulate on the project record.
- Invoices reference the contract and project they came from.
- Payments close the loop.
At every step, nothing needs to be re-typed. The customer on the invoice is the same customer record from step one. The cost on the project is built from the actual purchases and stock movements, not a manual estimate.
This is the same workflow Vertex is built around — see how modular ERP systems work for how the pieces connect without becoming one monolithic system.
What "modern" changes
The core idea of ERP — one shared operational record — hasn't changed since the concept was named in the 1990s. What has changed is how it's delivered:
| Then | Now |
|---|---|
| On-premise servers, IT-managed | Server-rendered web apps, accessible anywhere |
| Multi-year implementation projects | Modules adopted incrementally, in weeks not years |
| Rigid, generic workflows | Configured around how your business actually operates |
| One-size-fits-all licensing | Pay for the modules you actually use |
The other real shift is modularity. Older ERP systems tended to be monolithic — you bought the whole suite, whether you needed payroll and manufacturing planning or not. A modern ERP should let a business start with what it needs today — say, sales, procurement and finance — and add fleet or logistics later, without a migration.
What ERP is not
It's worth being clear about what a good ERP doesn't try to be:
- It's not a replacement for judgment. It makes the numbers visible; it doesn't make decisions for you.
- It's not a CRM, an accounting package, or a warehouse system bolted together with duct tape. Those integrations exist, but they're a workaround for not having a real shared data model — not the same thing as one.
- It's not a project that has to take a year to show value. If a module can't demonstrate value within weeks of turning it on, something's wrong with how it was designed.
The honest test
The simplest way to know whether a system is actually functioning as an ERP, rather than just a collection of screens: pick any invoice and ask where the numbers on it came from. If the answer is "the finance team typed them in based on what sales told them," you don't have an ERP yet — you have a database with better formatting. If the answer is "the sales order, the purchase orders, the stock issued and the hours logged," you do.
That's the bar. Everything else — the interface, the modules, the industry it was originally built for — is secondary to whether the system actually connects the operational reality of the business to the numbers everyone is looking at.