¿Sustituirá la IA a los ERP tradicionales?

Durante las dos últimas décadas he trabajado en implantaciones de ERP, en datos operativos y en negocios de retail en fases de madurez muy distintas. Un patrón ha resultado sorprendentemente persistente: una empresa puede invertir mucho en un ERP y seguir preparando el informe semanal del propietario combinando a mano varios archivos de Excel.

Rara vez el problema es que falte software. Lo más habitual es que distintos sistemas contengan definiciones, procesos y versiones diferentes de la misma realidad del negocio. Alguien tiene que juntarlos, decidir de qué cifras fiarse y explicar el resultado a la dirección. Por el camino se pierde o se reinterpreta información, la gente repite el mismo trabajo cada mes, y rastrear una cifra dudosa hasta su origen se vuelve difícil. He escrito aparte sobre lo que eso le cuesta a un negocio en el día a día.

En muchos negocios de retail y hostelería este problema básico de reporting aún no está resuelto. Las expectativas, mientras tanto, han ido mucho más allá del reporting. Las empresas quieren ahora un sistema que detecte una desviación relevante, ofrezca una explicación, ponga en marcha una respuesta y, con el tiempo, diga si esa respuesta produjo un resultado medible.

Cuando el análisis se convierte en acción

Imagina que el margen de una categoría empieza a caer en varias tiendas. Un sistema de BI tradicional lleva el cambio a un cuadro de mando. Todavía hace falta que alguien lo vea, investigue la causa, decida qué hacer, comunique la decisión y vuelva más tarde a comprobar si funcionó.

Un sistema más capaz examinaría la estructura de la caída: si subió el peso de los productos de bajo margen, si una promoción funcionó de forma distinta a lo previsto, si se movieron los precios de compra, si faltaron productos clave, si cambió el mix de ventas. Después podría proponer una acción (revisar la implantación, mover stock entre tiendas, ajustar el siguiente pedido, cambiar una promoción, asignar la tarea al responsable adecuado) y, una semana o un mes más tarde, revisar esa decisión frente a las ventas, el margen, la rotación de stock, la merma y la caja.

Observación, hipótesis, acción, evidencia del resultado. La mayoría del software de gestión muestra bastante bien lo que pasó. Mucho menos es capaz de seguir una decisión hasta su resultado económico.

A esa secuencia la llamo bucle de prueba; la etiqueta importa menos que el último paso. Cuando existe, el reporting deja de ser solo una forma de observar el negocio y pasa a formar parte de cómo responde el negocio. Es el cambio que defendí en de la contabilidad a la navegación, y la razón por la que marql lleva un Impact Ledger de lo que cada recomendación aplicada hizo con las cifras.

Hay varios niveles posibles de respuesta, y no son intercambiables. Un sistema puede poner una recomendación delante de un responsable y quedarse ahí. Puede crear una tarea y seguir su cumplimiento. Para un proceso acotado y repetitivo, puede actuar por su cuenta dentro de límites acordados de antemano. Podría preparar un traspaso de stock entre ubicaciones pero exigir que lo apruebe un responsable de operaciones; podría lanzar un pedido dentro de un rango acordado pero escalar una compra mayor. Las decisiones que afectan a precios, a compromisos de compra importantes o a una parte grande del inventario necesitan un nivel de control distinto del de los ajustes rutinarios.

El objetivo no es delegar tantas decisiones como sea posible. El trabajo difícil consiste en decidir qué acciones son reversibles, qué límites se pueden fijar de antemano y dónde el coste de un error sigue justificando la aprobación de una persona.

Lo mismo vale para la idea de moda de conversar con tu negocio. Una interfaz conversacional es realmente útil, pero no porque los propietarios estuvieran esperando otra forma de pedir un informe. Quieren saber qué desviación importa, qué pudo causarla, quién tiene que responder y si la decisión dio resultado. El lenguaje natural hace ese proceso más accesible. No hace más fiable la información que hay debajo.

La parte del ERP que la IA no puede sustituir

La pregunta de si la IA sustituirá al ERP suele mezclar dos funciones bastante distintas.

La primera es todo lo que ven los usuarios: menús, formularios, informes estándar, pantallas de aprobación, flujos analíticos integrados. Buena parte de esto va a cambiar. La gente pasará menos tiempo buscando un informe concreto o haciendo clic en una larga secuencia de pantallas, y los agentes asumirán muchas consultas, comprobaciones y pasos de proceso rutinarios.

La segunda es menos visible. Los sistemas de ERP, TPV, contabilidad y almacén registran hechos del negocio. Establecen que se produjo una venta, que se recibió mercancía, que se dio de baja un producto, que la mercancía se movió entre ubicaciones, que cambió un precio, que se contabilizó una factura. Esos hechos no se originan en la capa de IA. Hay que seguir capturándolos, conectándolos y guardándolos según reglas definidas.

Un sistema contable no puede concluir que una transacción probablemente ocurrió. Tiene que registrar lo que ocurrió, conservar los justificantes y mantener un historial que alguien pueda revisar más tarde. Un minorista necesita conocer no solo el saldo de stock actual, sino qué recepciones, ventas, traspasos, devoluciones y bajas lo produjeron. La IA es probabilística por diseño, lo que resulta útil cuando una tarea implica interpretación, información incompleta o un abanico de respuestas plausibles. Un sistema de registro tiene otra responsabilidad: coherencia, repetibilidad, permisos, pista de auditoría. Añadir IA no hace desaparecer esos requisitos.

La frontera no es absoluta, eso sí. La IA puede mejorar bastante la entrada de datos y el control dentro del ERP sin convertirse ella misma en el sistema de registro. Un agente específico puede leer una factura, un pedido de compra o un albarán y preparar los campos para revisión, cotejar un proveedor o un SKU con los datos maestros existentes, detectar un dato que falta y señalar un error probable antes de que se contabilice la transacción. Otros agentes pueden vigilar lo que ya se ha registrado, en busca de duplicados, registros que faltan, valores inusuales, clasificaciones de producto incoherentes o transacciones que no cuadran con las operaciones relacionadas. En lugar de aflorar a final de mes, esos problemas se pueden tratar cerca del momento en que ocurren.

No todas estas capacidades caben bajo la palabra IA. Si un campo obligatorio está vacío o un valor se sale de un rango conocido, una regla convencional lo detecta de forma más fiable y más barata. Los métodos estadísticos y el aprendizaje automático tradicional son buenos para encontrar patrones inusuales en grandes volúmenes de transacciones. La IA generativa y los agentes se ganan su sitio cuando el sistema tiene que leer un documento no estructurado, interpretar un contexto, explicar una anomalía o proponer qué debería pasar después. Una arquitectura práctica usa las tres, y elige según la naturaleza del problema. El mercado suele trabajar en el orden contrario: primero todo se describe como IA, y el problema se define después.

Los datos de mala calidad salen más caros

Cuando los datos solo se usan para informes, un error estropea un informe. Cuando esos mismos datos empiezan a impulsar recomendaciones y acciones, las consecuencias cambian. Un saldo de stock incorrecto lleva a una compra innecesaria. Un SKU duplicado distorsiona el rendimiento de una categoría. Las clasificaciones incoherentes afectan a las decisiones de surtido, y los registros tardíos hacen que el sistema responda a una situación que ya no existe. Los mismos problemas socavan cualquier intento posterior de calcular lo que una decisión devolvió.

La IA puede hacer este riesgo menos visible, porque lo que produce suena convincente. Un agente puede responder con seguridad a la pregunta de un propietario, identificar un patrón plausible y recomendar un curso de acción razonable. Si los datos de origen son incompletos o incoherentes, la explicación seguirá siendo coherente. Simplemente será coherente sobre una versión equivocada del negocio.

Un Porsche 911 puede tener una ingeniería excepcionalmente sofisticada, y nada de ella elimina la necesidad de combustible. En un sistema de gestión impulsado por IA, ese combustible son datos exactos, estructurados y a tiempo.

Por eso tampoco estoy convencido de que la IA vaya a abaratar automáticamente las implantaciones de ERP. Reducirá el coste de tareas concretas: procesamiento de documentos, cotejo de datos maestros, detección de anomalías, documentación de integraciones, primer diagnóstico. Pero al mismo tiempo las empresas piden más a sus datos: más detalle, disponible antes, coherente en un número creciente de sistemas. La naturaleza del trabajo cambia; el trabajo no desaparece. En algunos casos la implantación se vuelve más exigente, porque el resultado ya no está pensado solo para un informe de dirección. Un analista humano puede mirar una cifra inusual y decidir que probablemente algo está mal. Un proceso automatizado necesita que esa incertidumbre se detecte antes de ajustar un pedido o reasignar stock. Ese es el argumento para tratar el reporting como algo que se mantiene en marcha y no un proyecto que se termina.

Un punto de partida práctico

Para un propietario, el punto de partida sensato no es el producto de IA más impresionante ni un intento de sustituir todo el entorno contable. Es una decisión de gestión recurrente en la que una respuesta mejor y más rápida crearía valor medible: margen por categoría, merma, roturas de stock, asignación de stock, compras.

Una vez definido el escenario, puedes preguntarte qué datos necesita, de dónde vienen, cuánto se puede confiar en ellos, qué debería poder hacer el sistema y cómo se medirá el resultado. Eso suele dejar al descubierto bastante rápido el estado real de la infraestructura, y evita que el proyecto se convierta en una iniciativa general de IA sin responsable operativo ni resultado económico.

Para la mayoría de las cadenas de retail y los grupos de hostelería consolidados, sustituir el TPV, el ERP o la plataforma contable no es el primer paso. La vía más práctica es trabajar con los sistemas que ya existen. El TPV suele aportar los datos base; el ERP, la contabilidad y los sistemas de almacén añaden compras, costes, stock e información financiera. Conectarlos es solo el principio: productos, categorías, ubicaciones, transacciones, precios y saldos todavía tienen que conciliarse en un único modelo que siga siendo comparable entre tiendas, sistemas y periodos.

Esa es la parte de marql que menos atención atrae y la que más decide. marql lee los sistemas que la cadena ya utiliza, sin sustituirlos, con alojamiento en la UE, los normaliza en un único modelo y responde a la segunda pregunta sobre una cifra en la misma conversación que la primera. Parte de la conciliación está automatizada; las excepciones siguen necesitando personas que entiendan el negocio. Los precios empiezan en 200 € al mes.

No espero que la IA elimine los ERP y los sistemas contables en un futuro previsible. Hará que sus interfaces sean menos centrales, asumirá el trabajo analítico rutinario, simplificará la entrada de datos y reforzará los controles de datos. La responsabilidad de registrar correctamente los hechos del negocio sigue donde está. A lo largo de los años he visto una y otra vez cómo nuevas herramientas analíticas sacaban a la luz las debilidades de la contabilidad operativa en lugar de eliminar su necesidad. La IA las sacará a la luz más deprisa y, en algunos casos, actuará sobre la información antes de que una persona la haya revisado.