Tiempo de lectura: 13 minutos
Hay una pregunta que en muchas empresas lleva años contestándose sola: ¿nos planteamos cambiar el ERP? La respuesta era siempre la misma. Cuesta una fortuna, tarda meses, para el negocio mientras dura y, cuando acaba, tienes un sistema que guarda exactamente los mismos datos que el anterior. Lo mismo con el CRM, con el sistema de almacén o con el de planta.
Esa cuenta está cambiando, y no por una moda. La IA mueve las dos partes de la ecuación a la vez: abarata el trabajo más tedioso de migrar y, sobre todo, sube mucho el premio, porque un sistema nuevo ya no se limita a guardar el registro — puede hacer parte del trabajo que hoy hacen personas. Eso reabre una decisión que llevaba una década cerrada. No para todas las empresas: para las que tienen una estrategia ambiciosa, necesitan ejecutarla rápido y por iteraciones, y descubren que el sistema donde vive la operación es lo que marca el ritmo.
Qué es un sistema de registro y por qué nadie lo cambiaba
Un sistema de registro es donde tu empresa guarda la verdad sobre algo: los clientes, los pedidos, el stock, las nóminas, los asientos contables. No es "una herramienta más". Es la fuente que todos los demás consultan y la que se usa para discutir, para facturar y para responder ante una inspección.
Por eso cambiarlo daba tanto miedo. Migrar un ERP o un CRM significaba limpiar datos que nadie había limpiado nunca, mapear campos que alguien inventó hace doce años, reconstruir integraciones y reeducar a toda la plantilla. Un proyecto largo, caro y con riesgo real de parar la operación.
Y enfrente, el premio era pequeño. Pasabas de un sistema que guardaba registros a otro que guardaba los mismos registros con una interfaz más agradable. Nadie firma doce meses de proyecto por eso. El resultado es conocido: mercados enormes donde casi nadie cambia de proveedor, empresas atadas durante décadas a decisiones tomadas por gente que ya no trabaja allí.
El techo de la API: por qué la IA "por fuera" se queda a medias
La reacción sensata ante esto ha sido no tocar el sistema y poner la IA al lado: un asistente, un agente conectado por API que lee datos, los resume y propone algo. Funciona, y en muchos casos es lo correcto. Pero tiene un techo que conviene ver antes de invertir más en esa dirección.
El primer límite es lo que el agente puede ver. Una API expone los campos que alguien decidió exponer, no la historia de cada dato. Ve que un pedido está en estado 7, pero no que ese estado se usa desde 2019 para dos cosas distintas según el almacén. Ese contexto —el que separa una respuesta correcta de una respuesta plausible— vive dentro del sistema y en la cabeza de la gente, no en el endpoint. Es el problema del que hablo en ingeniería de contexto: el contexto es la mayor parte del resultado.
El segundo es lo que puede hacer. Leer es fácil; escribir es otra cosa. Un agente externo normalmente propone y una persona ejecuta, porque nadie quiere dar permisos de escritura amplios a algo que actúa por su cuenta sobre el sistema que sostiene la facturación. Así que el trabajo se ahorra a medias: la IA redacta, la persona copia, pega y confirma.
El tercero, y el más caro a largo plazo, es que el resultado se pierde. El agente propone un descuento, alguien lo aplica, el cliente compra o no compra. Ese desenlace queda en el CRM, pero no vuelve al agente como aprendizaje. Cada ejecución empieza casi de cero. No hay bucle.
Cuando esos tres límites aparecen a la vez en un proceso, la conversación deja de ser "qué agente pongo encima" y pasa a ser "dónde debería vivir esta lógica".
Qué cambia con la IA: baja el coste de migrar y sube el premio
Aaron Neil y Michael Brown, inversores de Battery Ventures, sostienen que la IA está alterando las dos partes de la ecuación de los systems of record — el análisis me llegó a través de la newsletter Suma Positiva, de Samuel Gil. Merece la pena separar las dos mitades, porque tienen pesos muy distintos.
El coste baja, pero solo en una parte. Limpiar datos, mapear campos entre dos modelos, transformar formatos, escribir los scripts de carga, documentar lo que hacía el sistema viejo leyendo su código: todo eso es trabajo mecánico, tedioso y muy automatizable. También ayuda a reconstruir la lógica de negocio que nadie documentó nunca. Lo que no baja es el resto: formar a la gente, rediseñar procesos, negociar contratos, aguantar los dos sistemas en paralelo, y el riesgo de tener a la operación medio parada. Quien venda una migración de ERP "con IA" como algo rápido, está vendiendo humo.
El premio sube mucho, y ahí está lo interesante. Antes migrabas para guardar lo mismo. Ahora puedes migrar a algo que, además de guardar, hace parte del trabajo. Eso cambia de dónde sale el retorno: ya no compites contra la cuota del software anterior, sino contra el coste de las horas que hoy se dedican a ese trabajo. Es un presupuesto de otro orden de magnitud.
Conviene decir también lo que esto todavía no es. Hoy hay pocos productos que hagan un proceso completo de principio a fin sin nadie mirando; la mayor parte de lo que se vende como "ERP con IA" es un asistente bien integrado, útil pero parcial. Los que sí ejecutan lo hacen en dominios acotados. Y la opción de construirlo propio, que la IA ha puesto al alcance de empresas medianas, sigue siendo un producto que hay que mantener: con equipo, con pruebas y con alguien que responda cuando falle. Nada de esto invalida la tesis; acota a quién le sale a cuenta.
Del sistema que guarda al sistema que hace: ejemplos por área
Esto se entiende mejor con casos concretos. En los cuatro, el patrón es el mismo: el sistema deja de esperar a que alguien le pida un dato y pasa a proponer o ejecutar un trabajo, con una persona que decide y responde.
Finanzas (ERP). Hoy el sistema guarda apuntes, facturas y asientos, y una persona dedica los primeros días del mes a cuadrar. Un sistema que hace el trabajo prepara el cierre, concilia lo que casa solo y deja encima de la mesa únicamente las excepciones, explicadas: esta factura no tiene albarán, este apunte se sale del patrón de los últimos doce meses. El trabajo de la persona pasa de buscar a decidir.
Ventas (CRM). Hoy guarda fichas, oportunidades y notas de reunión que casi nadie vuelve a leer. Un sistema que hace el trabajo redacta la propuesta con el histórico real de ese cliente, detecta que una oportunidad lleva tres semanas sin movimiento cuando las que se cierran nunca pasan de diez días, y avisa. No "envía correos automáticos": señala dónde mirar, con el motivo.
Logística. Hoy guarda stock, pedidos y albaranes, y la reposición depende de un punto de pedido fijado hace años y de la experiencia de dos personas. Un sistema que hace el trabajo propone la reposición cruzando ventas, plazos reales de cada proveedor y estacionalidad, replanifica una ruta cuando entra una incidencia, y deja escrito por qué lo propone para que quien decide pueda discutirlo.
Producción. Hoy guarda órdenes, partes de trabajo e incidencias. Un sistema que hace el trabajo reprograma el turno cuando cae una máquina, con las restricciones reales de personal, moldes y compromisos de entrega, y muestra qué pedido se retrasa en cada alternativa. La decisión sigue siendo del responsable de planta; lo que cambia es que la tiene en dos minutos y no en dos horas.
Fíjate en lo que tienen en común: ninguno es "un chatbot sobre mis datos". Son procesos completos, con su acción y su responsable. Es la diferencia entre una demo y un cambio, que es de lo que hablo en la última milla de la adopción de IA.
El bucle que solo se cierra dentro del sistema
Hay un motivo técnico por el que esto funciona mejor dentro que fuera, y es el que más se ignora al decidir.
Cuando los datos, la acción y el resultado viven en el mismo sitio, el sistema puede aprender de su propio uso. Propuso reponer 400 unidades, alguien lo bajó a 250, y seis semanas después hubo rotura de stock: eso es una señal, y está completa. El sistema sabe qué propuso, qué se decidió, quién lo decidió y qué pasó después. Un agente conectado por fuera ve, como mucho, el primer trozo.
Ese bucle es lo que convierte el uso en ventaja. Cuanto más se usa, más contexto acumula sobre cómo trabaja esta empresa; cuanto más contexto, mejores propuestas. Y es difícil de copiar, porque no está en el modelo: está en el historial de decisiones de tu operación.
Para el que construye producto, esto es exactamente la razón por la que empresas que empezaron resolviendo una tarea concreta —asistir al programador, revisar contratos, analizar llamadas de ventas— acaban convirtiéndose en el sistema central de esa actividad. No ganaron por tener mejor modelo, sino por quedarse con el bucle.
Para quién tiene sentido: estrategia ambiciosa y ejecución rápida
Este movimiento no es para mejorar la eficiencia un poco. Es para empresas que tienen una estrategia ambiciosa —entrar en un mercado, cambiar el modelo de servicio, duplicar la capacidad sin duplicar plantilla— y que necesitan ejecutarla rápido y por iteraciones, aprendiendo cada pocas semanas. Para ellas el sistema de registro no es un asunto de tecnología: es donde se ejecuta la estrategia. Si cada cambio de proceso pasa por una petición al proveedor y tres meses de espera, el sistema marca el ritmo de la empresa entera.
Se ve muy claro en las empresas que trabajan con OKR. Un objetivo del tipo "servir cualquier pedido en 24 horas" o "que la oferta salga el mismo día que se pide" se rompe en resultados clave que dependen de trabajo manual sobre el ERP o el CRM. Si trimestre tras trimestre el check-in dice lo mismo —no llegamos porque el proceso no da más de sí—, el freno no está en el equipo sino en el sistema donde vive el proceso. Es la lógica de OKR + IA: objetivos que la IA ayuda a ejecutar: que el objetivo tire de la tecnología, no al revés.
Y al contrario: si la estrategia es mantener lo que hay y crecer con el mercado, no hay motivo para asumir este riesgo. Esperar a que el proveedor incorpore estas capacidades es una decisión perfectamente defendible, y de hecho es la que yo daría por defecto.
Cuándo NO merece la pena moverse
Que la pregunta se reabra no significa que la respuesta sea que sí. Estos son los casos en los que yo no lo tocaría, o no todavía.
Cuando el problema son tus datos, no tu sistema. Si los maestros de artículo están duplicados, los estados no significan lo mismo en dos delegaciones y media empresa trabaja en hojas de cálculo paralelas, cambiar de sistema mueve el caos de sitio. Ese trabajo hay que hacerlo igual, y es más barato hacerlo antes.
Cuando tu proveedor va a hacerlo por ti. Los grandes fabricantes están metiendo estas capacidades en sus productos. Si tu caso no es especialmente particular y tu contrato no te ahoga, esperar puede ser la mejor decisión: te ahorras la migración y el riesgo. La pregunta útil para el próximo comité con tu proveedor es concreta: qué va a poder decidir el sistema sin intervención, con qué permisos, y en qué versión.
Cuando el proceso está muy regulado y la trazabilidad manda. No es un no, pero cambia el orden: primero se define quién responde de cada decisión automática y cómo se audita, y después se elige tecnología. Si no lo has hecho nunca, el AI Act obliga a bastante de esto y hay una política de uso de IA lista para adaptar.
Cuando no tienes a nadie que lo mantenga. Un sistema que decide necesita quien vigile qué decide. Si el plan es construirlo y olvidarse, acabará apagado o ignorado en seis meses. En una pyme sin equipo técnico propio, esto pesa más que cualquier otro factor.
Cuando el ahorro que persigues es de licencias. Es un mal motivo y la cuenta rara vez sale; lo conté con números en internalicé mi stack SaaS con IA. El motivo válido es el trabajo que el sistema pasa a hacer, no la factura mensual que dejas de pagar.
[ANÉCDOTA — Alex: aquí encaja un caso tuyo de una empresa que se planteó (o se está planteando) tocar su ERP, CRM o sistema de planta por este motivo. Formato: sector y tamaño sin identificar al cliente, qué proceso les dolía, qué opción se evaluó (agente por fuera / módulo del proveedor / sistema propio), qué decidieron y por qué, y cómo acabó. 4-6 frases. Si no hay caso todavía, este bloque se quita y no pasa nada.]
Cuatro criterios para decidir tu caso
En vez de discutir "ERP nuevo sí o no", que es una discusión que no se gana, yo la parto en cuatro preguntas que sí tienen respuesta. Se contestan por dominio (compras, almacén, cobros…), no para toda la empresa a la vez.
1. ¿Cuánto trabajo humano hay pegado a este registro? Cuenta horas reales de personas dedicadas a mover, cuadrar, revisar o decidir sobre esos datos cada mes. Si son pocas, el premio no existe y la conversación termina aquí.
2. ¿Cuánto de lo que hace falta para decidir bien está fuera del sistema? Si la respuesta correcta depende de conocimiento que solo tienen dos personas y de tres hojas de cálculo, hoy ninguna IA lo va a hacer bien —ni dentro ni fuera— hasta que ese conocimiento se escriba. Ese es el trabajo previo, y es el que casi nadie quiere hacer.
3. ¿Qué te deja hacer tu sistema actual? Concretamente: ¿puedes escribir en él desde fuera con permisos finos y trazabilidad? ¿Puedes sacar el histórico completo, no solo el estado actual? ¿Puedes extenderlo sin romper el soporte del fabricante? Tres noes seguidos es la señal más clara de que el techo es el sistema.
4. ¿Qué pasa el día que se equivoque? Si una propuesta errónea la ve una persona antes de ejecutarse y cuesta cinco minutos corregirla, el riesgo es asumible. Si se ejecuta sola y afecta a un cliente o a una declaración, necesitas control antes que capacidad.
Si los cuatro apuntan en la misma dirección, tienes un candidato. Si no, tienes un proceso que mejorar sin cambiar de sistema, que también es un buen resultado.
Un plan por dominios, sin big bang
La forma de equivocarse aquí es conocida: un proyecto de dos años para sustituirlo todo. La alternativa es ir por anillos, empezando por fuera.
| Fase | Qué haces | Qué tienes al final |
|---|---|---|
| 1. Elegir el dominio | Escoges un proceso periférico con mucho trabajo manual, bajo riesgo si falla y ligado a un objetivo que la empresa se ha marcado este año (si trabajáis con OKR, a un resultado clave que no avanza por culpa de ese proceso): reposición de consumibles, preparación de ofertas, conciliación de una cuenta. Le pones dueño con nombre. | Un caso acotado, un responsable y una medida: horas dedicadas hoy y errores hoy. |
| 2. Escribir lo que no está escrito | Documentas las reglas reales de ese proceso, incluidas las excepciones que todo el mundo conoce y nadie apuntó. Lo haces con la gente que lo ejecuta. | La base de contexto sin la cual nada de esto funciona, útil tanto si migras como si no. |
| 3. Probar por fuera primero | Montas la versión con agente conectado por API. Es más barata y rápida, y te dice si el problema es de capacidad o de acceso. | Una medida real de hasta dónde llegas sin tocar el sistema, y evidencia de dónde está el techo. |
| 4. Mover solo lo que el techo justifique | Si el techo era el sistema, llevas ese dominio —no toda la empresa— a un sistema que sí pueda ejecutar y registrar. Puede ser SaaS, puede ser propio, y conviven con lo viejo. | Un dominio funcionando de otra manera, con datos para decidir si sigue el siguiente. |
| 5. Cerrar el bucle | Registras qué propuso el sistema, qué decidió la persona y qué pasó después. Lo revisas cada mes con el dueño del proceso. | El activo que de verdad se acumula: el historial de decisiones de tu operación. |
Dos avisos sobre este plan. El primero: la fase 3 no es un trámite. Muchas empresas descubren ahí que con un agente por fuera les basta, y se ahorran la migración. Ese también es un buen final. El segundo: quien paga la fase 2 es el negocio, no tecnología. Escribir las reglas reales de un proceso es trabajo de quien lo ejecuta, y si no se le descuenta de su carga, no se hace.
Qué significa esto según tu papel
Si eres ingeniero o arquitecto: tu aportación más valiosa en esta conversación no es la comparativa de productos, es responder a la pregunta 3 con datos: qué permite y qué no permite el sistema actual, con ejemplos concretos de lo que has intentado y no has podido hacer. Eso es lo que convierte una discusión de opiniones en una decisión.
Si eres product manager o product owner: el patrón te suena, porque es el de siempre: cuándo un agente aporta valor de verdad y qué tareas tiene sentido automatizar. Aquí el producto es interno y el usuario es tu compañero de almacén, pero el criterio no cambia: empieza por el problema y por la medida, no por la capacidad.
Si eres coach o facilitador: el trabajo está en la fase 2. Hacer aflorar las reglas reales de un proceso —con sus excepciones y sus pactos no escritos— es exactamente lo que sabes hacer, y es el cuello de botella de todo lo demás. Un taller bien llevado aquí vale más que tres meses de piloto.
Si diriges una empresa o una pyme: la pregunta que tienes que poder contestar no es qué sistema comprar, sino qué decisiones estás dispuesto a delegar en un sistema, con qué control y quién responde si sale mal. Contestada esa, la elección técnica es mucho más sencilla. Si trabajas con OKR, mira qué resultados clave llevan trimestres estancados por un proceso manual: ahí tienes la lista de candidatos, ya priorizada. Y no hace falta que lo decidas todo hoy: por eso el plan va por dominios.
Preguntas frecuentes
¿Merece la pena cambiar de ERP para aprovechar la IA? Solo si tu estrategia exige ejecutar rápido y por iteraciones, el proceso que quieres mejorar tiene mucho trabajo humano pegado y tu sistema actual te impide escribir en él con permisos finos y trazabilidad. Si el freno es la calidad de tus datos o el conocimiento que no está escrito, cambiar de sistema no lo arregla. La forma sensata de averiguarlo es probar primero con un agente conectado por API: si eso resuelve el caso, no necesitas migrar.
¿Qué es un system of record y en qué se diferencia de una herramienta cualquiera? Un sistema de registro es donde la empresa guarda la información fundamental sobre clientes, empleados, finanzas o inventario: es la fuente de verdad que todos los demás sistemas consultan y la que se usa para facturar y para responder ante auditorías. Una herramienta se puede cambiar un martes; un sistema de registro arrastra procesos, integraciones y obligaciones legales, y por eso su sustitución es una decisión de negocio, no de tecnología.
¿Es mejor SaaS u on premise para un sistema con IA? La decisión no depende de la IA, sino de los mismos factores de siempre: qué datos manejas y qué obligaciones tienes sobre ellos, si necesitas particularizar mucho el proceso, y si tienes a alguien que lo mantenga. Lo que sí cambia es que hoy hay una tercera opción real —un sistema propio construido con asistencia de IA— que antes solo estaba al alcance de empresas grandes. Sigue necesitando ingeniería y mantenimiento.
¿Por qué un agente conectado por API se queda corto? Por tres límites que aparecen juntos: ve solo lo que la API expone y no la historia de cada dato, normalmente propone en vez de ejecutar porque nadie da permisos amplios de escritura sobre el sistema crítico, y el resultado de lo que propuso no le vuelve como aprendizaje. Sirve muy bien para asistir a una persona; se queda corto cuando lo que quieres es que cambie el proceso entero.
¿Cuánto se abarata realmente una migración con IA? Se abarata la parte mecánica: limpiar datos, mapear campos entre modelos, generar scripts de carga y reconstruir la documentación del sistema antiguo leyendo su código. No se abarata formar a la gente, rediseñar procesos, mantener dos sistemas en paralelo ni asumir el riesgo operativo, que suelen ser la mayor parte del coste real. Cualquier presupuesto que dé por barata la migración entera está ignorando esa mitad.
¿Por dónde empiezo si soy una pyme sin equipo técnico propio? Por un solo proceso periférico, con mucho trabajo manual y poco riesgo si falla, y por escribir sus reglas reales con la gente que lo ejecuta. Con eso hecho, prueba la opción más barata —un agente conectado por API— y mide horas y errores antes y después. Solo si ahí topas con un límite del sistema tiene sentido plantear un cambio, y aun así de ese dominio, no de todo.
Por dónde seguir
Si estás en la fase de saber si esto va contigo, el diagnóstico organizativo de IA te sitúa en media hora, y las 7 preguntas que un directivo debería hacerse sobre la IA sirven bien para llevar esta conversación a un comité de dirección. Si ya tienes el dominio elegido y lo que te falta es el contexto escrito, la guía de ingeniería de contexto es el material que yo usaría para la fase 2.
Recursos relacionados
- Internalicé mi stack SaaS con IA: los números reales (y cuándo NO hacerlo)
- ¿Internalizar el SaaS con una IA? Decide con nuestra calculadora
- Ingeniería de contexto: por qué el contexto es la mayor parte del resultado
- Cuándo un agente de IA aporta valor
- La última milla de la adopción de IA
- OKR + IA: objetivos que la IA te ayuda a ejecutar, no a inflar
- Diagnóstico organizativo de IA