Investing in Business Process Automation: Where to Start

The situation companies face today

Labour costs are rising and hiring has become harder. Yet the volume of work to be processed has not fallen. Many companies try to close that gap with automation, but when the time comes to begin, they stall on the question of what to tackle first.

The problem is not a shortage of things to automate. It is that there are too many. Even companies with a full enterprise resource planning system spend a substantial share of actual working hours outside the system. Pulling a purchase order out of an email and retyping it into the system, copying a tracking number from a logistics provider's website into a customer's template, manually reconciling several spreadsheets at every period close — these are the typical cases.

Individually, these tasks look trivial. That is why they rarely make it onto an improvement backlog. But if one person spends 90 minutes a day on work of this kind, an organisation of 20 people loses roughly 7,500 hours a year. That is the workload of 3.5 full-time employees.

The larger loss is not time but errors and delays. Transcription by hand always produces typos, and processing halts whenever the person responsible is away. Because this cost is recorded in no ledger, by the time it surfaces it has already taken the form of a customer complaint or a missed deadline.

Why automation projects fall short of expectations

When an automation initiative fails, the cause usually lies not in the technology but in candidate selection. Three patterns recur.

First, the chosen process was dominated by exceptions. If more than half of all cases require exception handling, automation does not reduce work; it creates a new task of checking whether the automated result is correct. From the operator's point of view, the workload has increased.

Second, the input data was not structured. Purchase orders whose format differs by supplier, or spreadsheets whose column order changes every time, require format standardisation before any automation. Skip that step and the exception-handling logic simply keeps growing.

Third, there was no baseline against which to measure the effect. If processing time is not recorded before deployment, all that remains afterwards is an impression that things "seem faster". Where return on investment cannot be demonstrated, the budget for the next initiative is not secured either.

All three are questions that can be settled before work begins. That is why a diagnostic is needed.

Distinguish the two types of automation first

Before starting the diagnostic, dividing automation into two kinds keeps the judgement simple.

Rule-based automation takes over work whose conditions and handling are clearly defined. Tasks such as "when a purchase order arrives, read the line items and register them in the system" or "every morning, send a list of items whose stock has fallen below the threshold". The output is always the same, verification is straightforward, and build cost is comparatively low.

Judgement-based automation deals with work where the input differs each time and there is no single correct answer. Classifying free-form enquiries, extracting only the required fields from documents with inconsistent layouts, or answering customer questions in prose all fall into this category. Its reach is far broader, but it must be designed on the assumption that it can be wrong.

The two types are verified differently. For rule-based automation it is enough to check whether it did exactly what was specified, whereas judgement-based automation requires that the tolerance for error and the point of human intervention be defined in advance. Manage both against the same standard without drawing this distinction and the latter will invariably cause problems.

A four-stage diagnostic framework

Stage 1 — Build a task inventory

List the repetitive tasks in each department and record three things for each.

• Monthly volume
• Time per case
• Number of people handling it

The purpose of this stage is not accuracy but a comparable list. Attempt to measure to the minute and the survey itself will never finish. Ask the person doing the work roughly how many minutes it takes and write down the answer. Refining the margin of error is sufficient later, once the candidates have been narrowed.

In practice, an organisation of 20 to 30 people produces a list of 40 to 60 items. The act of compiling the list is already useful in itself. Repetitive tasks that not even the department head knew about frequently come to light at this stage.

One caution when surveying. Do not ask people what they would like to automate. Framed that way, you get the work they most dislike, not the work best suited to automation. Asking them to walk through what they did yesterday in chronological order is more accurate.

Stage 2 — Assess automation suitability

Assess each task along four axes.

Keep as first-round candidates only those tasks rated "suitable" on all four axes. If any axis is "unsuitable", classify the task as one whose precondition must be resolved before automation. Where the structure of input is unsuitable, for instance, this is not an automation initiative but a format standardisation initiative.

There is a simple way to judge clarity of rules. Ask the person doing the work whether they could hand the task over to a new joiner using documentation alone. Work that cannot be handed over on paper cannot be handed over to a machine either.

An unsuitable rating on structure of input is not immediate grounds for abandonment, because this is territory that judgement-based automation, as distinguished above, can cover. In that case, however, the accuracy target and the review procedure must be designed alongside it, so allow a longer preparation period than for a rule-based initiative.

Stage 3 — Calculate the payback period

Take precise measurements only for the first-round candidates, then calculate the payback period.

Annual savings = monthly volume × 12 × time saved per case × hourly labour cost
Payback period (months) = build cost ÷ ((annual savings − annual running cost) ÷ 12)

Three points require care.

Set the hourly labour cost on a fully loaded basis, not on salary. Including statutory insurance, severance provisions and office space, it typically comes to 1.3 to 1.5 times salary. Set this figure at salary alone and the savings are understated, causing genuinely sound initiatives to be rejected.

Time saved per case is not 100%. Even after automation, time goes into checking results, exception handling and system monitoring. For a conservative estimate, count 70% of the existing processing time as the saving.

Always account for the annual running cost. Server costs, external API fees and maintenance contracts belong here. A payback period calculated without this item comes out shorter than the reality.

A worked example

Substituting figures makes the judgement clear. The following is a hypothetical example intended to illustrate the method of calculation; actual values will differ according to each company's circumstances.

Assume the task of transferring purchase orders received by email from suppliers into an internal system.

Time saved per case is 12 minutes × 70% = 8.4 minutes, that is, 0.14 hours.

Annual savings    = 400 × 12 × 0.14 × 25,000 = 16,800,000 KRW
Annual net effect = 16,800,000 − 2,400,000 = 14,400,000 KRW
Payback period    = 18,000,000 ÷ (14,400,000 ÷ 12) = 15 months

A payback period of 15 months falls short of the "within six months for a first initiative" criterion set out below. In that case there are three options: find another task with a higher volume, narrow the build scope to lower the cost, or defer the initiative.

Apply the same calculation to a task running at 1,200 cases a month and the annual saving becomes 50,400,000 KRW, with the payback period dropping below five months. Volume dominates the payback period — that is the essential lesson of this calculation. Work that is short per case but occurs often generally comes before work that takes longer per case.

Stage 4 — Decide the order of execution

Sort by shortest payback period, but do not choose the first initiative on payback period alone. The first initiative has two conditions.

• A payback period within six months
• Work whose failure would not halt the core business

The second condition matters. If the first automation causes problems in a critical process, automation as an undertaking loses credibility inside the organisation. Conversely, a first success secures the budget and the cooperation of the business side for what follows. The first initiative is rightly chosen for certainty rather than scale.

Candidates that surface first, by industry

The tasks that come forward as first-round candidates are largely predictable by industry. Use the following as a reference list when building the inventory.

Manufacturing and distribution — collecting and entering purchase orders by supplier, alerts for stock below threshold, generating shipping instructions, collecting tracking numbers from logistics providers and notifying customers, multi-spreadsheet reconciliation at period close.

Services and B2B — issuing quotations, tracking contract status and expiry alerts, issuing recurring invoices, classifying enquiry types and assigning owners, summarising consultation histories.

E-commerce — order status change notifications, classifying returns and exchanges, synchronising product information across channels, collecting and classifying reviews, back-in-stock alerts.

Common to all — verifying attendance and expense documentation, provisioning accounts for new joiners, compiling periodic reports, synchronising data between external systems.

This list is only a starting point. Recognise as genuine candidates only those that pass the Stage 2 assessment, because exception rates and format structure differ from company to company even for the same task.

Checks before deployment

Once you have decided to proceed, confirm that the following five things are in place.

Have you measured the baseline. Processing time, case volume and error counts before deployment must be recorded. Begin measuring after deployment and there is nothing to compare against.

Is there a designed path for handing exceptions to a person. Cases the automation cannot handle will certainly arise. When they do, they must pass to a person rather than fail silently. Without this path, missed cases are discovered days later.

Do you have a means of noticing that the automation has stopped. When a person stops doing something, it is visible. Automation stops quietly. At minimum, put in place monitoring sufficient to raise an alert when throughput deviates from the norm.

Is maintenance responsibility defined for when the target system changes. The interfaces and APIs of integrated systems change without notice. Who fixes them, and by when, must be set out in the contract or in internal policy.

Have you checked personal data and regulatory requirements. If the process being automated handles customer or employee information, there are items to settle before work begins.

• Where personally identifiable information is stored during processing, and for how long it is retained
• If data is transmitted to an external service, in which country that data is stored
• Whether a processing record is retained so that activity can be traced after the fact
• Whether access rights are separated by role

Where an external artificial intelligence service is used in particular, always verify in the contract terms whether the data you submit is used to train that service. Enter customer information without checking this clause and an automation that works perfectly well in technical terms becomes a compliance breach. Retaining a step in which a person reviews the automated output is necessary for the same reason.

Build it yourself, or use what already exists

Once the target is settled, the implementation approach must be chosen. The deciding question is whether the work in question is a source of competitive advantage.

If handling the work differently from competitors is itself a strength of the company, building to fit is the better course. Conversely, if every company handles the work the same way, using something already proven is faster and cheaper. Building attendance tracking or electronic approval from scratch is, in most cases, waste.

When evaluating off-the-shelf products, however, check three things.

Can our processes be adapted to the product. Off-the-shelf products are built on the assumption of a standard procedure. Where current practice diverges sharply from that assumption, resistance to changing the process costs more than modifying the product.

Can the data be extracted. This is needed when migrating to something else later or connecting to internal systems. Confirm the data export function and the integration method before signing.

Who is accountable when it stops. For work that depends on an external service, an outage at that service is an outage in your operations. Obtain the response times and remedies in the event of an outage in writing.

Common objections and how to handle them

Automation initiatives are blocked more often by the organisation than by the technology. Anticipating the objections makes them easier to answer.

"There is nothing wrong with the way we do it now." Usually true. The problem arises not now but when volume grows. Answer this objection by presenting the breaking point rather than present-day inconvenience. Calculating and showing the maximum volume the current headcount can process is more persuasive.

"Does this mean my job disappears." This is the strongest objection and must be answered directly. Explain that the target is the simple, repetitive work the person already disliked, and decide in advance where the freed-up time will go before telling them. Without an answer ready, you will not secure cooperation even at the survey stage.

"There are too many exceptions for this to work." From the business side, this claim is usually accurate. Do not argue; count the exception rate for real. That is precisely the purpose of the Stage 2 assessment. If the count shows many exceptions, removing the task from the candidate list is the correct outcome.

"We tried this before and it failed." Establish the specific cause of the failure. In most cases it is one of the three patterns set out above. Demonstrate, with evidence, that the same mistake will not be repeated.

The first 90 days after deployment

Go-live is not the end but the start of verification. Confirm the following over the first 90 days.

First two weeks — parallel operation. Run the automation alongside the existing method and compare the results. The discrepancies found in this period reveal the true exception rate. Switch over directly without a parallel period and incorrect processing will be discovered weeks later.

First month — categorise the exceptions. Classify the cases passed to a person by type. Where a particular type recurs, it is not an exception but a missing rule. Incorporating it into the rules widens the scope of automatic processing.

Three months — compare against the baseline. Measure processing time, case volume and error counts again and compare them with the figures recorded before deployment. This comparison is the budgetary basis for the next initiative.

If the effect fell short of expectations, record that too. Knowing the conditions under which automation does not perform as hoped is the most valuable information available when choosing the next initiative.

Summary

Automation succeeds or fails on candidate selection rather than tool choice.

• Turn repetitive tasks into a list so that they can be compared.
• Distinguish rule-based automation from judgement-based automation and verify each differently.
• Keep as candidates only work with clear rules, structured input and few exceptions.
• Calculate the payback period conservatively, reflecting fully loaded labour cost and running cost. Volume dominates the outcome more than time per case.
• Choose the first initiative for certainty, not scale.
• Confirm the scope of personal data processing and the location of data storage before work begins.

Above all, measure the baseline before you begin. An improvement that is not measured cannot be proven, and an improvement that is not proven receives no further budget.