Process Improvement Before Automation: Our ERPNext Approach

Process improvement · ERPNext · Business automation

Before We Automate a Process, We Ask Whether It Should Exist

A purchase request passes through four inboxes. The same details are typed into three places. Someone spends Friday preparing a report nobody uses to make a decision. Before we turn those steps into an ERP workflow, we ask what each one achieves.

By Craft Interactive · Published 29 October 2026

Why review a process before automating it?

Process improvement before automation means checking whether each step contributes to an outcome, manages a real risk or meets a genuine requirement. We remove redundant work, simplify unclear handoffs and define necessary controls before configuring the system.

Software can route a request faster. It cannot decide, on its own, whether the request needed four signatures. If we reproduce every existing step in an ERP, we may also preserve the reasons work gets stuck.

Our starting question: If this step disappeared, what specific decision, protection or useful information would we lose?

The answer sometimes justifies keeping the step. Sometimes it shows that an approval should become a notification, or that a spreadsheet exists only because two departments cannot see the same record.

We begin with work that actually happened

A process diagram describes the intended route. A recent transaction shows the route people really took. We ask the team to walk through an ordinary request, a delayed one and an exception that required extra attention.

For each example, we trace the original request, the information entered, the people involved, the decisions made and the points where work stopped. We also look for activity outside the official process: a WhatsApp confirmation, a private spreadsheet or an email sent because someone did not trust the status on screen.

Working time

Time spent checking, entering, preparing or correcting the transaction.

Waiting time

Time spent in a queue, an inbox or a handoff before the next action.

Repeated work

Information copied, decisions repeated or documents rebuilt without adding value.

These are different problems. A form that takes five minutes to complete but waits two days for an unclear approval needs a different solution from a form that requires 45 minutes of manual re-entry.

A routine purchase that became everyone’s responsibility

Consider Harbour Tools Trading, a fictional UAE distributor. Its warehouse requests AED 2,400 of standard packing materials from an existing supplier. The purchase is within an approved budget and uses agreed prices.

The warehouse supervisor emails the request. A coordinator copies it into a spreadsheet. The department manager confirms the need. Procurement checks the supplier and price. Finance confirms the budget. A director gives a final approval. The coordinator then retypes the same details into a Purchase Order and updates the spreadsheet again.

Several people are doing useful work. But not every handoff is making a separate decision.

This is a proposed design exercise, not a reported client result. AED 2,400 is an example amount, not a recommended approval threshold. The business must decide its own authority limits and required controls.

How we decide whether an approval earns its place

We give each approval a job description. “The manager has always approved it” explains the history, but it does not explain the decision.

1. What risk does it address? Examples include unbudgeted spending, unsuitable suppliers, unusual discounts or changes to payment details.
2. What evidence does the approver review? The reviewer needs enough information to make a decision, not simply a button to press.
3. What can the approver change or reject? If they have no meaningful discretion, the action may be an acknowledgement rather than an approval.
4. Has another person already made the same decision? Two reviews can be justified when they address different risks. We examine their purpose before combining them.
5. What happens when the approver is unavailable? A named delegate and an agreed escalation route prevent routine work from depending on one inbox.

A rarely rejected request is not automatically evidence of a useless control. Good preparation or the existence of the check may be preventing errors. We review what the control protects before changing it.

Approval, visibility and ownership are different needs

A director may need visibility of spending without approving every routine purchase. A buyer may need ownership of a request without being authorised to approve it. A finance colleague may need a notification when a condition changes rather than another mandatory sign-off.

Separating these needs helps us design a process with fewer unnecessary interruptions and clearer accountability.

Repeated work often reveals missing trust or visibility

When someone maintains a second tracker, we ask what the official record cannot tell them. Perhaps the delivery date is missing. Perhaps nobody updates the status. Perhaps the department cannot access the report it needs.

Removing the spreadsheet before resolving that problem simply moves the workaround elsewhere.

• The same data entered twice: identify the authoritative source and use linked records or a scoped integration where appropriate.
• A daily “any update?” email: check whether the record has a current status, a responsible person and an expected next action.
• A weekly report rebuilt by hand: establish who uses it and which decision it supports before designing a report or dashboard.
• Repeated corrections: investigate unclear item codes, missing fields, inconsistent units or incomplete requests at the point of entry.

Some repeated checks remain necessary. Comparing received goods with an order serves a different purpose from approving the original purchase. We preserve checks that detect a new type of error.

We agree the simpler process before configuring it

For our fictional packing-material purchase, a revised process might retain the department owner’s confirmation and procurement’s supplier review, while escalating only the exceptions defined in the approved policy. Finance retains the visibility and controls needed for budget, invoice and payment responsibilities.

We document the agreed route in plain language: who creates the request, who decides, what evidence is required, which conditions trigger escalation and what happens after rejection. We also decide which old form or tracker can be retired.

Fewer approvals must not quietly remove independence. Changing who authorises a purchase does not mean giving the requester unrestricted authority to change supplier bank details or release payment.

The process owner signs off the revised responsibilities. Any contractual, statutory or internal control requirements remain part of that review. We then have a concrete process to implement and test.

Where ERPNext fits after the process review

ERPNext provides tools for implementing the agreed process. The useful question is which capability supports each decision, rather than how many approval levels we can add.

Assignment is not approval. A condition-based workflow is not a complete control framework by itself. We test permissions and document submission behaviour together, including what happens when data changes or a request is rejected.

Some policies need custom fields, validation or additional development. Budget checks, delegation, reminders and external integrations must be confirmed against the deployed version and agreed scope. They should not be assumed to work automatically because a workflow has been created.

For businesses considering ERPNext implementation in Dubai and across the UAE, this discovery work helps make the configuration more relevant to everyday operations. Open-source ERP software offers flexibility; a clear process tells us where that flexibility is useful.

We test the awkward cases before go-live

The routine request is only the first test. We also walk through a request above the authority limit, a new supplier, a rejected request, an unavailable approver and a change made after approval. Where thresholds apply, we test values immediately below, exactly at and above the limit.

We check that users cannot bypass the intended route through their permissions. We review who can amend or cancel documents and which changes require a fresh decision. If a request can be split to avoid an authority limit, that risk needs a policy and monitoring response.

Once the pilot works, we retire superseded trackers with an agreed cutover. Keeping the old and new processes indefinitely can bring the duplicated work straight back.

Measure whether work improved

Before making changes, record a baseline over a representative period. After the pilot, compare similar transactions using the same definitions.

• Approval lead time: how long a complete request waits for a decision.
• Manual touches: how often someone re-enters or transfers the same information.
• First-pass completeness: how many requests can proceed without being returned for missing details.
• Control exceptions: unauthorised changes, incorrect approvals or issues missed by the revised process.

A faster approval is useful only if the decision remains sound. We look at speed, effort and control together, then adjust the process using what the team learns.

Frequently asked questions

Bring us one process that keeps getting stuck

It could be a purchase request, a discount approval or a report your team rebuilds every week. We can review the purpose of each step and discuss how ERPNext can support a simpler, accountable process.

Discuss your process with us

Further reading

The example and review method in this article are illustrative. Product capabilities are referenced from the official ERPNext documentation:

• Workflows and transition conditions
• Role-based permissions
• Assignment Rules