Chris June frames the issue like this: an ERP team doesn’t struggle because workflows don’t exist—it struggles because the handoffs between workflows are brittle and invisible. In this editorial, lightweight custom software means a small, purpose-built layer that routes requests, enriches them with the right context, and publishes updates back to ERP users—without replacing the ERP itself.For Canadian SMBs, the practical goal is operating_model_clarity: you want teams to know what happens next, why it happened, and what changed, even when the ERP’s native workflow tooling can’t express every “small business reality.”
What gaps does ERP workflow software actually leave open?
Most off-the-shelf ERP systems handle core transactions well: purchase requisitions, approvals, postings, and status changes. The gap is usually the connective tissue around them—who should be notified, which data should be consulted at the moment of decision, and how updates should be communicated when multiple systems and teams touch the same record.Two common examples from real ERP operations:1) Routing and approvals lack “request context.” Many approval events are triggered from a workflow step, but the approver still has to reconstruct the story (vendor history, policy notes, attachments, or prior exceptions) from multiple screens or emails.2) Update visibility is fragmented. When a workflow completes—or stalls—users need a clear “what changed” narrative. SAP, for example, explicitly supports monitoring background workflow integration messages, because operations teams need visibility into what’s actually happening behind the scenes. (help.sap.com)
Proof: Microsoft’s Dynamics 365 guidance on business events and workflow approvals shows the ERP workflow pattern (business event → workflow approval) and how the configuration depends on specific platform conditions and versions. That kind of coupling is exactly where small teams often feel pressure to build “glue” when the native workflow isn’t enough. (learn.microsoft.com)
Implication: if you don’t add coordination and context around ERP workflows, you’ll end up with “tribal knowledge” and manual follow-ups. That raises cycle time and increases the risk that someone approves with missing information.
How does lightweight ERP workflow support software look in practice?
Lightweight custom software usually looks like a support layer, not a replacement stack. It focuses on four jobs:1) Agent orchestration for handoffs across people and tools (ERP, email, ticketing, spreadsheets).2) Context systems that normalize the “story” of the request: what triggered the workflow, which records are linked, and which policies apply.3) Failure handling that routes exceptions to humans with clear next steps.4) Update publication that posts a short, auditable summary back to the places users already look.If you’re using an AI component, keep it narrow. Let it draft summaries, propose clarifying questions, or classify exceptions—but keep deterministic logic for routing and approvals.
Proof: Microsoft’s Power Automate Approvals patterns show how approval requests are created and awaited through a defined workflow action model (e.g., “create approval request,” then “start and wait for approval”). That’s the kind of deterministic “await and continue” orchestration you can wrap with custom logic for context and better notifications. (support.microsoft.com) (support.microsoft.com)
Implication: you can deliver measurable clarity without touching your ERP’s core posting logic or rewriting procurement/finance flows.
When is a focused tool enough, and when do you need custom software?
A common budget trap is assuming that “AI for ERP” means you must build everything. In reality, there are two tiers:Tier A: focused platform tools are enough when the workflow gaps are already covered by the vendor’s process model. For example, if your ERP event model supports the right triggers and the approvers only need a better interface—not new coordination logic—you can often rely on native events/workflows and a small amount of configuration.Tier B: lightweight custom software becomes necessary when you need cross-workstream coordination, richer context, or safer update loops than the ERP’s own workflow UI provides.A practical way to decide:- If you can express the needed behavior as “when X happens in ERP, do Y deterministically, then notify Z” using vendor workflow constructs, choose the focused tool route.- If the behavior requires context enrichment, multi-step investigation, and human decision logging across systems, you’ll need a small custom layer.This distinction matters because operational risk isn’t just about model output; it’s also about human-AI teaming and how people are kept in control at decision points. NIST’s AI Risk Management Framework emphasizes trustworthy AI design and risk management practices, including human-centered considerations. (nist.gov)
Proof: NIST’s AI RMF playbook and core framework organize actions into Govern, Map, Measure, and Manage, which is a useful lens for lightweight ERP support systems: you can “map” what context is needed, “manage” exceptions with human-in-the-loop steps, and “measure” performance against cycle-time or error-rate. (nist.gov)
Implication: start with the smallest system that closes the real handoff gap. If you overbuild on day one, updates, integrations, and edge cases will cost more than the ERP team saves.
What trade-offs and failure modes should you design for?
Lightweight doesn’t mean fragile. It means intentional boundaries.The most common failure modes in ERP workflow support software are predictable:1) Context drift. The support layer uses the wrong record snapshot (e.g., stale vendor master data). Approvers get a confident summary that doesn’t match the current ERP state.2) Silent routing failures. A request gets stuck because the support layer couldn’t reach an integration point, and nobody sees that it’s stuck.3) Over-automation. The system starts “helping” beyond the decision authority you intended, especially when AI summarization is treated as final.4) Update coupling. ERP vendors change event schemas or workflow behavior. The custom layer breaks in subtle ways.
Proof: SAP’s workflow capability integration documentation highlights the need to monitor and administrate background workflow processing via message dashboards and monitoring over time. That operational monitoring is not optional if you want fewer “unknown stuck states.” (help.sap.com)
Implication: build for failure as a feature. Use deterministic orchestration for routing and approvals; store an immutable “request narrative” for each handoff; and ensure every failure routes to a human with an explicit next action.
A realistic Canadian SMB example that stays lightweightConsider a 25-person
Canadian distribution wholesaler using an ERP for purchasing and AP. They have:- 2 people in operations handling vendor onboarding and purchase requisitions.- 1 bookkeeper managing AP approvals and invoice exceptions.- 1 IT generalist who can’t support a large engineering roadmap. Their pain point isn’t that the ERP can’t approve purchases. It’s that approvals stall when information is missing: tax documentation, last-mile delivery notes, and the “why” behind a price variance.A lightweight support layer solves it this way:- Routing: When a purchase requisition approval is created in ERP, a small service posts an “approval packet” to the bookkeeper’s work queue.- Context system: The packet includes normalized fields from the requisition plus the last documented vendor exception notes.- AI custom tool (narrow scope): A small summarizer drafts a one-page explanation of the variance and lists missing attachments. It does not decide approval.- Update loop: When the approver approves/rejects, the layer writes a short changelog back into the ERP-linked record so operations can close the loop without searching email threads.
Proof: Microsoft’s approach to configuring and consuming workflow approvals through workflow business events illustrates the underlying “event-driven approval” model your support layer can hook into. (learn.microsoft.com)
Implication: the team improves handoffs and status visibility while keeping the ERP’s financial logic intact. The build stays small because it focuses on coordination and context, not re-implementing procurement or accounting.
See Systems We Build
If you want operating_model_clarity without a massive build, the first step is mapping your ERP handoffs and identifying where coordination, context, and updates break down.See Systems We Build.