Back to the list
Automation

Investment in process automation: where to start?

A four-phase diagnostic procedure to select automation initiatives based on data rather than intuition. It includes a suitability assessment table, the return period formula, sector-specific application examples, and pre-launch verification points, including those related to personal data and regulations.

The situation companies face today

Labor costs are rising, and hiring has become more challenging. However, the workload to be processed does not decrease. Many companies attempt to bridge this gap with automation, but when it comes to starting, they are halted by the question, 'Where should we begin?'.

The issue is not a lack of candidates for automation, but rather an excess of them. Even in companies with an enterprise resource planning system, a significant portion of actual working time is consumed outside the system. The most representative cases include: extracting an order from email and re-entering it into the system, copying the tracking number from the logistics provider's website and pasting it into the client's form, or manually reconciling multiple spreadsheets at each closing.

Taken individually, these tasks seem minor. Therefore, they rarely make it to the list of improvement initiatives. However, if a single person spends 90 minutes daily on this type of work, in an organization of 20 people, about 7,500 hours are lost annually: the equivalent of the workload of 3.5 full-time employees.

The greatest loss is not time, but errors and delays. In any manual transcription process, mistakes inevitably arise, and if the responsible person is absent, processing halts. Since this cost is not recorded in any accounting, when the problem comes to light, it has already manifested as a customer complaint or a delayed closing.

Why automation projects fail to meet expectations

When automation implementation fails, the cause is often not the technology, but rather the selection of the target. Three patterns repeat.

First: a process dominated by exceptions was chosen. If more than half of the cases require exception management, automation, instead of reducing work, creates new tasks: 'checking if the result of the automated processing is correct.' From the perspective of the responsible person, the burden has increased.

Second: the input data was not standardized. Orders with different formats depending on the supplier or spreadsheet files where the order of fields changes each time require prior normalization of the forms before automation. If this phase is omitted, the only thing that grows endlessly is the logic of exception management.

Third: there was no baseline to measure the effect. If the time spent before implementation is not measured, afterwards there is only the impression that 'it seems to be faster.' And if the effect of the investment cannot be demonstrated, budget approval for the next initiative will also be unattainable.

All three are issues that can be assessed before starting. Hence the need for a diagnosis.

First, distinguish the two types of automation

Before entering the diagnosis, separating automation into two categories simplifies the criteria.

Rule-based automation replaces tasks whose conditions and processing methods are clearly defined: 'when an order arrives, read the lines and register them in the system' or 'every morning send the list of items whose inventory is below the threshold.' The outcome is always the same, verification is straightforward, and the implementation cost is comparatively low.

Criteria-based automation addresses tasks where the input varies each time and the correct response is not singular. This includes classifying inquiries in free format, extracting only the necessary fields from documents with disparate formats, or responding in writing to customer questions. Its scope is much broader, but it must be designed with the premise that it can make mistakes.

The two types are verified differently. In rule-based automation, it is sufficient to check if what was intended has been done exactly, while in criteria-based automation, it is necessary to establish in advance the acceptable margin of error and the point of human intervention. If this distinction is not made and both are managed with the same criteria, problems will arise in the second case without exception.

Four-phase diagnostic framework

Phase 1 — Create a process inventory

List the repetitive processes by department and record three data points for each.

  • Number of cases per month
  • Time spent per case
  • Number of people processing it

The goal of this phase is not accuracy, but to obtain a comparable list. If you try to measure with minute precision, the study itself never concludes. Ask the responsible person how many minutes it approximately takes and note that figure. The margin of error can be refined later, once the list of candidates is reduced.

In my experience, in an organization of 20 to 30 people, this list yields between 40 and 60 entries. The exercise of creating it is already useful: it is common for repetitive tasks to emerge that even the department head was not aware of.

It is important to keep a warning in mind when conducting the study. Do not ask people what they would like to automate. Formulated this way, the response points to the task they dislike the most, not the one that is best suited for automation. It is more accurate to ask them to recount what they did the previous day, in chronological order.

Phase 2 — Assess suitability for automation

Evaluate each process according to four axes.

Evaluation axis Suitable Not suitable
Clarity of rules The decision criterion can be written in one sentence Depends on the experience and intuition of the person
Normalization of input The form and fields are fixed The format changes each time
Proportion of exceptions Less than 10 % More than 30%
System Accessibility Offers stable APIs or screens Screens that change frequently

Only retain processes that are deemed 'suitable' across the four dimensions as preliminary candidates. If any are deemed 'unsuitable', classify them as initiatives that need to be resolved before automation. For example, if the issue is with input normalization, it is not an automation initiative, but rather a form normalization initiative.

There is a simple method to assess the clarity of the rules: ask the responsible person if they could transfer that task to a newcomer solely with documentation. What cannot be transferred in writing cannot be transferred to a machine either.

Even if input normalization is deemed unsuitable, immediate abandonment is not necessary, as it is a domain that can be addressed with the criteria-based automation described earlier. However, in such cases, both the precision goal and the review procedure must be designed simultaneously, so it is advisable to anticipate a longer preparation period than in rule-based initiatives.

Phase 3 — Calculation of the payback period

Accurately measure only the preliminary candidates and calculate the payback period.

Ahorro anual = casos mensuales × 12 × horas ahorradas por caso × coste laboral por hora
Periodo de retorno (meses) = coste de implantación ÷ ((ahorro anual − coste operativo anual) ÷ 12)

Three issues must be addressed.

Calculate the labor cost per hour based on total cost, not on salary. Including mandatory social contributions, severance pay, and office space, it typically ranges from 1.3 to 1.5 times the salary. If only the salary is considered, the savings are underestimated, and initiatives that were actually reasonable are discarded.

The time savings per case is not 100%. Even after automation, time is spent checking results, managing exceptions, and reviewing the system. To be conservative, calculate savings as 70% of the time previously spent.

Always include the annual operating cost. This includes server costs, fees for external APIs, and maintenance contracts. A payback period calculated without this item will be shorter than the actual one.

Calculation Example

When substituting with figures, the criteria become clear. The following is a hypothetical example intended to illustrate the calculation method; actual values will vary based on each company's conditions.

Let’s assume the process of transferring customer orders received via email to the internal system.

Concept Value
Number of cases per month 400 cases
Time spent per case 12 minutos
Porcentaje de ahorro tras la automatización 70 %
Coste laboral total por hora 25.000 KRW
Coste de implantación 18.000.000 KRW
Coste operativo anual 2.400.000 KRW

El ahorro por caso es de 12 minutos × 70 % = 8,4 minutos, es decir, 0,14 horas.

Ahorro anual       = 400 × 12 × 0,14 × 25.000 = 16.800.000 KRW
Efecto neto anual  = 16.800.000 − 2.400.000 = 14.400.000 KRW
Periodo de retorno = 18.000.000 ÷ (14.400.000 ÷ 12) = 15 meses

Un periodo de retorno de 15 meses no alcanza el criterio antes señalado de que «la primera iniciativa esté dentro de los seis meses». En ese caso hay tres opciones: buscar otro proceso con mayor número de casos, reducir el alcance de la implantación para rebajar el coste, o posponer esta iniciativa a un puesto posterior.

Si se aplica el mismo cálculo a un proceso de 1.200 casos mensuales, el ahorro anual asciende a 50.400.000 KRW y el periodo de retorno cae por debajo de los cinco meses. La clave de este cálculo es que el número de casos domina el periodo de retorno. Por lo general, va antes un proceso breve pero frecuente que uno de larga duración por caso.

Fase 4 — Determinar el orden de ejecución

Ordene las iniciativas de menor a mayor periodo de retorno, pero no elija la primera atendiendo únicamente al periodo de retorno. La primera iniciativa debe cumplir dos condiciones.

  • Periodo de retorno inferior a seis meses
  • Un proceso cuyo fallo no detenga la actividad principal

La segunda condición es importante. Si la primera automatización causa problemas en un proceso esencial, dentro de la organización el propio intento de automatizar pierde credibilidad. A la inversa, un primer caso de éxito asegura el presupuesto y la colaboración del área de negocio para las iniciativas siguientes. Lo correcto es elegir la primera iniciativa por su certeza y no por su tamaño.

Candidatos que aparecen primero según el sector

Según el sector, los procesos que ascienden a candidatos preliminares están en general predeterminados. Utilice esta relación como lista de referencia al elaborar el inventario.

Fabricación y distribución — Recopilación e introducción de los pedidos por cliente, avisos de inventario por debajo del umbral, generación de órdenes de salida, recogida de los números de albarán del operador logístico y notificación al cliente, conciliación de múltiples hojas en el cierre mensual.

Servicios y B2B — Emisión de presupuestos, seguimiento del estado de los contratos y avisos de vencimiento, emisión periódica de facturas, clasificación del tipo de consulta y asignación de responsable, resumen del historial de atención.

Comercio electrónico — Notificación de los cambios de estado del pedido, clasificación de las solicitudes de devolución y cambio, sincronización multicanal de la información de producto, recopilación y clasificación de reseñas, avisos de reposición.

Comunes — Verificación de los justificantes de jornada y de gastos, alta de cuentas para las nuevas incorporaciones, recopilación de informes periódicos, sincronización de datos entre sistemas externos.

Esta lista es solo un punto de partida. Admita como candidatos reales únicamente los que superen la evaluación de la fase 2, porque un mismo proceso presenta proporciones de excepciones y grados de normalización distintos en cada empresa.

Puntos de verificación previos a la implantación

Si ya ha decidido empezar, compruebe que estén preparados los cinco puntos siguientes.

¿Ha medido la línea base? Debe dejar registrados el tiempo empleado, el número de casos tramitados y el número de errores previos a la implantación. Si empieza a medir después de implantar, no habrá término de comparación.

¿Está diseñada la vía para derivar las excepciones a una persona? Siempre se producirán casos que la automatización no pueda tramitar. En ese momento no debe fallar en silencio, sino pasar a la persona responsable. Sin esa vía, los casos omitidos se descubren varios días después.

¿Dispone de algún medio para detectar que la automatización se ha detenido? Cuando una persona deja de hacer su trabajo, se nota. La automatización se detiene en silencio. Como mínimo hay que contar con una vigilancia que envíe un aviso cuando el número de casos tramitados difiera de lo habitual.

¿Está definida la responsabilidad de mantenimiento para cuando cambie el sistema con el que se integra? Las pantallas o las API de los sistemas integrados cambian sin previo aviso. Debe estar establecido por contrato o por norma interna quién lo corregirá y en qué plazo.

¿Ha verificado los requisitos de protección de datos personales y de normativa? Si el proceso que va a automatizar maneja información de clientes o de empleados, hay aspectos que deben resolverse antes de empezar.

  • Dónde se almacena la información de identificación personal (PII) durante la tramitación y cuánto tiempo se conserva
  • Si los datos se transmiten a un servicio externo, en qué país quedan almacenados
  • Si queda un registro de la tramitación que permita la trazabilidad posterior
  • Si los permisos de acceso están diferenciados por persona responsable

En particular, si utiliza un servicio externo de inteligencia artificial, verifique siempre en las condiciones contractuales si los datos introducidos se emplean para el entrenamiento de dicho servicio. Si se introduce información de clientes sin comprobar esa cláusula, una automatización que técnicamente funciona bien se convierte en un incumplimiento normativo. Por la misma razón resulta necesario mantener un procedimiento en el que una persona verifique el resultado de la automatización.

Desarrollar a medida o utilizar algo ya existente

Una vez fijado el objetivo, hay que elegir la forma de implantarlo. El criterio de decisión es si ese proceso constituye una fuente de ventaja competitiva.

Si la manera de tramitarlo, distinta a la de la competencia, es precisamente el punto fuerte de la empresa, conviene desarrollarlo a medida. En cambio, si se trata de un proceso que todas las empresas realizan del mismo modo, resulta más rápido y más económico utilizar algo ya contrastado. Construir desde cero el control de jornada o la aprobación electrónica es, en la mayoría de los casos, un desperdicio.

Ahora bien, al evaluar un producto estándar, verifique tres cuestiones.

¿Podemos adaptar nuestros procesos al producto? Los productos estándar se construyen presuponiendo procedimientos normalizados. Si la forma de trabajar actual difiere mucho de esa premisa, la resistencia a cambiar los procesos resulta mayor que el coste de modificar el producto.

¿Podemos extraer los datos? Hará falta más adelante, al migrar a otra solución o al conectar con el sistema interno. Verifique antes de firmar la función de exportación de datos y el método de integración.

¿Quién responde cuando se detiene? En un proceso que depende de un servicio externo, una incidencia de ese servicio equivale a la interrupción de nuestra actividad. Deje verificados por escrito los tiempos de respuesta ante incidencias y las condiciones de compensación.

Objeciones habituales y cómo tratarlas

Las iniciativas de automatización se atascan con más frecuencia en la organización que en la tecnología. Conocer de antemano las objeciones previsibles facilita la respuesta.

«El método actual no da problemas». Suele ser cierto. El problema no está en el presente, sino en el momento en que aumente el volumen de tramitación. Ante esta objeción, no presente la incomodidad actual, sino el punto límite. Resulta más persuasivo calcular y mostrar el número máximo de casos que la plantilla actual puede tramitar.

«¿No desaparecerá mi puesto?». Es la objeción más intensa y hay que responderla de frente. Debe explicarse de antemano que lo que se automatiza es el trabajo repetitivo y sencillo que la propia persona no deseaba hacer, y a qué se destinará el tiempo liberado. Si esa respuesta no está preparada, no se obtendrá colaboración ni siquiera en la fase de estudio.

«Hay demasiadas excepciones, no va a funcionar». Esta afirmación del área de negocio suele ser exacta. No la rebata: cuente realmente la proporción de excepciones. Ese es justamente el propósito de la evaluación de la fase 2. Si al contarlas resulta que son muchas, lo correcto es retirar ese proceso de la lista de candidatos.

«Ya lo intentamos antes y fracasó». Averigüe con detalle la causa del fracaso. En la mayoría de los casos se trata de uno de los tres patrones descritos anteriormente. Hay que demostrar con argumentos que no se va a repetir el mismo error.

Los 90 días posteriores a la implantación

La puesta en marcha no es el final, sino el comienzo de la verificación. Durante los primeros 90 días, compruebe lo siguiente.

Primeras dos semanas — Operación en paralelo. Ejecute a la vez la automatización y el método anterior y contraste los resultados. Las discrepancias detectadas en este periodo revelan la proporción real de excepciones. Si se cambia de golpe sin operar en paralelo, los tratamientos erróneos se descubren varias semanas después.

Primer mes — Clasificación de los tipos de excepción. Clasifique por tipos los casos derivados a personas. Si un tipo concreto se repite, no es una excepción, sino una regla omitida. Al incorporarla a las reglas, se amplía el alcance del tratamiento automático.

Tres meses — Comparación con la línea base. Vuelva a medir el tiempo empleado, el número de casos tramitados y el número de errores que había registrado antes de la implantación, y compárelos. Esa tabla comparativa será la justificación presupuestaria de la siguiente iniciativa.

Si el efecto no alcanzó lo previsto, deje también constancia de ello. Saber en qué condiciones la automatización no funciona como se esperaba es la información más valiosa a la hora de elegir la siguiente iniciativa.

Resumen

El éxito o el fracaso de la automatización se decide más en la selección del objetivo que en la elección de la herramienta.

  • Elabore una lista de los procesos repetitivos para hacerlos comparables.
  • Distinga la automatización basada en reglas de la automatización basada en criterio y aplique a cada una un método de verificación distinto.
  • Conserve como candidatos únicamente los procesos con reglas claras, entradas normalizadas y pocas excepciones.
  • Calcule el periodo de retorno de forma conservadora, incorporando el coste laboral total y los costes operativos. El número de casos domina el resultado más que el tiempo por caso.
  • Elija la primera iniciativa por su certeza y no por su tamaño.
  • Verifique antes de empezar el alcance del tratamiento de datos personales y la ubicación de almacenamiento de los datos.

Y, sobre todo, mida la línea base antes de la implantación. Una mejora que no se ha medido no puede demostrarse, y a una mejora no demostrada no se le asigna el siguiente presupuesto.

Contáctenos

¿Necesita soluciones de IA, desarrollo de ERP, un sitio web responsivo o una app móvil?

Le propondremos el enfoque de desarrollo óptimo y la estrategia de construcción a medida de su entorno de negocio y sus flujos de trabajo.

Iniciar un proyecto