El contrato de Application Management (AMS) que renuevas hace quince años está perdiendo sentido, y la causa es de costos. La inteligencia artificial cambió el precio de construir software y dejó obsoleto el supuesto que sostenía al AMS tradicional. En su lugar gana terreno otra disciplina: la consultoría de procesos de negocio. Renovar el AMS clásico en 2027 significa pagar por un servicio idéntico al de 2020 mientras el mercado ya opera con otra lógica de cálculo.
Qué es la consultoría de procesos de negocio
La consultoría de procesos de negocio analiza cada proceso de una empresa y decide, caso por caso, cuál es la mejor forma de resolverlo entre las opciones tecnológicas disponibles. Mira el proceso real, no el sistema heredado, y aplica tres criterios a la vez: técnico, económico y de experiencia del negocio. Su salida es una decisión fundamentada, con neutralidad de proveedor.
El trabajo parte del levantamiento del proceso de punta a punta y termina en una recomendación respaldada por números. En el medio: mapeo del flujo actual, diagnóstico de dónde el estándar cubre bien y dónde se queda corto, modelado del costo de cada alternativa, y elección de la ruta. La decisión puede mandar un proceso a SAP, sacarlo a una aplicación propia, reemplazarlo por un servicio externo u orquestarlo con agentes de IA.
El mercado ya descontó el cambio
En enero de 2026, la acción de SAP cayó cerca de 15% en una sola sesión, su mayor desplome diario desde octubre de 2020, después de que su guía de ingresos cloud para el año quedará bajo lo que esperaba el mercado (Reuters). Respecto de su máximo de los doce meses previos, la acción acumulaba una baja cercana al 40%.
ServiceNow perdió alrededor de 17% en abril tras sus resultados del primer trimestre, su peor día registrado, y desde su máximo histórico llegó a caer cerca de 55% hacia febrero. Salesforce retrocedió alrededor de un tercio en seis meses.
Estas caídas no son ruido de ciclo. El mercado está probando una hipótesis concreta: cuando un agente de IA ejecuta solo las tareas que antes pedían licencias por usuario, el modelo de precios por asiento queda bajo presión. Apostar hoy toda la operación a un único proveedor es una posición que Wall Street empezó a cuestionar moviendo capital.
Construir software dejó de ser caro
Construir software colapsó de precio. Lo que a un desarrollador SAP le tomaba una semana, hoy lo resuelve en uno o dos días. Generación de código, documentación técnica, mapeo de integraciones: todo se aceleró entre diez y cien veces. La habilidad técnica pura dejó de ser, por sí sola, una ventaja.
La consecuencia tiene dos caras. Cuando el estándar de SAP cubre bien un proceso, construir algo encima pierde justificación. Cuando se queda corto, ya no hay razón para tolerarlo: hoy es viable, en plazo y costo, levantar una aplicación cloud que extienda S/4HANA con la experiencia que el negocio necesita, sin tocar el núcleo. Hace dos años, esos plazos y costos no eran realistas.
De dos opciones a seis
Hace tres años, la pregunta «¿cómo resuelvo este proceso?» tenía dos respuestas realistas: resolverlo dentro de SAP, por configuración estándar o desarrollo Z, o comprar un software especializado. El resto existía en el papel. Construir a medida era caro y lento, modernizar un sistema heredado era un proyecto de años, integrar significaba código propio, y los agentes de IA todavía no estaban.
Hoy la misma pregunta tiene seis respuestas viables:
- Resolver dentro de SAP. Configuración estándar o desarrollo Z. Sigue siendo la mejor respuesta cuando el proceso es genérico y el estándar lo cubre, aunque ya no es la opción automática.
- Software especializado. Lo mejor por categoría en CRM, recursos humanos, planificación, logística o precios, con madurez creciente.
- Aplicación cloud a medida. Viable hoy con IA y arquitecturas modernas, para los procesos donde el negocio compite de verdad y ningún estándar le hace justicia.
- Modernizar el sistema heredado. Cuando lo construido frena la operación pero la lógica de negocio sigue siendo correcta.
- Integración inteligente. Plataformas de integración (iPaaS), APIs y orquestación moderna. El pegamento entre sistemas dejó de ser código propio.
- Agentes de IA como capa transversal. Potencian a las otras cinco y automatizan tareas que antes dependían de licencias por usuario.
El error más común llega antes de elegir: es quedarse con la opción de siempre sin evaluar las otras cinco.
Cómo se elige: tres criterios a la vez
La pregunta dejó de ser «¿cómo configuro SAP para esto?». Ahora es «¿cuál de las seis opciones corresponde a este proceso?». Y se responde con tres dimensiones de análisis al mismo tiempo.
Criterio técnico. Qué tan bien resuelve cada opción el problema, qué deuda técnica deja, cómo se integra con el resto de los sistemas y qué tan mantenible queda en cinco años.
Criterio económico. Cuánto cuesta construir, operar y hacer evolucionar cada opción a tres o cinco años. El costo total de propiedad real, con licencias, infraestructura, talento y deuda incluidos. Qué libera capital y qué lo deja amarrado.
Experiencia del negocio. Cuál opción le da al usuario final la experiencia que el proceso pide, cuál acelera el ciclo y cuál habilita una diferencia competitiva que las demás bloquean.
Ninguna dimensión decide sola. Una opción más barata que genera deuda técnica termina costando más. Una opción técnicamente elegante que el usuario no adopta no resuelve nada. La decisión vive en el cruce de las tres.
Por qué el AMS tradicional ya no alcanza
Un AMS montado como gestión de incidentes resuelve síntomas. Cada ticket cerrado, en cambio, es información sobre cómo opera el negocio: qué cubre bien el estándar, dónde se queda corto, qué procesos críticos se sostienen con parches temporales. Esa información existe en todos los AMS. En la mayoría, se descarta.
El AMS que tiene sentido hoy atiende cada incidente dos veces. La primera resuelve el caso del usuario dentro del acuerdo de nivel de servicio (SLA). La segunda pregunta si el problema va a volver y qué evita que regrese. La primera atención es soporte. La segunda es consultoría continua. Sin esa segunda capa, los tickets se reproducen sin fin y la empresa paga dos veces: la licencia y el síntoma.
Qué perfil hace este trabajo
Este servicio pide un perfil distinto al del consultor SAP clásico. Alguien que entienda el proceso de punta a punta, conozca las seis opciones con profundidad real, sepa modelar la economía de cada una y no responda a la cuota de venta de ningún proveedor. Que pueda decir «esto se queda en SAP», «esto sale a una aplicación cloud», «esto se reemplaza por un servicio externo», «esto se orquesta con agentes», y defender cada decisión con los tres criterios a la vez.
Eso es la consultoría de procesos de negocio. Trabaja sobre el proceso, no sobre el sistema. Es neutral frente a la tecnología. Y usa IA como parte del método, en cada etapa, desde el levantamiento hasta el modelado de costos.
Qué se juega en los próximos dos años
En los próximos dos años, las decisiones tecnológicas de las empresas van a separarse mucho más que en la década pasada. Quien evalúe caso por caso, con criterio de proceso y sin reflejo de proveedor, va a operar con sistemas más livianos, más fáciles de cambiar y más baratos. Quien siga comprando AMS tradicional sobre el supuesto de que SAP resuelve todo va a seguir pagando licencias por capacidades que ya no usa y acumulando deuda técnica sobre procesos que debieron salir del núcleo hace años.
El primer paso no es contratar nada. Es tomar tus cinco procesos más caros de operar y preguntar, para cada uno, cuál de las seis opciones le corresponde. Esa sola conversación suele mostrar dónde estás pagando de más.
Notas relacionadas:
