26 de febrero de 2026RPA4 min de lectura

RPA para pymes: qué es y qué merece la pena automatizar

RPA suena a consultora grande y a proyecto de un año. En realidad describe algo muy sencillo: un programa que hace el trabajo repetitivo que hoy hace una persona con el ratón. Aquí va lo que funciona, lo que no y cuándo tiene sentido.

RPA son las siglas de Robotic Process Automation, y es de esos nombres que hacen más daño que bien. No hay ningún robot. Lo que hay es un programa que repite una tarea que hoy hace alguien a mano: abrir un fichero, copiar unos datos, pegarlos en otro sitio, comprobar que cuadra y mandar un correo.

Si en tu empresa alguien dedica una hora al día a mover información de un sitio a otro, eso es un candidato a RPA. Y probablemente no lo hayas pensado nunca como un proyecto de tecnología, porque no lo parece: parece «la tarea de los lunes».

Qué se automatiza bien

El RPA brilla cuando la tarea cumple tres condiciones: es repetitiva, sigue reglas claras y trabaja con datos que ya existen en algún sitio. Por ejemplo:

• Sacar los pedidos de un correo o de un portal y meterlos en el sistema.
• Copiar altas de clientes de un formulario a la base de datos.
• Cruzar dos listados y sacar las diferencias.
• Montar el mismo informe cada semana con los mismos datos.
• Renombrar, clasificar y archivar documentos que llegan.
• Avisar cuando algo se sale de lo normal: un pago que no entra, un stock que baja.

En la Clínica Podológica Valdenoja el trabajo era exactamente de este tipo: el historial repartido entre carpetas, fichas y memoria, y las cuentas esperando a fin de mes entre tickets y libretas. No hacía falta inteligencia artificial: hacía falta que el sistema hiciera lo que se estaba haciendo a mano.

Qué NO se automatiza bien

Aquí es donde se rompen los proyectos. El RPA es malo cuando:

La tarea depende del criterio de una persona

«Si el cliente es de los buenos, le damos margen». Eso no es una regla, es un juicio. Se puede automatizar si consigues escribir la regla; si no consigues escribirla, no la automatices: acabarás con un sistema que decide mal.

El proceso cambia cada dos meses

Automatizar un proceso inestable es pagar dos veces: una por construirlo y otra por rehacerlo. Si un proceso está en discusión, primero se cierra y después se automatiza.

El proceso está mal de raíz

Este es el más importante y el que más se ignora. Si una tarea existe solo porque dos programas no se hablan, la respuesta buena no es un robot que haga de puente: es que se hablen. Automatizar un proceso absurdo lo hace más rápido, no mejor.

Cuándo merece la pena en una empresa pequeña

No hace falta un volumen enorme. La cuenta que hacemos es más sencilla:

• Horas al mes. Cuántas horas se van hoy en la tarea.
• Errores. Cuánto cuesta cuando sale mal: un pedido perdido, una cita mal dada, un cobro que no se reclama.
• Cuello de botella. Si esa tarea solo la sabe hacer una persona, la empresa está atada a que esa persona esté.

El tercer punto es el que más se subestima. Muchas automatizaciones no se pagan con las horas que ahorran, se pagan el día que esa persona está de baja o se va.

¿RPA o software a medida?

Es la duda razonable. La diferencia práctica:

RPA es poner una capa por encima de lo que ya tienes, sin tocarlo. Es rápido, es barato y es reversible. Es lo indicado cuando el programa de fondo no se puede cambiar, o cuando no quieres cambiarlo todavía.

Software a medida es rehacer la pieza. Cuesta más y tarda más, pero el resultado no es un puente: es que el problema desaparece. Lo desarrollamos en software a medida o de catálogo.

Nuestra regla es simple: si la tarea es un parche entre dos sistemas que van a seguir ahí muchos años, RPA. Si la tarea es el síntoma de que falta una herramienta, la herramienta.

Cómo se empieza

Con una sola tarea, la más aburrida que tengas, y midiendo antes. Cuánto tiempo cuesta hoy y cuántos errores da. Sin ese antes no hay forma de saber si el después es mejor, y todo el mundo se salta ese paso.

Después se automatiza esa tarea y solo esa. Cuando lleve un mes funcionando sin que nadie la mire, se coge la siguiente. Los proyectos de automatización que fracasan casi siempre empezaron intentando resolver diez cosas a la vez.

Preguntas frecuentes