Invertir en Automatización de Procesos Empresariales: ¿Por Dónde Empezar?

La situación que enfrentan las empresas hoy

Los costos laborales están aumentando y la contratación se ha vuelto más difícil. Sin embargo, el volumen de trabajo a procesar no ha disminuido. Muchas empresas intentan cerrar esa brecha con la automatización, pero cuando llega el momento de comenzar, se estancan en la pregunta de qué abordar primero.

El problema no es la falta de cosas para automatizar. Es que hay demasiadas. Incluso las empresas con un sistema completo de planificación de recursos empresariales dedican una parte sustancial de las horas de trabajo reales fuera del sistema. Sacar una orden de compra de un correo electrónico y volver a escribirla en el sistema, copiar un número de seguimiento del sitio web de un proveedor logístico en una plantilla de cliente, reconciliar manualmente varias hojas de cálculo en cada cierre de periodo: estos son los casos típicos.

Individualmente, estas tareas parecen triviales. Por eso rara vez llegan a una lista de mejoras. Pero si una persona pasa 90 minutos al día en trabajos de este tipo, una organización de 20 personas pierde aproximadamente 7,500 horas al año. Esa es la carga de trabajo de 3.5 empleados a tiempo completo.

La mayor pérdida no es tiempo, sino errores y retrasos. La transcripción manual siempre produce errores tipográficos, y el procesamiento se detiene siempre que la persona responsable está ausente. Como este costo no se registra en ningún libro contable, para cuando se manifiesta, ya ha tomado la forma de una queja del cliente o un plazo perdido.

Por qué los proyectos de automatización no cumplen con las expectativas

Cuando una iniciativa de automatización falla, la causa generalmente no radica en la tecnología, sino en la selección de candidatos. Tres patrones se repiten.

Primero, el proceso elegido estaba dominado por excepciones. Si más de la mitad de todos los casos requieren manejo de excepciones, la automatización no reduce el trabajo; crea una nueva tarea de verificar si el resultado automatizado es correcto. Desde el punto de vista del operador, la carga de trabajo ha aumentado.

Segundo, los datos de entrada no estaban estructurados. Las órdenes de compra cuyo formato varía según el proveedor, o las hojas de cálculo cuyo orden de columnas cambia cada vez, requieren estandarización de formato antes de cualquier automatización. Si se omite ese paso, la lógica de manejo de excepciones simplemente sigue creciendo.

Tercero, no había una línea base contra la cual medir el efecto. Si el tiempo de procesamiento no se registra antes de la implementación, todo lo que queda después es la impresión de que las cosas "parecen más rápidas". Donde no se puede demostrar el retorno de la inversión, el presupuesto para la próxima iniciativa tampoco se asegura.

Las tres son preguntas que se pueden resolver antes de que comience el trabajo. Por eso se necesita un diagnóstico.

Distinguir los dos tipos de automatización primero

Antes de comenzar el diagnóstico, dividir la automatización en dos tipos mantiene el juicio simple.

La automatización basada en reglas asume trabajos cuyas condiciones y manejo están claramente definidos. Tareas como "cuando llega una orden de compra, leer los artículos y registrarlos en el sistema" o "cada mañana, enviar una lista de artículos cuyo stock ha caído por debajo del umbral". La salida es siempre la misma, la verificación es sencilla y el costo de construcción es comparativamente bajo.

La automatización basada en juicio se ocupa de trabajos donde la entrada varía cada vez y no hay una única respuesta correcta. Clasificar consultas en formato libre, extraer solo los campos requeridos de documentos con diseños inconsistentes, o responder preguntas de clientes en prosa caen en esta categoría. Su alcance es mucho más amplio, pero debe ser diseñado bajo la suposición de que puede estar equivocado.

Los dos tipos se verifican de manera diferente. Para la automatización basada en reglas, es suficiente comprobar si hizo exactamente lo que se especificó, mientras que la automatización basada en juicio requiere que la tolerancia al error y el punto de intervención humana se definan de antemano. Gestionar ambos bajo el mismo estándar sin hacer esta distinción inevitablemente causará problemas.

Un marco de diagnóstico en cuatro etapas

Etapa 1 — Crear un inventario de tareas

Liste las tareas repetitivas en cada departamento y registre tres cosas para cada una.

• Volumen mensual
• Tiempo por caso
• Número de personas que lo manejan

El propósito de esta etapa no es la precisión, sino una lista comparable. Intentar medir hasta el minuto y la encuesta en sí nunca terminará. Pregunte a la persona que realiza el trabajo aproximadamente cuántos minutos le toma y anote la respuesta. Refinar el margen de error es suficiente más tarde, una vez que se hayan reducido los candidatos.

En la práctica, una organización de 20 a 30 personas produce una lista de 40 a 60 elementos. El acto de compilar la lista ya es útil en sí mismo. Las tareas repetitivas que ni siquiera el jefe del departamento conocía a menudo salen a la luz en esta etapa.

Una precaución al encuestar. No pregunte a las personas qué les gustaría automatizar. Enmarcado de esa manera, obtendrá el trabajo que más desprecian, no el trabajo más adecuado para la automatización. Pedirles que describan lo que hicieron ayer en orden cronológico es más preciso.

Etapa 2 — Evaluar la idoneidad de la automatización

Evalúe cada tarea a lo largo de cuatro ejes.

Mantenga como candidatos de primera ronda solo aquellas tareas clasificadas como "adecuadas" en los cuatro ejes. Si algún eje es "inadecuado", clasifique la tarea como una cuya precondición debe resolverse antes de la automatización. Donde la estructura de entrada es inadecuada, por ejemplo, esta no es una iniciativa de automatización sino una iniciativa de estandarización de formato.

Hay una manera sencilla de juzgar la claridad de las reglas. Pregunte a la persona que realiza el trabajo si podría entregar la tarea a un nuevo integrante utilizando solo la documentación. El trabajo que no se puede entregar en papel tampoco se puede entregar a una máquina.

Una calificación inadecuada en la estructura de entrada no es motivo inmediato para el abandono, porque este es un terreno que la automatización basada en juicio, como se distingue arriba, puede cubrir. En ese caso, sin embargo, el objetivo de precisión y el procedimiento de revisión deben diseñarse junto con ello, por lo que se debe permitir un período de preparación más largo que para una iniciativa basada en reglas.

Etapa 3 — Calcule el período de recuperación

Realice mediciones precisas solo para los candidatos de primera ronda, luego calcule el período de recuperación.

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

Tres puntos requieren cuidado.

Establezca el costo laboral por hora sobre una base completamente cargada, no solo sobre el salario. Incluyendo seguros legales, provisiones de indemnización y espacio de oficina, típicamente llega a 1.3 a 1.5 veces el salario. Establezca esta cifra solo en salario y los ahorros se subestiman, causando que iniciativas realmente sólidas sean rechazadas.

El tiempo ahorrado por caso no es del 100%. Incluso después de la automatización, el tiempo se destina a verificar resultados, manejar excepciones y monitorear el sistema. Para una estimación conservadora, cuente el 70% del tiempo de procesamiento existente como el ahorro.

Siempre tenga en cuenta el costo anual de funcionamiento. Los costos de servidor, tarifas de API externas y contratos de mantenimiento pertenecen aquí. Un período de recuperación calculado sin este ítem resulta más corto que la realidad.

Un ejemplo trabajado

Sustituir cifras hace que el juicio sea claro. Lo siguiente es un ejemplo hipotético destinado a ilustrar el método de cálculo; los valores reales diferirán según las circunstancias de cada empresa.

Suponga la tarea de transferir órdenes de compra recibidas por correo electrónico de proveedores a un sistema interno.

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.