He estado reflexionando sobre los módulos tradicionales del software ERP y he realizado una lista de los 10 módulos que podrían resolver algunos problemas reales que he visto a través del trabajando como consultor de transformación digital de negocios, y que, como tal, aún no existen en el mercado.
Son ideas que van más allá de la inteligencia artificial, copilotos IA, RPA, process mining, analítica predictiva, low-code.. Son funcionalidades de procesos completos, operativas y gobernadas dentro del ERP, y no simples asistentes.
Como antes dije esta es mi lista. Es una reflexión. Si quieres agregar ideas, perfecto, hazlo en los comentarios.
- Revertir La Demanda Invisible: pasar de «no tenemos ese producto o esa marca», a una acción comercial
Las analíticas de ventas de ERP, CRM, BI solo reportan lo que se vendió, pero lo que no se pudo vender, lo que se pudo facturar, o los beneficios no percibidos. De eso no hay datos ni queda rastro.
Qué quiero decir. El gerente de una cadena de ferreterías me decía que sus vendedores no están atentos a las marcas o productos que no tienen en catálogo, pero que se está vendiendo en el mercado. Ellos mismos dirigen a los clientes a la competencia.
Es una oportunidad perdida, una demanda invisible.
Pero hay muchos otros casos de demanda invisible que se podría visibilizar y resolver:
- consultas de productos inexistentes
- solicitudes de cotización no atendidas
- devoluciones por falta de tallas
- búsquedas internas en tienda online
- carritos abandonados
- menciones en soporte o en redes sociales
- Señales de «demand sensing» a lo largo de toda la cadena de suministro
La solución podría ser añadir en el ERP un «Libro de Demanda no atendida«.
Cuando registrar la carencia cueste más de 5 segundos, el empleado no lo hará si el mostrador está lleno clientes.
Hay que encontrar alternativas ágiles y sin fricción:
Por ejemplo, un botón en el POS («No tenemos tal producto»). Con una sola línea de texto o selección de categoría.
O un mensaje de voz al chatbot.
Más allá de notificar la carencia, lo ideal sería cerrar el ciclo convirtiendo el «no hay» en «lo puedo consigir para mañana». Es decir, venta bajo demanda.
Factores de éxito
Capturar señales negativas estructuradas: búsquedas sin resultados, productos consultados pero no disponibles, sustitutos rechazados, preguntas recurrentes y motivos de abandono.
Cruzar demanda con capacidad real: detectar interés está muy bien, pero el módulo debería estimar si es viable su fabricación, su compra, su distribución o lanzar una nueva referencia.
Y debería cerrar el bucle comercial: cada oportunidad debe generar una acción trazable: solicitud a un proveedor, derivación al departamento de marketing, prueba de mercado, dar de alta del artículo, o desarrollar un proyecto piloto de I+D…dependiendo del tipo de negocio.
- Registro de Razones de Decisiones: Sabemos qué “qué pasó”, pero “por qué se decidió”
El ERP registra facturas, órdenes, pagos o asientos contables, pero desecha todo el historial causal de cada decisión importante que se tomó:
¿por qué se aprobó el cambio de precio?
¿Por qué se rechazó un proveedor?
¿Por qué se priorizó un pedido?
¿Por qué se modificó una regla?
¿Por qué se canceló un proyecto?
La idea es crear un registro ágil que describa todo el contexto acompañó cada decisión adoptada:
Las alternativas consideradas
Los datos disponibles en ese momento
La predicción esperada
Los responsables humanos o agentes
KPI esperado
Vínculos entre la decisión y el resultado real obtenido
Causas probables del éxito o del fracaso
Qué se podría haber logrado con las otras alternativas
Esto crearía una especie de memoria empresarial contrafactual, produciendo datos extremadamente valiosos para el negocio.
Ejemplo:
La empresa eligió proveedor A en lugar de B.
Tres meses después comenzaron los retrasos y problemas.
Apunte en el Libro de Razones:
La decisión se tomó porque A era 7% más barato, pero se subestimó la probabilidad de un retraso en el puerto de recepción;
el coste real fue 14% superior al ahorro inicial”.
Por qué sería novedoso: los ERP tradicionales son excelentes sistemas de registro, pero fallan como sistemas de aprendizaje causal. Justamente porque no recogen los datos necesarios.
Gartner ha afirmado que decision intelligence y la IA causal son áreas relevantes para mejorar las decisiones empresariales, pero se debería incrustar esa lógica dentro del ERP como una capa obligatoria de memoria, auditoría y aprendizaje. Totalmente de acuerdo.
Beneficios:
Mejoraría el pricing, compras, planificación, presupuestos, promociones, inversiones y gestión de riesgos porque la empresa aprende de decisiones reales, no solo de reportes históricos.
Debería operar como un núcleo transversal.
- Gemelo Contrafactual de Decisiones: el ERP que te recuerda lo que NO hiciste
Este módulo está relacionado directamente con el anterior, la diferencia es que no nos centramos en el contexto de la decisión, sino en el impacto de las decisiones que no se tomaron.
El problema es que el sistema ERP guarda lo que efectivamente se ejecutó (la compra, el precio, el plan de producción), pero no las alternativas descartadas, ni las razones que determinaron cada decisión.
Por eso las empresas repiten errores y no pueden saber si una decisión fue buena o solo tuvo suerte.
¿Cómo funcionaría este módulo?
Cada decisión relevante (fijar un precio, elegir proveedor, aceptar un pedido urgente,…) se registra junto con las alternativas consideradas, las hipótesis y el contexto de ese momento.
En un segundo plano, el sistema iría simulando qué habría pasado con las otras opciones, utilizando los datos reales que fueron llegando después.
Lo que buscamos es conservar los escenarios alternativos y contrastarlos con los resultados reales:
¿Qué hubiese pasado si hubiésemos aceptado ese pedido?
¿Y si hubiésemos cambiado el proveedor?
¿Y si hubiésemos pospuesto la compra?
En este caso, el valor es aprender de decisiones pasadas con evidencias concretas:
¿qué reglas funcionaron y qué sesgos se repitieron?.
Y, particularmente, convertir el aprendizaje en táctica: cada análisis debería proponer cambios concretos en reglas, umbrales, aprobaciones o parámetros, con validación humana.
- Genoma de Procesos y Laboratorio de Caos Empresarial del ERP
Se trata de una funcionalidad de ERP en dónde cada proceso se representaría como un modelo vivo, un “genoma” compuesto por:
Reglas
Roles
Controles
Actividades
Aprobaciones
Excepciones
Recursos
Objetivos
Dependencias
Riesgos
Todo esto más un «entorno seguro» para inyectar perturbaciones como rotura de stock, ausencia de un aprobador, picos de demanda, retraso de proveedor y observar el grado de resiliencia.
Es decir, ERP podría crear mutaciones y caos controlado del proceso, hacer pruebas y verlo evolucionar.
Se lleva a cabo con datos de eventos reales. Y se entrena con logs del ERP, del CRM, del Sistema de Gestión de Almacenes, del Sistema de Ejecución de Manufactura y de comunicaciones. Y no con diagramas teóricos.
¿Esto es algo absolutamente disruptivo?
No. El “genoma de procesos” ya está presente en software empresarial en forma de en minería de procesos, de simulación de procesos y de digital twins o gemelo digital.
Reconstruyen el flujo real eventos, comprueban su conformidad y ensayan cambios antes de ponerlos en producción.
¿Qué lo hace nuevo?
Las plataformas actuales pueden descubrir, simular y recomendar mejoras de procesos.
También pueden realizar pruebas A/B de procesos apoyadas por IA.
Pero la innovación consiste en cerrar completamente el ciclo: descubrir, rediseñar, atacar, experimentar, desplegar y revertir los procesos erróneos de forma continuada.
¿Cómo funcionaría el Genoma de Procesos y Laboratorio de Caos Empresarial?
Por ejemplo, el sistema detecta un cuello de botella o una duplicación de un proceso.
Genera varias versiones alternativas o de reconducción del proceso y las ejecuta en el gemelo digital.
Introduce fallos simulados: como ausencia de personal, caída de proveedores, fraude, retrasos, picos de demanda o errores de datos.
Prueba las mejores variantes en modo sombra o con un grupo reducido.
Implanta progresivamente la opción ganadora.
Y si se violase algún límite revertiría automáticamente los cambios realizados.
También se podría utilizar con pilotos de procesos mediante aprendizaje federado o colaborativo: una sucursal aprendería de los incidentes de otra sin intercambiar sus datos confidenciales.
- Gemelo Digital Operacional del ERP
Se trata de un módulo de simulación en tiempo real del comportamiento de la empresa antes de ejecutar cualquier decisión relevante, como confirmar un pedido, cambiar un proveedor, aprobar una promoción, contratar personal, modificar precios, producir o adquirir más inventario..
Evidentemente, este módulo trabajaría fusionado o en paralelo con el laboratorio de caos del módulo anterior.
El formato de este instrumento no sería el de un dashboard, sino el de un simulador obligatorio previo a la toma de cualquier decisión relevante.
Antes de registrar una acción, el ERP simularía su efecto en tesorería, en inventario, en la capacidad productiva, en la entregas, en el cumplimiento, márgenes, riesgos, niveles de emisiones, recursos humanos y clientes.
Un ejemplo: El departamento de ventas recibe un pedido de comercio exterior muy importante, pero a condición de tener que hacer un descuento del 15% sobre el precio actual. Ventas lo celebra ¿pero es un buen negocio en todo sentido?
Para tomar la decisión el ERP simula:
El impacto en flujo de caja a 20 semanas, por ejemplo.
El nivel de riesgo de ruptura de stock
Costes de materias primas
La capacidad producción en planta
Aranceles, costes logísticos, tipo de cambio
El margen real después de logística y de la financiación
Efecto en relación y compromisos con otros clientes
Riesgo de incumplir el Acuerdo de Nivel de Servicio
Riesgo regulatorio
Riesgo país,..
Si el resultado fuese negativo, el ERP daría un señal de alerta y propondría versiones alternativas del pedido.
¿Grado de innovación?
Los ERPs de alto nivel ofrecen funcionalidades extraordinarias de este tipo, como minería de procesos, SCM (Gestión de la Cadena de Suministro), MES (Manufacturing Execution System) y plataformas de gemelos digitales…
Estos ERPs ya permiten simulaciones y análisis de tipo what-if (qué pasaría si…), optimización de costes y procesos, y detección de cuellos de botella,.. pero no en el espectro estrictamente comercial, en donde cada transacción importante pueda pasar por un gemelo vivo antes de ejecutarse.
Y se podrían potenciar mucho más si se llegasen a convertir en un “motor de realidad operativa”: modelo de objetos (como pedidos, lotes, máquinas, vehículos, personas, contratos) o eventos, no una simple réplica visual.
O sincronizarlo con datos operativos, como inventario, capacidad operativa, plazos, costes, calidad, mantenimiento y restricciones comerciales.
O si ofrececen simulaciones accionables para cada escenario, terminando con una recomendación, un plan alternativo o una alerta concreta.
- Contabilidad de Confianza en los Datos y de las Decisiones
Un ERP trata todos los datos como fuesen realmente ciertos.
Si el sistema te dice que el stock es de «120 unidades» y podría ser un dato exacto. O podría llevar más tres meses sin inventario físico.
El plazo de entrega «10 días» puede ser un dato seguro o una estimación hecha por costumbre.
Las decisiones se suelen tomar sobre una precisión más o menos cierta, pero esa incertidumbre se propaga a través de los cálculos.
La propuesta es que cada dato no solo tenga un valor, sino que integre un estado de confianza (procedencia u origen, frescura o antigüedad, cobertura, método de verificación, variabilidad histórica, y riesgo de error).
¿No sería mejor que el MRP en vez de decirte: «necesitas comprar 500», te diga:
«necesitas entre 600 y 800, y el 60 % de esa incertidumbre viene del stock del almacén B, que no se audita desde hace 90 días».
El sistema analiza varias situaciones convergentes y sugiere que datos hay que se deben verificar (mediante un recuento, o una llamada) y hace más racional y reduce el riesgo de la decisión.
Es imprescindible hacer visible la incertidumbre en ámbitos de decisiones: mostrar rangos, escenarios y alertas en presupuestos, previsiones, costes, plazos y disponibilidad.
El sistema debe recomendar una acción, no solo advertir de que el dato es incierto.
¿Qué cambiaríamos con esto?
Pasamos de datos limpios a datos con una calidad medible.
Hay áreas que lo agradecerán. Por ejemplo, los recuentos de inventario dejarán de ser cíclicos y ciegos, y pasarán a dirigirse por el valor de información.
Y los informes financieros podrán mostrar rangos y sensibilidades, no solo cifras únicas.
A nivel transversal este módulo mejoraría la demanda invisible, el gemelo contrafactual, el laboratorio de caos y los agentes.
- Procesos que se Rediseñan Solos: ERP con Descubrimiento y Mutación Controlada de Flujos
Si observas los sistemas ERP verás que se configuran una vez y con el tiempo los procesos se burocratizan. Se anquilosan.
Cambiarlos exigiría meses de consultoría. Pero los empleados se vuelven creativos e inventan atajos en Excel, WhatsApp, Airtable, Claude,… porque el proceso oficial no funciona.
La idea es desarrollar un sistema que vaya observando cómo se ejecutan los procesos.
Que detecte cuellos de botella, pasos innecesarios y atajos informales, y que proponga variantes mejoradas del flujo.
Que lleve a cabo pruebas de forma controlada por humanos, como un test A/B de los procesos, a pequeña escala (una planta de la empresa, un equipo, un tipo de pedido).
Si la variante mejora el tiempo, el coste o los errores sin romper controles de cumplimiento, se oficializa su adopción general, (siempre con aprobación humana) y las nuevas reglas sobre el proceso.
Lo interesante no es tanto que ERP mute solo, sino que el ERP es capaz de detectar una mejor variante de proceso, que la simule, que proponga el cambio, obtenga aprobación y despliege la mutación.
¿Es una mejora novedosa?
No. El process mining ya existe en sistemas ERP. Pero esta idea lo que propone es cerrar todo el ciclo desde la propuesta, el experimento y su despliegue.
- Consejo de Agentes Copiloto, con voto, veto y auditoría
En lugar de un único copiloto de IA como ya tienen todos los ERP modernos, el nuestro ERP tendría un consejo de agentes verticales especializados:
Un agente financiero
Un agente legal
Un agente de compras
Un agente para la cadena de suministro
Un agente fiscal
Un agente de sostenibilidad
Un agente de ciberseguridad
Un agente comercial
Un agente de recursos humanos..
Cada agente defendería un objetivo diferente. Por ejemplo:
El de ventas: maximizar ingresos
El de finanzas: proteger el margen y la tesorería
Legal: detectar y reducir el riesgo contractual
Compras: asegurar el abastecimiento y optimizar los costes
Sostenibilidad: controlar huella de carbono
Ciberseguridad: evitar la fuga de datos
Operaciones: proteger la capacidad de producción y de servicios, y los compromisos
Cada decisión solo se ejecutaría si pasa por el protocolo de consenso empresarial o un Playbook.
Algunos agentes tendrían poder de veto; otros podrían exigir revisión humana.
Esto sería más potentes que los agentes empresariales convencionales.
En primer lugar, porque los agentes actuales registran muy bien las transacciones, pero siguen delegando gran parte de la decisión operativa a humanos.
Y en segundo lugar, porque trabajarían como un órgano formal de decisión, con reglas de voto, trazabilidad, umbrales de riesgo y responsabilidad 100% auditable.
Darían coherencia, por ejemplo, evitarían que una función optimice su KPI dañando a otra.
El valor empresarial está en que sean capaces de reducir errores antes de que una acción llegue a un humano o a un sistema crítico.
- Red de Acuerdos Autónomos B2B de ERP a ERP
Esta idea la de crear una red en la que los ERP de los clientes, proveedores, bancos, operadores logísticos y aseguradoras pudieran negociar directamente entre ellos, en principio sin participación humana, y sin limitarse a intercambiar órdenes o facturas.
Funcionamiento:
Cada empresa definiría su Playbook operar en el mercado:
Qué puede negociar automáticamente
Qué información puede revelar
Cuáles serán los precios mínimos o máximos
Condiciones de pago aceptables
Capacidad disponible
Límites de riesgo
Restricciones jurídicas y ambientales
Operaciones en las que podrían negociar pero con aprobación humana.
Los agentes negociarían simultáneamente:
Precios
Cantidades
Fecha y prioridad de entrega
Condiciones de pago
Reservas de capacidad
Penalizaciones por incumplimiento
Garantías
Huella de carbono
Reparto del riesgo ante interrupciones
El resultado de su actividad sería un contrato de intención ejecutable, acompañado de las pruebas de que ningún agente se excedió en sus competencias. O mejor aún un «smart contract» en la cadena de bloques.
Por ejemplo, en una operación de comercio exterior un puerto queda cerrado. Ante esta noticia se dispara el Acuerdo Autónomo.
Los ERP de las seis empresas implicadas renegocian rutas, inventarios, fechas, seguros y capacidad productiva.
Cada compañía protege sus costes confidenciales, pero demuestra que puede cumplir la nueva obligación.
¿Es una idea innovadora?
No. No lo es. Es reformular una idea que ya existe. SAP dispone del protocolo de interoperabilidad bidireccional Agent-to-Agent (A2A) asociado a su IA Joule, y Oracle dispone de agentes que monitorean negociaciones y realizan recomendaciones sobre la marcha.
Pero de momento, eso no equivale a un especie de marketplace interempresarial en donde agentes autónomos pueden negociar acuerdos multidimensionales con información privada y una potestad contractual limitada.
Se están estudiando mucho los esquemas de negociación entre agentes de IA aplicados a cadenas de suministro. Y resultados son dispares, tanto en sus beneficios, como en los riesgos de llegar a acuerdos irracionales, retrasos o injusticias en cuanto a quien sale ganando o perdiendo en este tipo de relación.
El reto es muy interesante. Pero hay que superar un gran riesgo, que es la responsabilidad jurídica cuando un agente acepta un mal contrato.
Y, por otra parte, es fundamental diseñar la excepción humana: un acuerdo autónomo debe escalar a personas cuando haya discrepancia, riesgo, fraude potencial o un cambio de condiciones.
- Núcleo de Gobernanza y Trazabilidad Algorítmica
Los ERPs tradicionales fueron diseñados para registrar transacciones humanas (Sistema de Registro). Los ERPs modernos, impulsados por Agentes de IA, están diseñados para ejecutar decisiones autónomas (Sistema de Acción).
En la Unión Europea con Ley de IA de la Unión Europea (EU AI Act), el GDPR, y la Data Governance Act, el riesgo crítico ya no es técnico, es legal y reputacional, y el ERP debe transformarse en un sistema de responsabilidad legal y técnica.
Este módulo transversal de ERP actuaría como un notario digital inmutable que sitúa la gobernanza en el centro del flujo de trabajo, permitiendo la adopción de agentes autónomos con certeza jurídica.
La idea central mantener una IA confiable y totalmente auditable.
Concretamente, el sistema intercepta cada decisión tomada por un Agente de IA dentro del ERP antes, durante y después de su ejecución.
Registrando:
- La Identidad del Agente (ID del Modelo, Proveedor y Nivel de Autonomía
- Linaje de Datos (fuente del dato, sesgos potenciales, calidad..)
- Lógica y Regla: El «porqué» de la decisión.
- Aprobación Humana, cuando es normativa: Crítico para la IA de Alto Riesgo (Art. 14 EU AI Act).
- Evaluación de Impacto
- Reversibilidad y Remediación. Es decir, la capacidad de deshacer
- Mapeo Regulatorio: etiquetado normativo y creación del dossier técnico obligatorio para auditores externos.
Abro el debate 😉