Migración a SAP S/4 Hana

Los clientes existentes de SAP deben migrar a la nueva generación de software S/4 Hana antes de 2025. SAP solo ha dado una garantía de soporte para ERP/ECC 6.0 hasta entonces, la última vez en el Congreso Anual 2018 de la DSAG. La mayoría de los clientes existentes de SAP asocian la migración con el objetivo de un panorama de aplicaciones ágil que les ayude a dominar los retos de la digitalización.

Pero cuidado: lo que es totalmente correcto como objetivo a nivel de aplicación no puede transferirse de uno en uno al nivel de datos. Esto se debe a que los datos de las aplicaciones empresariales siempre se encuentran en un contexto empresarial, que por motivos legales debe conservarse junto con los datos durante los periodos de conservación legalmente establecidos. Este contexto empresarial también contiene información adicional importante, por ejemplo sobre el historial y la calidad de una relación comercial con un cliente o proveedor, que puede ser valiosa para la empresa en cuestión incluso años después.

Así que, a nivel de datos, se trata menos de agilidad y más de estabilidad. Esta es la razón por la que cada migración a nuevas generaciones de software -tanto dentro como fuera de SAP- conduce a la acumulación de grandes volúmenes de datos en los centros de datos de las empresas, que se conservan y mantienen junto con las aplicaciones heredadas debido al contexto empresarial, en algunos casos durante muchas décadas y con un coste considerable.

Al cambiar a S/4, surge de nuevo, y de forma agravada, el problema de tener que seguir operando con los sistemas heredados. Por un lado, no tiene sentido por razones de costes transferir todos los datos y documentos de los sistemas heredados a la base de datos Hana.

Aunque los medios de almacenamiento se han abaratado considerablemente en general, la memoria principal y los recursos informáticos siguen requiriendo una inversión significativa. Por otra parte, la estructura de datos cambiará masivamente al pasar a SAP Hana. Por ejemplo, el número de tablas en las grandes instalaciones se reducirá de más de cien mil a un máximo de quince mil a veinte mil. Esto expone a las empresas a enormes riesgos legales si no encuentran una solución sensata para sus datos y sistemas heredados.

Una cuestión de arquitectura

Por lo tanto, la pregunta más importante es: ¿cómo pueden conciliarse los objetivos opuestos de agilidad y estabilidad? Con la ayuda de un nuevo enfoque: una arquitectura diferente del paisaje de aplicaciones que separe los datos y documentos heredados de las aplicaciones ágiles del futuro. De este modo, los sistemas heredados pueden desconectarse y las nuevas generaciones de software pueden mantenerse ligeras y ágiles a largo plazo.

El elemento clave de esta nueva arquitectura es un entorno independiente del sistema para los datos, los documentos y su contexto empresarial que ya no son necesarios en los sistemas operativos.

Un entorno de este tipo garantiza la estabilidad necesaria a nivel de datos. Al mismo tiempo, aumenta la seguridad jurídica e informática. Esto se debe a que, a diferencia de muchos sistemas heredados, puede seguir parcheándose y protegiéndose. También permite gestionar sin fisuras todo el ciclo de vida de los datos y documentos heredados a nivel de registros de datos y documentos individuales mediante funcionalidades de gestión de la retención. Esto incluye explícitamente la eliminación selectiva de datos y documentos, uno de los requisitos clave del Reglamento General de Protección de Datos (RGPD).

La certificación conforme a la norma IDW PS 880 del Instituto de Auditores Públicos de Alemania garantiza que los auditores y las autoridades fiscales también confíen en este entorno en lo que respecta a la inmutabilidad de los datos y documentos transferidos desde los sistemas operativos, así como su contexto empresarial.

Ahorre hasta un 80

El resultado: las aplicaciones heredadas pueden desconectarse, lo que supone un ahorro operativo de hasta el 80% -y a veces incluso más- en comparación con su funcionamiento continuado. Pero esto es igual de importante en el contexto de la próxima migración a S/4:

Si los datos y documentos empresariales se externalizan a este entorno en cuanto dejan de ser necesarios desde el punto de vista operativo, las aplicaciones y sistemas actuales seguirán siendo ágiles y sencillos a largo plazo. Por regla general, el volumen de datos operativos puede reducirse entre un 50 y un 75 por ciento. Se evita así cualquier lastre innecesario.

Un simple cálculo muestra por qué esto es tan importante: alrededor de 10.000 clientes actuales de SAP tienen su sede en países de habla alemana. Incluso si suponemos una media de 2.000 días-hombre por proyecto, en 2025 habría una necesidad de capacidad de 20 millones de días-hombre en el mercado DACH, es decir, unos 3,2 millones al año.

Incluso si todos los 2.000 expertos en migración de datos que se calcula que hay en los países de habla alemana trabajaran los 365 días del año, sólo se dispondría de una capacidad de 730.000 días-hombre al año.

Incluyendo las vacaciones y otros periodos de inactividad, se necesitarían cinco veces más expertos en migración de los que realmente hay disponibles para realizar los proyectos de aquí a 2025. Según Adam Riese, esto simplemente no será posible.

Gane tiempo y vuélvase ágil

Si los datos y contenidos que ya no se necesitan se transfieren continuamente de las aplicaciones operativas a una plataforma independiente del sistema legalmente segura, la TI corporativa en su conjunto se vuelve mucho más ágil y puede dar soporte a una amplia gama de escenarios empresariales con muy poco esfuerzo.

Ejemplo: Adquisición y venta de empresas y divisiones empresariales:

Es importante decidir qué aplicaciones debe asumir la empresa adquirida porque tienen ventajas sobre las propias y cuáles ya no son necesarias. Esto está directamente relacionado con la cuestión de qué datos y documentos deben migrarse a los sistemas vivos. El funcionamiento continuado de los sistemas heredados en las empresas es una de las principales razones por las que el 80% de todo el presupuesto de TI suele gastarse sólo en operaciones.

También existen riesgos de cumplimiento y seguridad si los sistemas adquiridos ya no pueden mantenerse o protegerse de forma fiable con parches de seguridad periódicos. Y la retroadaptación, por ejemplo para cumplir los requisitos de eliminación del GDPR de la UE, ya no es técnicamente posible para muchos sistemas heredados o solo puede realizarse con un gran coste.

Ejemplo: Consolidación de entornos de aplicaciones heterogéneas en sistemas centralizados como SAP:

La consolidación del entorno de sistemas SAP no es un proyecto puramente técnico. Se trata más bien de una combinación de objetivos empresariales y estratégicos: La centralización pretende reducir la complejidad, disminuir los correspondientes gastos de mantenimiento, administración y costes y acelerar la innovación.

Así, la consolidación de los entornos SAP distribuidos globalmente ofrece la posibilidad de implementar cambios y desarrollos posteriores con mayor rapidez y hacer que estén disponibles a escala mundial. Sin embargo, estos objetivos sólo pueden alcanzarse si se desmantelan los sistemas heredados.

Ejemplo: Consolidación de centros de datos distribuidos por todo el mundo:

Los proyectos de consolidación de centros de datos comienzan con un inventario exhaustivo y un análisis del panorama de aplicaciones y sistemas. ¿Cuáles de ellos pueden trasladarse realmente a la ubicación central sin grandes cambios? ¿Existen normativas y leyes locales que prohíben el traslado porque los datos relativos a determinadas transacciones o personas, como la contabilidad financiera o los recursos humanos, no pueden cruzar las fronteras nacionales?

Todas estas consideraciones ponen en peligro el objetivo real de la consolidación, la centralización, y también amenazan con hacer que el traslado parcial sea muy complejo y, por tanto, largo y costoso. Al fin y al cabo, muchas ubicaciones no pueden desmantelarse si no se encuentra una solución para los datos y documentos heredados.

Factor de calidad de los datos

Ejemplo de calidad de datos: Un cliente, muchos registros de datos y, además, diferentes, por lo que las empresas suponen diferentes clientes en lugar de uno. Esto se debe a que no pueden determinar ninguna relación entre los conjuntos de datos durante las evaluaciones.

Esta es la situación actual en muchas empresas. Sin embargo, el análisis detallado de los datos es un requisito previo para optimizar los procesos digitales y crear nuevos productos y servicios digitales. Si no se tiene una visión correcta del historial de compras de un cliente, no se le podrá dirigir las ofertas adecuadas ni el nivel de personalización adecuado. En resumen, falta la base de los modelos de negocio digitales.

Futuro

Durante el tiempo anterior y posterior a la migración a S/4 Hana: los sistemas SAP crecen. Incluso al cabo de poco tiempo, hay que ampliar la capacidad de almacenamiento y aumentar los recursos informáticos para que las solicitudes de los usuarios empresariales contra el sistema no tengan un impacto negativo notable en el rendimiento. Los clientes actuales de SAP se enfrentan a un nuevo reto. Esto se debe a que, por lo general, sus sistemas actuales aún no se ejecutan en la nueva base de datos Hana, sino en uno de los sistemas DBMS relacionales habituales. Sin embargo, en el futuro tendrán que adquirir licencias para SAP Hana, que también dependen del volumen.

Por lo tanto, los clientes de sistemas heredados de SAP tienen un gran interés en reducir sus activos de datos antes de migrar a la base de datos de Hana. La solución a los retos en los escenarios empresariales mencionados consiste en desmantelar los sistemas informáticos que ya no son necesarios y transferir los datos y documentos que contienen a una plataforma moderna para poder gestionar el ciclo de vida de la información heredada y su contexto empresarial.

Si determinados datos y documentos no pueden salir de las fronteras nacionales, pueden almacenarse y mantenerse en instancias locales de la plataforma, pero son accesibles en todo el mundo. Además, se puede comprobar la redundancia, coherencia y corrección de los datos y corregirlos y enriquecerlos en función de las normas.

La plataforma JiVS, basada en Java, se desarrolló precisamente para estos y otros escenarios ágiles de negocios y aplicaciones. Se caracteriza por su capacidad para seguir almacenando los datos de los sistemas heredados desactivados, pero también los documentos asociados, en su contexto empresarial y de forma legalmente segura. JiVS es, por tanto, el elemento central de un panorama de aplicaciones ágil en las empresas: Este es el enfoque correcto.