El copiloto de tu ERP no basta para automatizar tu empresa
Sage, SAP o Business Central resuelven lo que pasa dentro del ERP. El proceso que de verdad cuesta caro, el que cruza sistemas, queda fuera.
“Ya tenemos IA, viene con el ERP.” Se oye cada vez más en la primera llamada con una empresa industrial. El partner de Sage, de SAP o de Microsoft ha activado el copiloto que trae de serie, alguien ha visto una demo, y la conclusión parece razonable: si el ERP ya piensa solo, para qué contratar nada más.
Qué hace de verdad el copiloto de tu ERP (y qué no)
El copiloto de tu ERP automatiza lo que ya vive dentro de ese ERP: lee facturas, sugiere asientos, resume informes sobre sus propios datos. El trabajo que de verdad cuesta, el Excel puente entre sistemas, el pedido que se teclea dos veces, el cierre que cruza tres aplicaciones, queda fuera de su alcance.
Sage Copilot compone el asiento cuando ya tiene la factura dentro de Sage. El copiloto de Business Central sugiere una descripción de producto con los datos que ya están en Business Central. Hacen bien lo que anuncian, dentro de los límites de su propio sistema. Ese límite es justo el que importa, y el fabricante no tiene ningún incentivo en señalarlo.
Por qué el fabricante no te va a hablar de lo que queda fuera
El partner que te instala el copiloto de Sage vende licencias de Sage. El que te vende Business Central factura por Business Central y por las horas de configurarlo. Ninguno pierde nada por no mencionar que la mitad de tu trabajo manual pasa fuera de su sistema: no es su negocio arreglar eso, y de hecho reconocerlo abiertamente sería una razón para que llames a otro.
A nadie le pagan por decir “esto que le duele no lo resuelve mi producto”, y eso basta para explicar el silencio. La consecuencia práctica es que la única fuente de información sobre el alcance de un copiloto de ERP suele ser quien te lo vende, y quien te lo vende tiene un interés directo en que la respuesta sea “sí, con esto ya está”.
Hemos visto llamadas con empresas industriales que ya tenían el copiloto de su ERP activo desde hacía meses, con el partner encantado de la adopción, y con el mismo departamento de administración copiando datos a mano entre el ERP y el resto de sistemas todos los días. El copiloto funcionaba exactamente como prometía. El problema nunca había estado ahí. Por ejemplo, el pedido que un cliente confirma por email seguía teniendo que teclearlo alguien dos veces: una en el ERP y otra en el CRM, exactamente igual que antes de activar el copiloto.
El proceso que sí duele: el que cruza sistemas
El trabajo que se lleva las horas de un equipo de administración casi nunca ocurre dentro de un solo sistema. Ocurre en el puente: el pedido que llega por email y hay que teclear en el ERP, el informe del lunes que se monta copiando de tres pantallas distintas, la conciliación entre lo que dice el ERP y lo que dice la hoja de cálculo que lleva el comercial, el dato que hay que pasar del CRM al ERP y de vuelta porque ninguno de los dos habla con el otro.
Aquí conviene ser exacto, porque los fabricantes han empezado a asomarse a esa frontera. Business Central tiene desde 2025 un agente de cuentas a pagar que vigila el buzón de la empresa, extrae los datos de las facturas de proveedor que llegan por correo y las casa con los pedidos. Eso es cruzar la frontera de verdad, y funciona.
Pero fíjate en la letra pequeña: cubre un flujo concreto (la factura de proveedor que entra por email) y exige estar en la versión cloud reciente del producto. El pedido que confirma un cliente por correo, el informe que se monta de tres pantallas, la conciliación con la hoja del comercial: todo eso sigue fuera. Y si tu ERP es un Sage 200 en tu propio servidor o un desarrollo a medida de hace veinte años, esos agentes directamente no existen para ti.
La frontera no es un muro infranqueable; es una línea que el fabricante cruza solo donde le interesa y le resulta rentable, que es dentro de su propio ecosistema y en los flujos más estandarizados. El resto de tu trabajo manual vive al otro lado.
| Dentro del ERP (lo cubre el copiloto del fabricante) | Entre sistemas (lo que queda fuera) | |
|---|---|---|
| Ejemplo típico | Sugerir el asiento de una factura ya cargada en Sage | Pasar el pedido que llega por email al ERP y confirmarlo en el CRM |
| Quién lo construye | El propio fabricante, dentro de su producto (y en algún flujo estándar, algo más allá) | Nadie, salvo que alguien lo diseñe expresamente para tu caso |
| Quién tiene incentivo en resolverlo | El fabricante, porque vende más licencias de su ERP | Ninguna de las partes del stack actual, porque no es negocio de nadie en concreto |
| Dónde vive hoy el trabajo manual | Cada vez menos, según mejora el copiloto | Exactamente donde estaba, porque el copiloto no llega ahí |
Cómo saber cuál es tu caso
Dos preguntas bastan para saber si el copiloto de tu ERP resuelve lo que de verdad te cuesta, o si el dolor sigue estando en otro sitio.
- ¿El trabajo que más tiempo os quita empieza y termina en el mismo sistema? Si sí, es candidato al copiloto que ya tienes o al que te ofrece el fabricante. Si empieza en un correo, una llamada o un Excel y termina en el ERP, o al revés, no lo va a resolver ninguna IA que viva solo dentro de ese ERP.
- ¿Quién te ha dicho que “con esto ya está” tiene algo que ganar si sigues siendo su cliente? Esa pregunta separa un consejo neutral de una respuesta de venta. Un partner de un solo fabricante no puede recomendarte objetivamente salir de su stack, porque salir de su stack no es su negocio.
Si la respuesta a la primera pregunta es “cruza sistemas” y a la segunda es “el que me lo vende tiene interés en decir que sí”, ahí está el hueco. Ahí no falla tu ERP ni el copiloto que trae: es el límite estructural de cualquier producto que solo puede operar dentro de sí mismo.
Si no sabes si tu caso es de los que resuelve el copiloto que ya tienes o de los que necesitan algo distinto, eso es justo lo que responde un diagnóstico de procesos en tres semanas: qué pasa dentro de tu ERP, qué pasa entre sistemas, y por dónde conviene entrar. Lo hacemos sin vender licencias de ningún ERP concreto, así que la respuesta no depende de qué nos convenga a nosotros.
Si tu caso es justo lo contrario, un ERP tan antiguo que ni copiloto tiene, está tratado en integrar IA con un ERP antiguo sin cambiar de sistema, y si ese ERP corre en Cobol, en automatizar alrededor de un ERP en Cobol sin reescribirlo.
Escrito por Daniel Magarzo, CTO de Made to Scale, que se dedica a integrar estos sistemas.
