Our ERP vendor sells a workflow module. Why not use that?

Sometimes you should. The test is fit, not loyalty: does the module run your approval chains, your exception queues, your customer-specific rules without workarounds? ERP workflow modules are usually generic frameworks that assume your process looks like everyone else’s. If configuring it takes a year of consulting, you are paying custom prices for off-the-shelf fit.

Won't building tools around the ERP create integration risk?

There is integration work either way—the question is whether it is visible. A well-built operational layer reads and writes through the ERP’s own interfaces, so the ERP stays the single source of truth for items, customers, and transactions. The riskier pattern is what you have today: copies of ERP data drifting in spreadsheets and inboxes with no synchronization at all.

How do we know if our ERP is actually the problem?

Look at where the pain lives. If it is in transactions themselves—posting, inventory valuation, financial consolidation—the ERP is the problem. If transactions post fine but the work around them happens in email, hallway conversations, and personal spreadsheets, the ERP is doing its job and the missing piece is the operational layer.

We are mid-implementation of a new ERP. Should we wait?

Finish the implementation first; you need the system of record stable before you build around it. But use the implementation to watch for the gaps—every “we will handle that outside the system” note is a candidate for the operational layer later.

Does Praxyt replace ERPs?

No. Praxyt builds the layer around the ERP you keep: quote and approval workflows, order exception handling, backorder control, portals, and dashboards that read from and write back to your system of record.

Making the call

Internal tools vs. ERP: a new system, or a layer around the one you have?

If your ERP posts transactions accurately and the pain lives in the work around those transactions—the approvals in inboxes, the exceptions nobody owns, the status updates that require phone calls—you do not need a new ERP. You need an operational layer around the one you have. Replacing the ERP to fix a workflow problem is the most expensive way to leave the problem in place.

The distinction matters because the two systems have different jobs. An ERP is a system of record: it holds items, customers, orders, and the financial truth. It was never designed to control the decisions, handoffs, and exceptions that happen before and after a transaction is recorded. We wrote a full essay on this—why your ERP is not the same as an operating system—and it is the argument this page applies.

What each is actually for

ERP — system of record

Records orders, invoices, inventory, and the financial truth
Enforces accounting rules and audit trails
Standardized across thousands of companies by design
Workflow features are generic frameworks, not your process
Expensive and slow to change; every modification is a project

Internal tools — operational layer

Runs the work around transactions: approvals, exceptions, handoffs
Encodes your pricing rules, margin floors, and escalation paths
Shows one queue of what needs a decision, not a stack of reports
Reads and writes through the ERP’s own interfaces
Small and specific, so it changes as fast as your operation does

Keep the record where it is. Build the layer where the decisions happen.

When the ERP genuinely is the problem

Be honest about this, because “the ERP is terrible” often means “nobody configured it” or “the warehouse never adopted it.” The real cases for replacement are narrow. The system is unsupported or end-of-life and the risk is real, not theoretical. It cannot expose its data through any interface a modern tool can use. Its core data model no longer matches the business— you have become a different company than the one that bought it. Or transaction processing itself is broken: costing is wrong, inventory cannot be trusted, consolidations take weeks.

If none of those are true, an ERP replacement will consume a year or two of management attention, cost far more than the proposal said, and deliver the same workflow gaps you have today—because they were never ERP gaps in the first place.

When internal tools around the ERP are the better choice

Build the layer when transactions post fine but the operation around them runs on goodwill. Quotes wait in a manager’s inbox because the ERP has no approval chain that matches your pricing and margin rules. Short shipments and backorders surface when the customer calls, not when they happen, because the ERP records them but does not escalate them. Customer service re-keys the same details into three places because nothing connects the inbox to the order. Reports take a week to assemble because the numbers live in five systems and a spreadsheet only one person understands.

These are not reasons to replace the system of record. They are the exact shape of the workflow systems and operational dashboards that sit on top of it—and the reason clean integration with the ERP matters more than any single feature.

Common mistakes on both sides

Buying ERP modules for workflow problems. A generic workflow engine plus a year of configuration is custom software with someone else’s constraints.
Building tools that duplicate ERP master data. The operational layer should reference customers and items from the ERP, never maintain its own copies.
Replacing the ERP to fix an adoption problem. If the warehouse will not scan today, a new system will not make them scan.
Letting the ERP vendor scope the operational layer. Their incentive is to sell modules; your interest is a small system that does exactly your work.
Waiting for the “big reimplementation” to fix everything. The gaps costing you money this quarter are usually fixable in one workflow at a time.

Frequently asked questions

: Sometimes you should. The test is fit, not loyalty: does the module run your approval chains, your exception queues, your customer-specific rules without workarounds? ERP workflow modules are usually generic frameworks that assume your process looks like everyone else’s. If configuring it takes a year of consulting, you are paying custom prices for off-the-shelf fit.
: There is integration work either way—the question is whether it is visible. A well-built operational layer reads and writes through the ERP’s own interfaces, so the ERP stays the single source of truth for items, customers, and transactions. The riskier pattern is what you have today: copies of ERP data drifting in spreadsheets and inboxes with no synchronization at all.
: Look at where the pain lives. If it is in transactions themselves—posting, inventory valuation, financial consolidation—the ERP is the problem. If transactions post fine but the work around them happens in email, hallway conversations, and personal spreadsheets, the ERP is doing its job and the missing piece is the operational layer.
: Finish the implementation first; you need the system of record stable before you build around it. But use the implementation to watch for the gaps—every “we will handle that outside the system” note is a candidate for the operational layer later.
: No. Praxyt builds the layer around the ERP you keep: quote and approval workflows, order exception handling, backorder control, portals, and dashboards that read from and write back to your system of record.

Keep investigating

Your ERP may be fine. The work around it may not be.

A Workflow Review shows where the operational gaps actually live—and whether they justify a build.

Book a Workflow Review Explore Common Operational Problems