Por qué necesita Data Sync Manager antes de actualizar su S/4

Por qué necesita Data Sync Manager antes de actualizar su S/4

Tarde o temprano llegará S/4

Muchos de nuestros clientes de Data Sync Manager (DSM) decidieron comprar DSM como parte de un gran proyecto. Con frecuencia, esto sucede cuando el proyecto pone de manifiesto, desde el principio, el riesgo que suponen los sistemas de prueba antiguos con datos inexactos para el proyecto. En un momento en el que muchas organizaciones están planeando iniciar su transición a S/4, me gustaría exponer cómo el hecho de ser cliente de DSM puede ayudarle antes, durante y después de la migración a S/4: posiblemente el mayor proyecto SAP que tenga en perspectiva.

Antes: racionalización del landscape previa a la migración con infraestructura previa

Muchas organizaciones tienen un landscape SAP que no es de producción. Algunos sistemas son copias antiguas de producción y otros sistemas multicliente son reliquias de antiguos proyectos que ya han finalizado. En los últimos 20 años, el almacenamiento a nivel empresarial se ha vuelto más asequible y gestionable. Como consecuencia, los entornos SAP han podido utilizar cada vez más espacio. Sabiendo que S/4 es inminente y que la tecnología de bases de datos en memoria es mucho más costosa que los discos, ha llegado el momento de deshacerse del exceso de equipaje. Y, al mismo tiempo, asegurarse de disponer de buenos datos de prueba para cada parte del proyecto S/4, sea cual sea el método que se adopte. Con DSM, puede crear nuevos sistemas, equiparlos con clientes seguros que contengan datos enmascarados y utilizarlos para reemplazar los sistemas de prueba existentes. También puede utilizar la potente capacidad de eliminación de clientes de Client Sync para eliminar los clientes redundantes y borrar los que desee restablecer con datos correctos. Descubra cómo desvelar los datos de prueba invisibles de SAP para recuperar los costes.

Antes: pasos de preparación de S/4

Hay una serie de pasos que se pueden llevar a cabo incluso antes de iniciar su proyecto S/4 como, por ejemplo, la fase de integración de clientes y proveedores. Esta y otros factores pueden iniciar un proyecto de limpieza y depuración de datos. Tener la capacidad de incorporar datos a la carta en el sistema de desarrollo o sandbox podría hacer que estos proyectos previos funcionales requieran mucho menos tiempo y tengan más probabilidades de éxito a la hora de mostrar el trabajo que se va a realizar en producción. Disponga de datos de prueba fiables cuando los necesite, seleccione y copie solo los que necesite. Vea cómo funciona Object Sync .

Antes: enmascaramiento de los datos sensibles

Es posible que en su proyecto S/4 participen varios proveedores de servicios de información y consultorías especializadas, y que necesiten empezar a examinar los sistemas que no son de producción para realizar sus recomendaciones, preparar informes de análisis y determinar el alcance de posibles proyectos. Estas organizaciones pueden conectarse desde cualquier parte del mundo y necesitan ver datos precisos, PERO no datos personales reales. El número de filtraciones de datos que acaparan titulares en todo el mundo es cada vez mayor: no se arriesgue a que alguien descargue una tabla de datos sensibles de un sistema de control de calidad y la venda al mejor postor. Data Secure le ofrece control total de todos los datos sensibles.

Durante: sandbox

SAP recomienda realizar primero un sandbox antes de iniciar el proyecto en su totalidad. Descubra aquí más. información sobre qué sucede en ese sandbox. Cuanto más preciso sea el sandbox, mejor será. Sin embargo, una copia de toda la producción significará un dispositivo más grande y más costoso. Utilice DSM para crear un sandbox sencillo y específico para el proyecto y considere la posibilidad de recurrir a la nube, dado que la duración del proyecto del sandbox no está clara y hay que dar soporte a la empresa mientras tanto. Descubra cómo Ballance Agri utilizó DSM en su fase de sandbox de S/4.

Durante: reconstrucción de los sistemas que no son de producción a partir de la nueva producción

A cualquiera que adopte el método de infraestructura previa, le recomendaría que tuviera en cuenta la gran diferencia existente entre la configuración, la personalización y el código del sistema de desarrollo y la producción. A lo largo de los años, esa diferencia se ha hecho cada vez más pronunciada con el abandono del antiguo código Z, el traslado de la configuración a control de calidad y posteriormente, la cancelación del proyecto e incluso la instalación de complementos de terceros en desarrollo que nunca se desinstalaron. Nuestros equipos de migración utilizan DSM para reconstruir un nuevo landscape de no producción a partir del sistema de producción, como parte de su estrategia de migración a la nube. Esto también podría formar parte de su estrategia de migración a S/4.

El hecho de reconstruir el desarrollo y el control de calidad desde la producción significa un comienzo más depurado en el otro extremo, con una menor diferencia entre el desarrollo y la producción, por lo que hay menos posibilidades de que se cuelen los defectos. Algunas organizaciones incluso lo han hecho con copias completas como parte de su migración y han descubierto los costes cuando ya es demasiado tarde. Presumiblemente, la reducción del volumen de código personalizado que hay que reformular es un gran estímulo. El uso de DSM para crear nuevos sistemas de prueba y desarrollo más pequeños puede aportar la misma ventaja a la hora de eliminar la diferencia entre el desarrollo y la producción, y reducir la cantidad de código Z que hay que volver a crear, pero a una parte del coste, ya que pueden utilizarse dispositivos más pequeños.

Durante: activación de opciones de nube híbrida

Con la capacidad de enmascarar los datos al salir, también se puede considerar la posibilidad de mantener un entorno de producción en las instalaciones y trasladar todos los sistemas que no son de producción a la nube. Esos son los sistemas que más pueden beneficiarse de la elasticidad de los recursos en la nube. Inicie los sistemas durante las fases clave del proyecto y apáguelos cuando no los necesite. Con Object Sync y Client Sync actualizando los datos de prueba, no habrá personas reales ni datos sensibles que salgan de su red.

Después: incompatibilidad de TDMS con S/4

Una vez que se hayan hecho realidad sus sueños en S/4, este no será el final de la transición. Los equipos técnicos querrán adoptar S/4 como componente central digital de la empresa inteligente. Es probable que existan muchos proyectos posteriores que aprovechen las posibilidades de la inteligencia artificial, el aprendizaje automático, etc., a medida que su empresa trata de encontrar o mantener su ventaja frente a la competencia. Todos esos proyectos necesitarán datos de prueba precisos y un ágil landscape de no producción. La tan denostada solución TDMS, que llevó a muchos de nuestros clientes a descubrir DSM en primer lugar, no es compatible con S/4 y, por los cambios que hemos realizado en nuestra arquitectura en los últimos cuatro años para gestionar las nuevas tecnologías utilizadas por S/4, es difícil ver cómo podría hacerlo. DSM se utiliza, es compatible y tiene certificación en S/4.

Después: mantenimiento de los sistemas de prueba en el mismo dispositivo, incluso si la producción aumenta

A medida que su sistema SAP acelera para alcanzar la migración a S/4, sin duda su presencia aumentará. Los dispositivos tendrán que ampliarse o reducirse, pero es posible que su landscape de no producción no tenga que hacerlo. Con una planificación cuidadosa y el uso de DSM Client Sync, puede mantener actualizados los dispositivos de prueba más pequeños con subconjuntos de producción, lo que significa que la tasa de crecimiento de los sistemas de prueba es mucho menor que la de producción.

¿Desea ayuda para planificar su migración a S/4?

Nuestro informe de evaluación de S/4 puede ofrecer una idea precisa de los posibles niveles de esfuerzo de cada estrategia, así como una advertencia anticipada de los posibles obstáculos considerables que puedan surgir, incluidos:

• Elementos de comprobación de la preparación de SAP que serán relevantes para su sistema,

• Número de clientes/proveedores sin BP vinculados,

• Bloqueadores técnicos como el sistema no Unicode,

• Áreas de SAP utilizadas por su sistema que ya no son compatibles,

• Cantidad de código personalizado,

• Panel de control interactivo visual del sistema para enmarcar las conversaciones internas.

Reserve hoy mismo su evaluación gratuita. También puede recibir actualizaciones periódicas suscribiéndose a este hilo del blog; simplemente añada su dirección de correo electrónico en 'Get Instant Updates' (Obtener actualizaciones instantáneas).