Deber de cooperación

Trabajo práctico en el centro de datos, mostrar iniciativa durante las actualizaciones de versiones e inventar algunas soluciones ECC: eso es a lo que están acostumbrados los clientes actuales de SAP desde R/2 y R/3. La computación en nube debería liberarles ahora de todos los problemas y molestias on-prem. Ahora, la computación en nube debería liberarles de todos los problemas y molestias on-prem, porque la nube debería ser la continuación lógica de la externalización y el alojamiento.

Se suponía que el paso a la nube reduciría la carga de trabajo de los clientes actuales de SAP. Pero SAP ve las cosas de otro modo: el estándar de nube de SAP sólo incluye servicios rudimentarios: sin cooperación activa, pasa muy poco. En la imagen que SAP tiene de la nube, existe una obligación explícita de cooperación por parte de los clientes existentes.

En el uso operativo, la SAP Business Technology Platform (BTP) se convierte en una trampa de costes y, en consecuencia, en un paquete engañoso. Cuanto más profundizan los clientes de SAP en los secretos y estructuras de la BTP, más se dan cuenta de que están tratando con la antigua HEC, Hana Enterprise Cloud. ¿Fraude de etiqueta? Tal vez, porque HEC no estaba mal ni era malo, pero BTP debería ser más a un precio justo. Lo que el cliente SAP existente podría haber tolerado como "problemas iniciales" con HEC, quiere volver a encontrarlo como servicio automatizado en BTP.

El hecho es que muchos clientes actuales de SAP apenas notan diferencia entre BTP y HEC. Quizás BTP pueda hacer más que HEC. Desde el punto de vista de SAP Basis y la perspectiva de un gestor de CCoE, la diferencia entre HEC y BTP es marginal - ¡pero no para el CFO y el CIO!

Las tarifas del BTP de SAP, bajas al principio, sólo se explican y revelan tras varios meses de funcionamiento. Existe una especie de obligación de cooperar en la nube de SAP: ¡sale caro! Los que no quieren o no pueden hacerlo por sí mismos tienen que aceptar un recargo significativo. Naturalmente, SAP también permanece a mano en la nube, pero rápidamente le cuesta al cliente existente un múltiplo de la cuota de mantenimiento aceptada originalmente.

Lo que el subcontratista u hoster hacía para el cliente SAP existente como servicio, el cliente existente tiene que hacerlo independientemente en la nube SAP. Naturalmente, SAP también ofrece servicios, pero estos suelen tener que pagarse por separado. Si el cliente SAP existente no puede cumplir con su obligación de cooperar, ¡le saldrá caro!

Es difícil obtener un cálculo completo de los costes porque se carece de experiencia con la computación en nube de SAP. Así pues, la plataforma tecnológica empresarial sigue siendo una costosa vía de sentido único, ya que no existe una estrategia de salida de la nube que permita volver al sistema on-prem, más barato. No se prevén periodos de transición realistas ni una vuelta al origen. El cliente actual de SAP está desconcertado por las enrevesadas hojas de ruta, y lo ha estado desde los dorados días del R/3, cuando el profesor Henning Kagermann aún tenía el atlas de SAP en sus manos.