Where to start with automation investment?

Current situation faced by the company

Labor costs are rising, and hiring new staff has become challenging. However, the volume of work that needs to be processed does not decrease. Many companies try to bridge this gap through automation, but when it comes time to start, they often stop at "What should we do first?"

The issue is not the absence of targets for automation. Rather, there are too many. Even companies with an enterprise resource management system spend a significant portion of actual work hours outside the system in the field. Typical examples include extracting purchase orders from emails and re-entering them into the system, copying tracking numbers from logistics sites to paste into client forms, and manually reconciling multiple sheets at the end of each period.

These tasks may seem trivial individually. Therefore, they often do not make it onto the improvement task list. However, if one person spends 90 minutes a day on such tasks, in an organization of 20 people, approximately 7,500 hours are lost annually. This equates to the workload of 3.5 full-time employees.

The greater loss is not time but errors and delays. The process of transcribing by hand inevitably leads to typos, and if the responsible person is absent, processing halts. This cost is not recorded in any ledger, so when problems arise, they manifest as customer complaints or delays in deadlines.

Why do automation projects fall short of expectations?

When automation implementation fails, the cause is mostly not technical but rather selection of targets. Three patterns tend to repeat.

First, I chose tasks dominated by exceptions. If more than half of the total cases involve exception handling, automation will create a new task of "verifying whether the automated processing results are correct" instead of reducing work. From the perspective of the person in charge, the workload has increased.

Secondly, the input data was not standardized. Purchase orders with different formats for each client and Excel files with changing item orders must undergo format standardization before automation. Skipping this step will only increase the exception handling logic.

Thirdly, there was no baseline to measure effectiveness. If you do not record the time required before implementation, you will only be left with the impression that "things seem faster." If you cannot prove the effectiveness relative to the investment, securing the budget for the next project will also be difficult.

All three issues can be assessed before starting. Therefore, a diagnosis is necessary.

First, distinguish between the two types of automation.

Before starting the diagnosis, it is helpful to categorize automation into two types to simplify decision-making.

Rule-based automation replaces tasks where conditions and processing methods are clearly defined. For example, "When a purchase order arrives, read the items and register them in the system," or "Every morning, send a list of items with stock below the threshold." The results are always the same, verification is easy, and the implementation costs are relatively low.

Automation requiring judgment deals with tasks where inputs vary each time and there is no single correct answer. This includes classifying free-form inquiries, extracting only necessary items from documents with varying formats, or responding to customer questions in sentences. The scope of processing is much broader, but it must be designed with the assumption that errors may occur.

The two types have different verification methods. Rule-based automation can be checked by seeing if it was done "exactly as specified," but for automation that requires judgment, tolerances and points of human intervention must be established in advance. If this distinction is not made and managed by the same criteria, issues will inevitably arise in the latter.

Step 4 Diagnostic Framework

Step 1 — Create a work inventory.

List repetitive tasks by department and record three points for each.

• Monthly occurrence count
• Time required per case
• Number of personnel handling the process

The goal of this stage is not accuracy but rather to create a comparable list. If you try to measure it down to the minute, the investigation itself will never finish. Ask the person in charge, "Approximately how many minutes does it take?" and write it down as is. The margin of error can be refined in later stages once candidates are narrowed down.

Experientially, in organizations of 2030 people, this list yields 4060 items. The process of creating the list itself is already useful. Often, repetitive tasks that even department heads were unaware of are revealed at this stage.

There is one thing to be cautious about during the investigation. Do not ask the responsible person, "What do you want to automate?" This will lead to the least desirable tasks being mentioned, rather than the most suitable ones for automation. It is more accurate to ask, "Please tell me what you did yesterday in chronological order."

Step 2 — Automation suitability assessment

Each task is evaluated across four axes.

Only tasks that are "suitable" across all four axes remain as primary candidates. If any are "unsuitable," classify them as tasks that must be resolved before automation. For example, if input standardization is inadequate, it is not an automation task but rather a format standardization task.

A simple way to assess rule clarity is to ask the person in charge, "Can this task be handed over to a new employee solely through documentation?" Tasks that cannot be handed over through documentation cannot be delegated to machines either.

Even if input standardization is inadequate, there is no need to give up immediately. This is an area that can be handled as automation requiring judgment. However, in this case, you must also design accuracy targets and inspection procedures, so allocate a longer preparation period than for rule-based tasks.

Step 3 — Determine the recovery period.

Conduct precise measurements only for primary candidates and calculate the payback period.

연간 절감액 = 월 건수 × 12 × 건당 절감 시간 × 시간당 인건비
회수 기간(월) = 구축 비용 ÷ ((연간 절감액 − 연간 운영비) ÷ 12)

There are three things to be cautious about.

When calculating hourly labor costs, consider total costs rather than just salaries. Including the four major insurances, retirement benefits, and office space, this typically amounts to 1.3 to 1.5 times the salary. If only the salary is considered, the savings will be underestimated, leading to the exclusion of valid projects.

The time saved per case is not 100%. Even after automation, time is required for result verification, exception handling, and system checks. To be conservative, calculate the savings as 70% of the existing time spent.

Be sure to reflect annual operating costs. This includes server costs, external API usage fees, and maintenance contracts. Calculating the payback period without this item will yield a shorter duration than reality.

Calculation example

When you input the figures, the judgment becomes clear. Below is a hypothetical example to illustrate the calculation method, and actual values will vary based on each company's conditions.

Assuming the task of transferring purchase orders received via email from clients into the internal system.

The time saved per task is 12 minutes × 70% = 8.4 minutes, or 0.14 hours.

연간 절감액 = 400 × 12 × 0.14 × 25,000 = 16,800,000원
연간 순효과 = 16,800,000 − 2,400,000 = 14,400,000원
회수 기간   = 18,000,000 ÷ (14,400,000 ÷ 12) = 15개월

A payback period of 15 months does not meet the previously stated criterion of "the first project should be within 6 months." In this case, there are three options: find other tasks with a higher volume, reduce the scope of construction to lower costs, or postpone this project to a later priority.

Applying the same calculation to 1,200 tasks per month results in annual savings of 50.4 million won, and the recovery period drops below 5 months. The key point of this calculation is that the number of tasks governs the recovery period. Tasks that occur frequently, even if they take less time per task, usually come first.

Step 4 — Determine the order of initiation.

Sort by shortest payback period, but do not choose the first task solely based on payback period. The conditions for the first task are twofold.

• Recovery period within 6 months
• Tasks that do not halt core operations even if they fail

The second condition is crucial. If the first automation causes issues in core operations, the attempt at automation itself loses trust within the organization. Conversely, a successful first case secures the budget and cooperation for subsequent projects. The first project should be chosen based on certainty rather than scale.

Candidates that emerge by industry

The tasks that typically emerge as primary candidates vary depending on the industry. Use this as a reference list when creating your inventory.

Manufacturing and Distribution — Collecting and inputting purchase orders by client, notifying of stock shortages, generating shipping instructions, collecting logistics invoice numbers and notifying customers, and monthly closing with multiple sheet reconciliations.

Service·B2B — Issuing quotes, tracking contract status and expiration notifications, issuing recurring invoices, classifying inquiry types and assigning responsible persons, summarizing consultation history.

E-commerce — Order status change notifications, classification of return/exchange requests, multi-channel synchronization of product information, collection and classification of reviews, restock notifications.

Common — Verification of attendance and expense reimbursement documents, issuance of accounts for new employees, collection of regular reports, and data synchronization between external systems.

This list is just a starting point. Only recognize actual candidates that pass the second-stage evaluation. Even the same task may have different exception rates and standardization of formats across companies.

Pre-implementation verification items

If a decision to proceed has been made, please ensure that the following five items are prepared.

Have you measured the baseline? You must record the time taken, number of tasks processed, and number of errors before implementation. If you start measuring after implementation, there will be no basis for comparison.

Is there a pathway for exceptions to be handed over to a person? There will inevitably be cases that automation cannot handle. At this point, it should not fail quietly but must be passed on to the responsible person. Without this pathway, you will discover missing cases days later.

Is there a way to notice when automation has stopped? Tasks that were previously performed by humans become noticeable when not done by them. Automation can quietly stop. At a minimum, there should be monitoring that alerts you if the number of processed items deviates from the norm.

Is the maintenance responsibility defined when the target system changes? The screens or APIs of the integration targets can change without notice. At this time, it must be specified in the contract or internal regulations who will fix it and by when.

Have you confirmed the personal information and regulatory requirements? If the automated tasks involve customer or employee information, there are items that need to be organized before starting.

• Where personal identifiable information is stored and how long it is retained during the processing
• If data is being sent to external services, where is that data stored?
• Is there a record of processing history that can be traced later?
• Are access rights differentiated by person in charge?

Especially when using external AI services, be sure to check in the contract whether the data you input will be used for the service's learning. If you input customer information without confirming this clause, the automation that technically works well becomes a violation of regulations. It is also necessary to leave a procedure for a person to verify the automation results in the same context.

Will you create it yourself or use something already available?

Once the target is determined, you need to choose the implementation method. The criterion for judgment is whether the task is a source of competitiveness.

If the way of handling tasks is a strength of the company that differs from competitors, it is better to tailor the solution accordingly. Conversely, for tasks that are handled in the same way by any company, using already validated solutions is faster and more cost-effective. Creating attendance settlement or electronic approval systems from scratch is mostly a waste.

However, when reviewing off-the-shelf products, please check three things.

Can we adapt our tasks to the product? Off-the-shelf products are created based on standard procedures. If the current method significantly deviates from that premise, the resistance to changing the workflow will outweigh the cost of modifying the product.

Can the data be extracted? This is necessary when transferring to another system or connecting with internal systems later. Please verify the data export functionality and integration method before signing the contract.

Who is responsible when it stops? Tasks that depend on external services mean that any failure of that service leads to a halt in our operations. Document the response times and compensation terms in case of a failure.

Common objections and their handling

Automation tasks often face more organizational barriers than technical ones. Knowing the anticipated objections in advance makes it easier to respond.

"There is no problem with the current method." This is usually true. The issue arises not in the present but when the volume of processing increases. Instead of presenting current inconveniences, highlight the limit point. It is more persuasive to calculate and show the maximum number of cases that can be handled with the current personnel.

"Will my job disappear?" This is the strongest objection and must be addressed directly. You need to clarify that the automation target involves simple repetitive tasks that the staff dislikes, and inform them where the saved time will be utilized. If this answer is not prepared, you will not gain cooperation from the investigation stage.

"There are too many exceptions for this to work." This statement from the field is usually accurate. Do not argue; instead, actually count the exception rate. This is the purpose of the second-stage evaluation. If you find a high number of exceptions, it is appropriate to remove that task from consideration.

"We tried it before but failed." Identify the specific causes of failure. Most often, it falls into one of the three patterns outlined earlier. You must present evidence that you will not repeat the same mistakes.

90 days after implementation

The start of operation is not the end but the beginning of verification. During the first 90 days, check the following.

First two weeks — Parallel operation. Run automation alongside the existing method and compare results. Discrepancies discovered during this period will indicate the actual exception rate. If you switch directly without parallel operation, you will discover incorrect processing weeks later.

First month — organize exception types. Classify the tasks that have been handed over to individuals by type. If a specific type is recurring, it is not an exception but rather a missing rule. Reflecting this in the rules will expand the scope of automatic processing.

3 months — Compare with the baseline. Measure and compare the time taken, number of tasks processed, and number of errors recorded before implementation. This comparison table will serve as the basis for the budget of the next task.

If the effectiveness fell short of expectations, be sure to document that fact. Knowing under what conditions automation does not perform as expected is the most valuable information when selecting the next project.

Organization

The success or failure of automation hinges more on the selection of targets than on the choice of tools.

• Create a list of repetitive tasks to make them comparable.
• Differentiate between rule-based automation and automation requiring judgment, and establish different validation methods accordingly.
• Only keep tasks where the rules are clear, inputs are standardized, and exceptions are minimal as candidates.
• Calculate the payback period conservatively, reflecting total labor costs and operating expenses. The number of occurrences dominates the results over the time per case.
• Choose the first task based on certainty, not scale.
• Confirm the scope of personal information processing and data storage location before starting.

And above all, measure the baseline before implementation. Improvements that are not measured cannot be proven, and unproven improvements will not receive budget allocations in the next cycle.