Business Process Automation

Business automation does not pay off everywhere: a process that changes every month costs more to automate than to leave manual. So I start with a measurement (where the time goes and what one error costs) and take on only what still comes out ahead once that is on paper.

What people arrive with

It usually starts with a single piece of paper. A purchase request lands in email on Monday; on Tuesday it is forwarded on, because the approver is away; on Wednesday its figures are retyped by hand into the accounting system; on Thursday it turns out they were retyped from the second to last message. By Friday nobody can say where the request stood for three days.

One such request is no reason for a project. The reason appears when there are hundreds of them a week and somebody’s whole working day consists of forwarding and retyping. That is when the call comes: not “it broke” but “what already works costs too much”.

Where business automation pays off

The calculation happens before any work starts: how many times a month the operation runs, how many minutes it takes, what an hour of that person costs, and what one error costs. On the other side: the hours to build it and to keep it running over the next two years. If the difference is negative, I say so.

Three things usually fail that test: an operation that happens five times a year; a process rewritten every quarter to keep up with a regulator; and a process the company does not agree on. The last one is the most common: the same request runs differently in two departments, and the route has to be agreed first.

The second condition is someone with the right to cancel a step: a person who can say “that signature is no longer collected” without asking three managers for permission. Without that right, the route collects exceptions within six months and drifts back into email.

What I build

• An end-to-end document route: request, approval, signature, archive, with a deadline on every step and a log that shows the delay.
• Data exchange between systems instead of retyping: the ERP, CRM, warehouse system, accounting.
• Reporting that assembles itself and arrives on schedule rather than being built by hand before a meeting.
• Event alerts: a missed deadline, a stalled request, a failed integration. Each one goes to a named person and repeats until the request is closed; none of them go to a shared chat, where such messages stop being read in the second week.

All of it lives inside your own perimeter. The route exists in two forms: a one page diagram for the accountant and a scenario in the orchestrator for the administrator; the two are not allowed to drift apart.

Integrations and data

Most of the work is not a “robot” but a careful exchange of data. Where a system has an API, the exchange goes through it: that version survives interface updates. Where there is no API: webhooks, scheduled exports, parsing inbound mail. The method is chosen by what will still work in a year, not by how fast it assembles.

A separate question is the source of truth. When the same customer record is edited in three systems, automation spreads the error faster than a person ever could. So before any exchange it is fixed which system owns which field.

Scenarios reach into systems through service accounts and keys that usually have no owner. I separate them and write down who holds what. Reviewing access rights across every system, and defending the perimeter, are not part of this work: that belongs to information security.

Two examples from practice

At ITLT Systems I was the CTO. One of the projects was a workforce management platform: onboarding, time tracking, payroll, compliance checks. Headcount there runs into the thousands, so a manual step in the middle of a process becomes the bottleneck at once.

PharmAPI is a different case: what was automated is not internal routine but counterparty checking. The key decision was to make every function available programmatically: the check fires as a counterparty is entered into the CRM, and nobody opens a separate service.

Stack

Off-the-shelf connectors are fine while there are few scenarios; once there are dozens, an orchestrator inside your own perimeter is cheaper: the bill for cloud runs grows faster than their number.

Layer	Tools
Process orchestration	n8n, Camunda
Data exchange	REST, Webhook, Apache Kafka
Requests and service processes	Jira Service Management, ServiceNow
Off-the-shelf connectors	Zapier, Microsoft Power Automate

It all runs on your own machines: Docker for the services, Ansible for the rollout, so a move to another server is described in a file rather than in an engineer’s memory. Numbers about the processes are pulled with a query to PostgreSQL and opened in Metabase, or in your own BI system when one is already in place.

What I do not do

• I do not start by buying a platform: the route goes on paper and gets measured first, and the tool is picked to fit it.
• I do not build a robot that clicks through someone else’s interface when the system has an API: that construction breaks on the first update.
• I do not park a company on an engine it cannot leave: before the choice I check that the scenarios export cleanly and what the move would cost.
• I do not hand over a list of people to cut: I show how many hours are freed and where. Headcount decisions are yours.

How the time is counted

The work is hourly, $350 per hour (AED 1,285). The hours exist so that stopping is possible: if three hours of measurement show the process is not worth automating, you pay for three hours. A fixed sum leaves no such exit: the money is already in, and the conclusion “do not build it” is unprofitable for both sides.

The measurement and the payback calculation take 8 to 15 hours and end with a list of processes and an estimate for each. One end-to-end route, from the review through to handover, is 30 to 60 hours. A programme covering several processes is counted monthly. In the report the hours are split by stage: measurement, diagram, building, handover; there is no “other work” line in it.

Related services

If it is not clear which process to touch first, start with IT consulting. The data you collect usually needs reading, which is data analytics. When automation is part of a two or three year plan, see strategic planning. When decisions like these keep arriving, there is the fractional CTO format.

Frequently Asked Questions

Which process should be automated first?

The one where the gap between hours a year and hours to build is widest. You name the two or three places that hurt most; for each I count the frequency, the time per operation and the cost of an error. The queue follows those numbers, not whichever process is argued about loudest.

Will the systems already in place have to be replaced?

Almost never. Connecting what is already installed and paid for is cheaper than any replacement. I propose a change in one case only: the system will not hand data out in any form, and then I cost the move straight away.

Is this workable for a company with no IT department?

Yes, and it is a common case. The solution is then built so that keeping it running needs no engineer: plain settings, alerts to a named person, documentation in English.

What happens when a scenario breaks one day?

It will break: a supplier changes an export format, or a key expires. Every scenario writes a log and sends an alert to a named person. Along with the scenario you get its export as a file and a one page instruction: where to look, what to restart. That is enough for your administrator or a contractor to take the repair on.

---

Ready to Get Started?

Take a process somebody did by hand twice this week: that is where the measurement starts. Book a process measurement.