El software con capacidad de agencia convierte la migración de ERP en el precio de entrada

El software con capacidad de agencia se está convirtiendo en una nueva palanca para que los proveedores empresariales empujen a los clientes hacia el ERP en la nube. SAP y Oracle no se limitan a añadir herramientas que redactan correos o resumen informes; están integrando sistemas que pueden leer permisos y jerarquías de aprobación, tomar decisiones dentro de los flujos de trabajo de finanzas o cadena de suministro y ejecutar transacciones.

Esa capacidad cambia las apuestas de una migración de ERP. La fuente sostiene que el acceso a funciones agentivas está cada vez más vinculado a las plataformas en la nube donde los proveedores alojan los sistemas de registro. Para las empresas que todavía operan ERPs locales, el precio de adopción puede ser un traslado al cloud más amplio y anticipado.

SAP vincula el acceso a Joule al ERP en la nube

En su conferencia Sapphire de esta primavera, SAP presentó lo que llama la empresa autónoma: más de 200 agentes especializados, orquestados por aproximadamente 50 asistentes específicos de dominio y accesibles a través de una única interfaz, Joule.

Los agentes están diseñados para operar dentro del entorno empresarial central de SAP, respetando los permisos existentes y realizando trabajo en vivo en lugar de limitarse a recomendar una acción. Esa integración nativa es una ventaja clave frente a una herramienta externa que no puede ejecutar transacciones de forma segura en el sistema de registro.

También crea una dependencia de la plataforma en la nube de SAP. Hasta esta primavera, Joule estaba disponible solo para clientes con las suscripciones en la nube RISE y GROW de SAP. Desde entonces, SAP ha abierto el acceso a clientes que ejecutan ECC y S/4HANA en instalaciones propias, pero solo si se comprometen a mover la mayoría de su parque SAP al ERP en la nube.

Recomendado

La escasez de GPUs bloquea proyectos de IA en el 91% de las empresas rusas

Incluso con esa vía, los clientes reciben solo un conjunto limitado de las capacidades disponibles en lugar del portafolio completo. El punto central de la fuente es que la opción local aún exige gasto en la nube para desbloquear las nuevas funciones.

Los clientes de ECC afrontan un plazo adicional. El mantenimiento general finaliza en diciembre de 2027, con una extensión hasta 2030 disponible a un coste adicional. Después de eso, los clientes deben operar un sistema sin soporte o actualizar. El artículo sostiene que este calendario puede convertir el deseo de usar software con capacidad de agencia en una presión añadida para migrar, independientemente de si la organización había elegido ese calendario.

Oracle exige el paso a Fusion Cloud

Oracle adopta un enfoque más directo. Sus nuevos agentes funcionan únicamente dentro de Fusion Cloud, en la infraestructura de Oracle y dentro del modelo de seguridad de Oracle. No existe una edición para instalaciones propias que se pueda licenciar.

Eso significa que las organizaciones que todavía ejecutan E-Business Suite no pueden habilitar los agentes en sus sistemas actuales. Deben replataformarse en Fusion para utilizarlos en absoluto.

El resultado es similar al modelo de SAP: la vía hacia las capacidades agentivas pasa por la migración a la nube que los proveedores ya han estado fomentando. La diferencia es que el nuevo software da al argumento de la migración mayor palanca. El coste, el riesgo operativo y la interrupción han mantenido a muchas empresas en instalaciones propias a pesar de años de presión para moverse; la exclusión de nuevas capacidades puede convertirse en un incentivo más potente.

La migración y el software agentivo compiten por el mismo presupuesto

La fuente sostiene que la migración al ERP en la nube y el software con capacidad de agencia tiran del mismo fondo de financiación empresarial. La migración reclama el primer derecho porque es el requisito previo para el acceso.

Investigaciones del Grupo de Usuarios SAP de las Américas encontraron que el 61% de sus miembros identificó el presupuesto como su mayor desafío este año. El director de investigación del grupo atribuyó esa presión en parte a proyectos de ERP en la nube, y se espera que las nuevas capacidades agentivas tiren de los mismos presupuestos.

La secuencia de gasto puede, por tanto, volverse difícil para los CIOs:

• Pagar para migrar a la plataforma en la nube requerida.
• Pagar de nuevo para usar las nuevas capacidades una vez allí.
• Cubrir los cargos por consumo de funciones ajenas al conjunto limitado incluido en la suscripción principal.

Esa estructura puede consumir el capital destinado a producir resultados empresariales medibles antes de que un solo agente haya entregado uno. También crea un riesgo para programas ya bajo escrutinio por parte de consejos frustrados por pilotos que nunca llegan a producción o por gastos que no pueden vincularse a resultados.

La fuente no proporciona precios específicos de migración de SAP u Oracle, ni cuantifica los cargos por consumo. Tampoco cita métricas de rendimiento independientes para los agentes. El argumento trata sobre el control de los presupuestos y el calendario más que sobre una comparación medida de los resultados de los productos.

Mantener el control de la hoja de ruta del ERP

La recomendación del artículo es separar dos decisiones que los proveedores presentan cada vez más como una sola: si modernizar, y cuándo, en qué orden y con qué presupuesto hacerlo.

El soporte ERP de terceros se presenta como una forma de crear esa separación. Un proveedor independiente puede mantener el parque existente, preservar la interoperabilidad y ofrecer cobertura de seguridad en lugar del contrato de mantenimiento del proveedor, normalmente a una fracción del coste, según la fuente.

Ese enfoque podría eliminar la fecha de fin de soporte como un factor de presión inmediata y liberar el gasto de mantenimiento para proyectos que la organización haya priorizado. El ERP existente seguiría siendo un núcleo operativo productivo mientras los ejecutivos deciden dónde las capacidades agentivas pueden aportar valor.

La fuente describe dos posibles rutas a partir de ahí. Una empresa podría mantener su núcleo ERP estable y ejecutar el software con capacidad de agencia como una capa de orquestación por encima, accediendo al sistema de registro sin migrar toda la plataforma primero. Alternativamente, podría modernizar de forma selectiva—por ejemplo, pasando de bases de datos propietarias a alternativas de código abierto cuando eliminar las cuotas de licencia tenga un caso de negocio claro.

La cuestión subyacente es la gobernanza. El software que puede actuar dentro de finanzas, cadena de suministro y otros procesos críticos crea una dependencia más profunda del proveedor de la plataforma que un asistente que solo ofrece sugerencias. La fuente sostiene que las organizaciones deberían definir sus propios controles, la secuencia y el retorno esperado en lugar de heredarlos de una hoja de ruta en la nube.

«La empresa autónoma puede valer la pena. Lo que un consejo de administración debe negarse a hacer es permitir que su calendario y su presupuesto los marque la compañía que más tiene que ganar con ese cambio.»