Process Automation or Process Improvement?

Every morning, someone downloads the webshop orders, copies them into a spreadsheet, and then forwards the data to the warehouse and billing. The process works - until the person goes on vacation, an order data is incorrect, or the traffic doubles. This raises the question: process automation or process improvement should be the next step?

The two areas are not alternatives in every situation. The right decision is a matter of order. If we automate an opaque process filled with unnecessary steps, we will execute the same poorly designed process faster. However, if we first understand and simplify the operation, automation provides real capacity, reliability, and better managerial insight.

The question is not whether there is manual work involved

Manual tasks are not inherently a flaw. Investigating a customer complaint, approving a unique quote, or evaluating a manufacturing deviation may require human judgment. In these cases, the goal is for the colleague involved to make decisions based on appropriate, up-to-date information.

The situation is different when someone regularly enters the same data into three different systems, searches emails for the current status of an order, or spends three hours on a Friday afternoon compiling a management report. These tasks often require attention and repetition rather than expertise. Moreover, every manual transfer is an opportunity for error: the item number can be mistyped, an order can be missed, or records between two departments can differ.

The problem often isn't that people are involved in the process, but that they are the link between isolated systems. Sales know something that the warehouse only sees from a later forwarded spreadsheet. Finance works with different data than operations. Management gets a picture of the operation only after someone has manually compiled the numbers.

What does process improvement really mean?

Process improvement is not necessarily a major organizational overhaul. It first examines how a case, order, manufacturing task, or document progresses through the company. Who initiates it, who decides on it, in which system the information is generated, how many times it is transferred, and where it waits unnecessarily.

For example, in order processing, it may quickly become apparent that the team maintains a separate spreadsheet because the ERP lacks an easily viewable status list. Or it may be that the spreadsheet exists out of habit: it was introduced due to a previous system limitation that no longer exists. In such cases, clarifying responsibilities, standardizing a status field, or correctly using an existing system function may suffice instead of automation.

During development, it's worth asking some uncomfortable but useful questions:

• Why does this step occur, and what business risk does it address?
• Who uses the information generated here, and do they really need it in this form?
• Where is the data generated, and why do we re-enter it elsewhere?
• What happens if the colleague familiar with the process is unavailable for a week?

The answers to these questions often hold more value than selecting new software. It may turn out that two participants can be removed from an approval loop. Other times, it becomes clear that the process relies on the experience of a single person, without documented rules and verifiable statuses. This not only results in slow operation but also poses a business continuity risk.

When is process automation justified?

Process automation yields good results when the process's purpose, rules, and exceptions are sufficiently clear. Not every detail needs to remain unchanged, but it's essential to know what event initiates the process, what data is needed, who is responsible for exceptions, and what constitutes a correct outcome.

A good candidate might be when an e-commerce order, after approval, automatically transfers to the enterprise resource planning system, inventory reservation and billing preparation start based on rules, and the warehouse immediately sees the task in its own system. Here, technology does not replace human decision-making. It eliminates the need for someone to record and verify the same data across multiple platforms.

The same applies to document processing. Basic data can be extracted from an incoming invoice or order, which can be prepared for further processing with proper verification. However, differing amounts, missing references, or unusual items can remain under human approval. Well-designed automation doesn't eliminate control; it places it where it's genuinely needed.

Therefore, the business outcome of automation is rarely just time savings. Errors may decrease, lead times may shorten, customer communication may improve, and reports may become more reliable. Managers don't receive a manually compiled snapshot on Friday afternoons but can rely on more unified data generated during operations.

The cost of a wrong order

A common mistake is that a growing company reacts to symptoms. There are many orders, so another spreadsheet is created. There are many emails, so a new ticketing system is introduced. There is much administration, so an automation tool is sought. These can be useful initiatives on their own, but without a shared process view, new tools only add another layer to existing operations.

The cost appears later. System integration becomes more complicated because it's unclear which system is the data source. The number of exceptions increases because the automation can't handle previously unspoken rules. Colleagues bypass the new solution because it doesn't follow the real work. Ultimately, the company still relies on spreadsheets and personal consultations, just with more systems in the background.

The other extreme is also risky: endless analysis. Not every process requires months of redesign. If it's a clearly repetitive, low-risk, and well-measurable administrative task, a targeted integration or automation can yield quick results. The key is a sense of proportion. Critical points in the process require more thorough examination, while over-planning can slow improvement for a simple notification or data transfer.

How should one decide?

The best starting point is not a technological list but a specific, recurring business situation. Choose a process that affects many people, is regularly delayed, produces errors, or requires disproportionately high managerial attention. Review the entire path from the initiating event to closure, not just the part where most complaints arise.

Assess the lead time, the number of manual touches, the rate of corrections, and the exceptions. This practice alone clarifies whether the underlying issue is a capacity problem, lack of information, poor responsibility structure, or a lack of system connectivity. A process improvement is manageable when based on observable facts, not just intuition.

After this, the appropriate intervention can be decided. It might be that simplifying a rule solves the problem. It might be that a data connection between two systems is the missing element. It might be that a custom internal application or production support interface provides better control than another spreadsheet. It might also be that automation is needed, but only for a clearly defined process step.

The useful first step is not to ask which tool automates faster. Instead, select a process and collectively state: does it truly make sense to operate this way, in this order?