The unglamorous answer is usually the right one.
A large share of the repetitive work in an enterprise is deterministic: if these three conditions hold, do this. It does not need a model, it needs a rule, a route and an owner. Rules are cheaper to build, impossible to hallucinate, and trivially explainable to an auditor.
The discipline is resisting the temptation to solve a level-two problem with a level-four tool. We start at the bottom of the ladder and only move up when the process genuinely requires judgment that rules cannot express.
What we automate, and what we do not.
Manual data movement
A person exports from one system and imports into another every morning. This is an integration, not a job.
Approvals routed by email
Requests circulate in an inbox with no timer, no authority limit and no audit trail.
Reports assembled by hand
The same workbook is rebuilt monthly from four exports, by someone senior enough to know better.
Reconciliation as a role
A person exists because two systems disagree. Fix the disagreement rather than automating the reconciliation.
Automating an unstable process
If the process changes monthly, automation locks in a version that will be wrong next month.
RPA over a broken interface
Screen-scraping a system that has an API is technical debt dressed as a quick win.
What the engagement actually includes.
Workflow automation
Requests, approvals and internal services moved into governed workflows with authority limits, timers, escalation and a complete audit trail.
Rules engines
Deterministic decisions encoded as rules the business can read and change — pricing checks, credit holds, routing, eligibility — with versioning.
System integration
Where the automation is really a missing interface, we build the interface — as a versioned contract, not a scheduled export script.
RPA where it fits
Used only where a system genuinely has no interface and replacing it is not viable. Documented as deliberate debt with a review date.
Report automation
Recurring reports generated from source rather than assembled — including the ones that currently take a senior person two days a month.
Hour accounting
Each automation is measured against its baseline and reported: hours removed per month, and what the freed capacity was redeployed to.
Rule first, model last.
We start at the bottom of the automation ladder. These are the components used at each level, chosen for governability.
Ranges observed on Al Jawad engagements. Your targets are agreed in assessment, before the work starts.
Is RPA still relevant?
In narrow cases. Where a system has no interface and cannot be replaced, RPA is a reasonable bridge. Where an API exists, screen automation is debt we would rather not create.
How small can a first automation be?
Small is better. One workflow, four to six weeks, with a measured hour reduction. That earns the right to do the next one.
What if our process changes often?
Then we stabilise it first, or build the rules so the business can edit them without us. Automating an unstable process locks in a version that will be wrong next month.
Do you automate before or after process redesign?
After. Automating an inefficient process makes it fail faster and entrenches the inefficiency in code.
Start a conversation.
Choose the one that fits where you are. None of them is a sales call. Each is an advisory conversation calibrated to a specific question.