PROGENCuando alguien nos pregunta cuánto cuesta automatizar un proceso, la respuesta honesta es que depende de cosas que casi nunca están en el correo de la consulta. No del software, ni de la moda tecnológica del momento, sino de lo ordenado que esté el proceso, de cuántos sistemas hay que tocar y de cuántas excepciones tolera el negocio.
Esto genera una situación incómoda: pides tres presupuestos, te llegan cifras que van de 3.000 a 40.000 euros y no tienes forma de saber cuál es razonable. No porque alguien mienta, sino porque cada proveedor ha entendido un alcance distinto.
Este artículo te da el marco para estimar tú mismo el rango antes de sentarte con nadie. No para ahorrarte la conversación, sino para tenerla en igualdad de condiciones.
Las cinco variables que mueven el precio de verdad
1. Cuántos sistemas hay que conectar y cómo
Es, con diferencia, el factor que más dispara el coste. Automatizar dentro de un único sistema (por ejemplo, reglas y flujos en tu CRM) es barato. Mover información entre tres o cuatro herramientas ya es un proyecto.
La pregunta clave no es cuántos sistemas, sino qué tipo de puerta de entrada tiene cada uno:
- API documentada y moderna: coste bajo. Es el escenario cómodo.
- API antigua, con limitaciones de llamadas o autenticación rara: coste medio, y suele aparecer sorpresas.
- Solo exportación de ficheros (CSV, Excel) o acceso a base de datos: coste medio, pero previsible.
- Sin API, solo interfaz web o de escritorio: hay que recurrir a automatización de la interfaz. Coste alto y, sobre todo, mantenimiento alto, porque cualquier cambio visual en el programa rompe el robot.
Si tu ERP es una instalación local de hace doce años sin API, esa línea del presupuesto va a pesar más que todo lo demás junto.
2. El grado de variabilidad del proceso
Un proceso con reglas cerradas —si el campo A es X, haz Y— se automatiza rápido. Un proceso donde una persona "mira y decide" es otra cosa.
La pregunta que hacemos siempre en la primera reunión es: *de cada 100 casos, ¿cuántos siguen el camino estándar?* Si la respuesta es 95, el proyecto es acotable. Si es 60, hay que diseñar todo el circuito de excepciones, y ese circuito suele costar más que el flujo principal.
Una regla práctica: el coste no crece con el volumen, crece con la casuística. Procesar 10.000 facturas iguales es más barato que procesar 300 con quince formatos distintos.
3. La calidad de los datos de entrada
Un albarán en PDF nativo, siempre con la misma plantilla, es un problema resuelto. Un albarán escaneado torcido, con sello encima del número de pedido y en cuatro idiomas, es un proyecto de reconocimiento documental con validación humana.
Aquí conviene ser realista: si necesitas extracción de datos de documentos heterogéneos, presupuesta también la fase de revisión. Ningún sistema, ni con modelos de lenguaje por detrás, va a darte el 100% sin control. Lo que sí puedes conseguir es que el 85% pase solo y el resto llegue a una bandeja de revisión con el dato ya precargado.
4. Las consecuencias de un error
Automatizar el envío de un correo de seguimiento y automatizar una transferencia bancaria cuestan cosas distintas aunque técnicamente se parezcan. Lo que encarece el segundo caso son las capas alrededor: validaciones dobles, registro de auditoría, alertas, procedimiento de reversión, pruebas exhaustivas antes de pasar a producción.
Si el proceso toca facturación, nóminas, datos personales sensibles o comunicaciones con la Administración, multiplica la parte de pruebas y control por dos. No es inflar el presupuesto: es lo que hace que puedas dormir.
5. Quién lo va a mantener
Un proyecto de automatización no termina el día de la entrega. Cambia el proveedor de correo, tu gestoría actualiza el formato del fichero, alguien añade un campo obligatorio en el CRM. Todo eso rompe cosas.
Hay dos modelos y conviene decidir cuál quieres antes de pedir precio:
- Entrega y te lo quedas: coste inicial más alto (documentación, formación, código legible) y responsabilidad interna después.
- Servicio gestionado: coste inicial menor y una cuota mensual. Sale a cuenta si no tienes perfil técnico en plantilla.
Un presupuesto que no menciona el mantenimiento está incompleto, aunque parezca más barato.
Un método para estimar antes de pedir presupuesto
No necesitas ser técnico. Necesitas media hora y honestidad con las respuestas.
Paso 1. Mide el proceso actual. Cuántas veces se ejecuta al mes, cuántos minutos consume cada ejecución, cuánta gente interviene. Multiplica por el coste hora cargado (salario bruto más costes sociales, dividido entre horas efectivas). Esto te da el techo anual de lo que tiene sentido invertir.
Paso 2. Cuenta los puntos de contacto. Escribe la lista de sistemas, ficheros, buzones y personas que tocan el proceso de principio a fin. Cada elemento de esa lista es una integración potencial.
Paso 3. Estima el porcentaje de casos estándar. Pregúntaselo a quien ejecuta el proceso, no a quien lo supervisa. Suelen dar respuestas muy distintas.
Paso 4. Clasifica el proyecto. Con lo anterior, la mayoría de procesos caen en uno de tres perfiles:
- Sencillo: uno o dos sistemas con API, reglas claras, sin documentos. Semanas de trabajo, no meses. Se recupera normalmente en el primer año.
- Medio: tres o cuatro sistemas, alguna extracción de datos, un circuito de excepciones acotado. Es el grueso de los proyectos reales.
- Complejo: sistemas sin API, documentos heterogéneos, decisiones con criterio humano, requisitos de auditoría. Aquí conviene partir el proyecto en fases y automatizar primero el tramo más repetitivo.
Paso 5. Compara con el paso 1. Si el coste estimado supera el ahorro anual, no significa que haya que descartarlo: puede compensar por reducción de errores, por capacidad de crecer sin contratar o por plazos de respuesta al cliente. Pero conviene que ese argumento esté escrito, no sobreentendido.
En nuestros proyectos de automatización de procesos dedicamos la primera fase precisamente a esto: cerrar el alcance real antes de escribir una línea de código, porque un alcance mal definido es la causa habitual de que un presupuesto se duplique a mitad de camino.
Cómo leer un presupuesto de automatización
Cuando te lleguen las propuestas, busca estas cinco cosas. Si faltan, pregunta.
- Desglose por fases, no un precio único. Análisis, desarrollo, pruebas, puesta en marcha y formación deberían aparecer separados.
- Qué pasa con las excepciones: dónde van los casos que el sistema no sabe resolver y quién los ve.
- Propiedad del desarrollo: si mañana cambias de proveedor, ¿te llevas el código y las credenciales o empiezas de cero?
- Licencias de terceros: muchas plataformas de automatización cobran por ejecución o por usuario. Ese coste es tuyo y crece con el volumen.
- Condiciones de mantenimiento: qué incluye, qué no, y qué pasa si un sistema externo cambia.
Dos casos en los que no merece la pena
Por coherencia con lo anterior: hay procesos que es mejor no automatizar.
El primero, los que están a punto de cambiar. Si vas a migrar de ERP el año que viene, automatizar sobre el sistema actual es tirar dinero. Espera o automatiza solo la parte que sobrevivirá a la migración.
El segundo, los que se ejecutan poco y mal. Un proceso de cinco veces al mes que además nadie tiene claro cómo funciona no es un candidato a automatización: es un candidato a que alguien lo documente y lo simplifique primero. Muchas veces, al ordenarlo, descubres que la mitad de los pasos no hacían falta y el ahorro llega sin tecnología.
Preguntas frecuentes
¿Se puede dar una horquilla de precio sin ver el proceso?
Se puede dar un orden de magnitud, no un precio. La diferencia entre un proceso de dos sistemas con API y uno que depende de un programa sin interfaz de integración es de un factor de cinco o más, y eso no se adivina por teléfono. Cualquier cifra cerrada dada antes del análisis va con un margen de seguridad grande metido dentro, y ese margen lo pagas tú.
¿Es más barato usar una plataforma sin código?
En la puesta en marcha, casi siempre sí. A medio plazo depende del volumen: muchas plataformas facturan por número de ejecuciones o de tareas, y un proceso de alto volumen puede acabar costando más en licencias de lo que costó construirlo. Nuestra recomendación es calcular el coste de licencia a tres años con el volumen previsto, no con el actual.
¿Cuánto tarda en amortizarse?
Para procesos sencillos y repetitivos, lo habitual es que el retorno se vea dentro del primer año. En proyectos medios, entre doce y veinticuatro meses. Si la estimación te sale por encima de tres años, revisa el alcance: probablemente estés intentando automatizar de golpe algo que conviene hacer por fases, empezando por el tramo de mayor volumen.
¿Qué necesito tener preparado antes de la primera reunión?
Con tres cosas basta: el proceso descrito en pasos, aunque sea en un documento improvisado; la lista de sistemas implicados con su versión y si son locales o en la nube; y una estimación del volumen mensual y del porcentaje de casos que se salen de lo normal. Con eso se puede cerrar un alcance realista en una sola sesión.