Si después de la pandemia no ha volado a otros países, prepárese para un probable revés cuando vuelva a hacerlo. La experiencia es mucho más imprevisible de lo que solía ser. «La terminal era prácticamente para mí solo cuando hice el tránsito en Heathrow. Había un silencio sorprendente en un momento que suponía de gran actividad. Unas semanas después, tuve que hacer cola de una hora para dejar las maletas cuando ya había facturado para un vuelo europeo de corta duración. Y hace poco, el temido «vuelo cancelado», que solo se anunció a las 11 de la noche.
¿Cuál es la relevancia de RISE with SAP® y la gestión de datos de prueba junto con nuestra solución Data Sync Manager™? Mi experiencia con ambas soluciones me dice que todo depende de la planificación, porque de lo contrario puede haber situaciones difíciles innecesarias y costes adicionales no deseados.
Siempre se prevé el aumento de espacio del entorno de producción de SAP con el objeto de garantizar una capacidad suficiente conforme la empresa almacena cada vez más datos. Y es posible que en la planificación se incluya la repercusión de esto en los sistemas de prueba, en consonancia con la estrategia y los plazos de actualización.
Antes de pasar a RISE, esto puede hacerse casi de forma reactiva en el momento en que surja un problema. No obstante, cuando se pasa a un modelo de costes como el de RISE, lo primero es acordar cómo serán los volúmenes de los sistemas a lo largo del contrato. Hemos comprobado que las organizaciones adquieren la suite Data Sync Manager (DSM) más adelante para reducir el tamaño de los sistemas que no son de producción, si bien no obtienen todo el ahorro de costes, en comparación con el contrato RISE que se firma con el sistema de prueba, que es una cuarta parte del tamaño del de producción.
El sistema actual puede pasar a RISE sin una actualización S/4HANA inmediata, aunque la mayoría de las organizaciones tienen previsto pasar a S/4HANA como parte de su estrategia RISE with SAP. El coste de un sistema de prueba sobredimensionado puede no ser demasiado atractivo en los sistemas de bases de datos tradicionales, aunque cuando se pasa a la base de datos HANA, la tecnología intramemoria requerida tiene un coste mucho más elevado (normalmente más de tres veces el coste, según nuestra experiencia), y la capacidad de escalar en pequeños incrementos desaparece. Cuando un sistema supera el límite de espacio, el siguiente tamaño suele ser el doble, con el correspondiente impacto en el coste (salvo algunas economías de escala, cabe esperar).
Lo interesante de utilizar Client Sync, que forma parte de la suite DSM, para actualizar sus sistemas de prueba no es solo que implica que sus sistemas de prueba pueden ir en un dispositivo HANA más pequeño o en un soporte de tamaño de hiperescalador. Consiste en que sus sistemas de prueba pueden permanecer fijos en ese tamaño, aunque la producción aumente de manera considerable. Esto es así porque normalmente se utiliza Client Sync para crear un sistema de prueba con 3, 6 o 12 meses de historial transaccional. Por lo tanto, cuando se actualice dentro de un año, el tamaño solo será mayor si:
la empresa realiza ahora muchas más transacciones que antes;
se crean muchos más datos maestros.
Y, aunque se cumpla una de esas condiciones, el tamaño puede modificarse un poco cambiando la fecha de corte o limitando el sistema de prueba solo a determinadas sociedades. Incluso si se trata de una medida a corto plazo hasta el siguiente ciclo de contratación.
Junto con otras dos certificaciones, DSM cuenta ahora con la certificación «compatible con RISE with SAP». Así que, tanto si implementa DSM antes de pasar a RISE como si lo hace como parte del proyecto de pasar a RISE, no deje que le obliguen a firmar un contrato RISE con más espacio del que realmente necesita para aprovechar los sistemas que no son de producción.