Alkemia · Enterprise Apps Strategy

Seis condiciones fijan lo que el contrato va a costar
y llegan completadas por defecto.

El costo de un contrato de Cloud ERP a lo largo del plazo lo fijan condiciones que llegan completadas por defecto, rara vez se presentan como una elección, y dejan de ser negociables el día de la firma. Son seis, todas legibles en documentos que el cliente ya tiene en la mano. El precio de partida es el término más disputado de la propuesta, y suele ser el único que la negociación alcanza.
Para quien tiene una propuesta de SAP Cloud ERP en evaluación
Dónde viven los términos

Un contrato de Cloud ERP se reparte en varios documentos, y la diferencia entre dos de ellos decide qué tiene sentido negociar. Los términos generales recogen las condiciones que valen para toda la familia de contratos y no se reescriben cliente por cliente. El formulario de pedido y los anexos de servicio recogen lo específico de esa operación: duración, derechos de uso contratados, ajuste anual, alcance de servicio, niveles de disponibilidad. Un equipo que no separa ambos gasta capital de negociación donde no hay movimiento y acepta como inmutable lo que era el objeto real de la conversación.

Los dos documentos

Una parte es constante. La otra es la negociación.

Constante

Términos generales

Valen para toda la familia de contratos y no se reescriben por cliente. Ahí quedan la ausencia de rescisión por conveniencia, la ausencia de regreso a licencia perpetua y la imposibilidad de reducir volumen contratado dentro del plazo.

Saber que son constantes evita gastar capital de negociación donde no tiene efecto. El contenido de esas cláusulas sigue siendo información de decisión: es lo que define el costo de cambiar de opinión.

Específico

Formulario de pedido y anexos

Recogen lo que pertenece a esa operación: duración, derechos de uso y las bases sobre las que se miden, ajuste anual, mecánica de renovación y plazos de aviso, alcance de servicio incluido, nivel de disponibilidad y qué cuenta como servicio adicional.

Aquí es donde la propuesta todavía puede cambiar antes de firmar, y es la parte que llega completada con valores por defecto que nadie presentó como decisión.

Por qué la ventana es corta

El reloj del mantenimiento comprime la fase que fija la economía.

Las fechas son públicas y específicas. Para Business Suite 7, que incluye SAP ERP 6.0 (ECC) y es la generación on-premise anterior a S/4HANA, SAP ofrece mantenimiento mainstream de las aplicaciones centrales hasta el final de 2027. De 2028 a 2030 existe mantenimiento extendido opcional, con una prima de dos puntos porcentuales sobre la base de mantenimiento, aplicable al alcance de soporte de Business Suite 7 y no solo a la parte que todavía está en conversión. Quien no lo elija pasa a mantenimiento específico de cliente. En las aplicaciones centrales, estas ventanas de mantenimiento mainstream y extendido abarcan solo los tres enhancement packages (EHP) más recientes de cada aplicación (en SAP ERP 6.0, los EHP 6, 7 y 8). Los sistemas sin enhancement package o en un nivel anterior deben actualizarse a uno de estos niveles elegibles para recibir mantenimiento dentro de estas ventanas. Para los escenarios más complejos, la opción de transición SAP ERP, private edition, ofrece una suscripción de continuidad entre 2031 y 2033, con prerrequisitos propios, entre ellos completar la migración a SAP ERP, private edition sobre SAP HANA antes del final de 2030. En cuanto a S/4HANA, SAP se compromete a que siempre haya al menos una versión en mantenimiento hasta el final de 2040.

El efecto de esas fechas sobre la negociación es indirecto, y ese es el punto. Acortan el tiempo disponible para la única fase en que los términos todavía son reversibles, y esa fase es la primera en recortarse cuando el cronograma aprieta, porque es la que no produce entregable visible. La diligencia que desaparece es la comercial y contractual, porque no suele tener dueño designado.

Después de firmar, el mismo pedido cambia de naturaleza. Antes se sostiene en una alternativa concreta: no firmar, firmar otra cosa, firmar más tarde. Después se convierte en una solicitud de cambio evaluada sin contraparte, y lo que antes se negociaba pasa a comprarse.

Qué debe quedar resuelto

Seis decisiones, y el documento donde se lee cada una.

Ninguna de ellas exige acceso privilegiado a información del proveedor. Todas están escritas en documentos que el cliente recibe antes de firmar. Lo que cambia el resultado es tratarlas como decisiones mientras todavía hay alternativa del otro lado.

  • A

    La base de lo que ya se tiene

    Qué parte del parque instalado entra en la suscripción y qué parte sale antes.

    Una propuesta se dimensiona sobre una lectura de lo que el cliente ya posee y ya usa. Cuando esa lectura no se rehízo, el derecho de uso ocioso atraviesa la conversión y deja de ser un activo detenido para convertirse en un compromiso recurrente, pagado todos los años del plazo. Rehacer esa lectura antes de firmar cambia la base de cálculo sobre la cual se le pone precio a todo lo demás.

    Dónde se lee: Los contratos y el historial de derechos de uso del propio cliente, contra la base que supone la propuesta.

  • B

    La base de medición de cada servicio

    Sobre qué crece el costo, servicio por servicio, a lo largo del plazo.

    Los servicios suscritos no miden todos lo mismo. Unos escalan por usuario clasificado, otros por documento procesado por un sistema de terceros, otros por volumen de negocio. De ahí salen dos consecuencias prácticas: la proyección debe hacerse sobre volumen proyectado y no sobre el volumen de hoy, y conviene verificar si dos servicios distintos no están midiendo sobre la misma base, lo que expone una misma magnitud dos veces.

    Dónde se lee: Las líneas de derechos de uso del formulario de pedido y la descripción de servicio de cada ítem.

  • C

    Qué está en la tarifa y qué es línea aparte

    La frontera entre servicio incluido y servicio adicional, escrita antes de necesitarla.

    La suscripción trae una línea base de servicio. Fuera de ella quedan ítems que la operación real suele exigir: paquetes de seguridad y cumplimiento contratados contra brechas documentadas, retención extendida de respaldo, ambientes no productivos y la cantidad de ciclos de prueba que soportan. Ninguno de ellos es una sorpresa contractual, todos están escritos. Lo que decide el costo es si se dimensionaron antes de firmar o se pidieron después, cuando el precio deja de ser comparable.

    Dónde se lee: El documento de roles y responsabilidades, que separa servicio estándar de servicio adicional.

  • D

    La mecánica del plazo

    Duración, renovación, ajuste anual y qué pasa si la necesidad se achica.

    Aquí está la distinción que más cambia la conversación. Una parte de estas condiciones es estándar de los términos generales y vale para todo contrato de esa familia: no hay rescisión por conveniencia, no hay regreso a licencia perpetua, no hay reducción de volumen dentro del plazo. Otra parte pertenece al formulario de pedido y varía caso por caso: la duración, el ajuste anual y la mecánica de renovación, incluida la asimetría entre el plazo de aviso del cliente y el del proveedor. Tratar ambas como si fueran lo mismo hace que el equipo negocie donde no hay movimiento y acepte como fijo lo que era el objeto real de la conversación.

    Dónde se lee: Los términos generales para lo estándar, el formulario de pedido para lo que varía.

  • E

    La economía del nivel de servicio

    Cuánto vale el compromiso de disponibilidad frente al costo de una hora detenida.

    El remedio contractual por indisponibilidad es un crédito sobre la tarifa, y tiene tope. El techo de esa compensación es función de la tarifa pagada al proveedor, mientras que el perjuicio de una caída es función de lo que dejó de operar. Son dos magnitudes independientes. La decisión está en comparar el precio del compromiso superior contra el costo propio de una hora de indisponibilidad en los procesos que realmente se detienen. Para muchas operaciones el nivel estándar alcanza, y esa también es una conclusión defendible.

    Dónde se lee: El anexo de nivel de servicio, leído contra un costo de indisponibilidad calculado por el cliente.

  • F

    La salida

    Cuánto cuesta recuperar los propios datos y cuántas veces está incluido.

    La devolución de datos al cierre es un servicio estándar, entregado una vez por ciclo de contrato, y la planificación, el traslado y el almacenamiento quedan a cargo del cliente. Cualquier otra ocurrencia durante la vigencia es un servicio adicional. Esto importa antes de firmar porque hay escenarios bastante comunes que piden más de una extracción: una operación en paralelo, una escisión, la salida de una unidad de negocio. Modelar la salida al momento de firmar es el único momento en que todavía se puede comparar contra alternativas.

    Dónde se lee: La descripción del servicio de devolución de datos y lo que le asigna al cliente.

El orden importa. Las tres primeras fijan la base de cálculo, y las tres últimas solo pueden evaluarse una vez que esa base existe.

Cada una de estas seis es una elección hasta la firma. En la firma, todas pasan a ser supuestos.

Alexandre Pereira

El próximo paso

Poner a prueba la propuesta mientras los supuestos todavía son reversibles.

Para el CFO que responde por el compromiso plurianual y para el CIO que responde por la arquitectura que ese compromiso fija, la pregunta operativa es: de las seis, cuántas están resueltas por escrito en la propuesta actual. Una conversación de 30 minutos, sin compromiso, alcanza para identificar cuáles quedaron abiertas y cuáles dependen de información que todavía no se le pidió al proveedor. Si la conclusión es que la propuesta ya se sostiene como está, esa también es una respuesta útil, y es la que vuelve innecesario el trabajo siguiente.

Hablar de tu decisión

contact@alkemia.io

Cuando el trabajo necesita ir más allá de una conversación, el punto de entrada es el diagnóstico previo a la firma.

Para el mismo programa leído por el lado de la falla, ver por qué fracasan los programas de SAP Cloud ERP.

Preguntas frecuentes

La decisión previa a la firma, en términos prácticos.

¿Cuándo termina el mantenimiento de SAP ECC?
SAP ECC (SAP ERP 6.0) forma parte de SAP Business Suite 7, la generación on-premise anterior a S/4HANA. SAP ofrece mantenimiento mainstream de las aplicaciones centrales de Business Suite 7 hasta el final de 2027. De 2028 hasta el final de 2030 existe mantenimiento extendido opcional, con una prima de dos puntos porcentuales sobre la base de mantenimiento, aplicable al alcance de soporte de Business Suite 7. Quien no lo elija pasa a mantenimiento específico de cliente. En las aplicaciones centrales, estas ventanas de mantenimiento mainstream y extendido abarcan solo los tres enhancement packages (EHP) más recientes de cada aplicación (en SAP ERP 6.0, los EHP 6, 7 y 8). En paralelo, SAP sostiene su compromiso de que siempre habrá al menos una versión de S/4HANA en mantenimiento hasta el final de 2040.
¿Existe un camino después de 2030?
Existe, y tiene forma propia: una suscripción con plazo definido, con alcance, precio y prerrequisitos propios. SAP ofrece SAP ERP, private edition, transition option para continuidad de negocio entre 2031 y 2033. Los prerrequisitos publicados son específicos: el sistema debe haber migrado a SAP ERP, private edition sobre SAP HANA antes del 31 de diciembre de 2030, SAP HANA es la única base de datos soportada, hay un tamaño mínimo de 2 TB, y la oferta solo existe combinada con el max success plan, el plan de éxito de SAP que suma servicios de transformación, durante el período. Cada uno de esos prerrequisitos es una decisión que debe caber en el cronograma actual, porque la ventana de migración cierra el 31 de diciembre de 2030.
¿Negociar bien el descuento no resuelve el costo del contrato?
Resuelve una parte, y es la parte que más atención recibe. El descuento se aplica sobre el precio de partida. Lo que el contrato cuesta a lo largo del plazo depende además de la base sobre la cual se mide cada servicio, de qué está incluido en la tarifa y qué es línea aparte, del ajuste anual y de si el volumen se puede reducir o no, y del costo de salir. Esas condiciones siguen vigentes mucho después de concedido el descuento, y la mayoría de ellas nunca se presenta como una elección porque llega completada por defecto.
¿Qué se puede cambiar después de firmar?
Menos de lo que suele suponerse, por una razón estructural. Antes de firmar existe una alternativa concreta: no firmar, firmar otra cosa, firmar más tarde. Esa alternativa es lo que le da contenido económico a cualquier pedido. Después de firmar, los mismos pedidos pasan a ser solicitudes de cambio, evaluadas sin alternativa del otro lado, y el precio de esos cambios refleja esa ausencia.
¿Cómo afecta el contrato de ERP a la agenda de IA?
Un contrato de Cloud ERP fija por varios años el núcleo transaccional sobre el cual va a operar la agenda de IA: dónde quedan los datos, en qué formato salen, qué integraciones están contratadas y cuánto cuesta cada documento que procesa un sistema externo. Las iniciativas de IA que dependen de leer o escribir en ese núcleo heredan esas condiciones sin poder renegociarlas. Conviene llevar los casos de uso de IA ya previstos a la evaluación de la propuesta, mientras las bases de medición y los derechos de extracción siguen abiertos.
¿Toda propuesta necesita esta revisión?
No. Cuando el parque instalado es pequeño y homogéneo, el inventario de derechos de uso está actualizado, no hay integraciones relevantes con sistemas de terceros y el valor comprometido es modesto, una revisión independiente tiende a no justificar el tiempo que consume. El trabajo se justifica cuando el valor comprometido es material, cuando la base de medición es incierta, o cuando el cronograma presiona la decisión al punto de que la diligencia se está recortando para que quepa en la ventana.

Las condiciones de un contrato específico dependen de la edición de los documentos aplicables, del formulario de pedido efectivamente propuesto y de la jurisdicción. Antes de actuar, conviene validar el caso concreto contra los propios documentos y con apoyo legal.

SAP y los nombres de productos SAP son marcas de SAP SE o de sus filiales. Alkemia es una consultoría independiente, sin afiliación, respaldo ni representación de SAP. Este material es informativo, describe estructuras contractuales en términos generales y no constituye asesoría legal ni determina los términos de ningún contrato específico. Las fechas de mantenimiento reflejan las posiciones publicadas por SAP y consultadas en agosto de 2026.