Desaparición de los datos SAP: ¿cuáles son sus alternativas?

En esta serie de blogs, analizaremos el final del ciclo de vida de los datos y, en algunos casos, de los sistemas. Mi objetivo es impartir experiencia y conocimientos para ayudarle a planificar un final digno y pacífico para sus sistemas y datos SAP®, en lugar de una desaparición abrupta, con problemas en la sala de servidores y personas llorando a mares (todos hemos participado en proyectos así en algún momento de nuestras carreras de TI).

Las 5 razones principales por las que los sistemas se convierten solamente en sistemas para visualizar

¿Por qué hay que poner fin a los sistemas o a los datos?

En primer lugar, analicemos cómo surge la necesidad de eliminar sistemas o datos. Existen algunos acontecimientos empresariales que pueden desembocar en que un sistema pase a ser de 'solo visualización’. Esto podría ser, por ejemplo, el caso de la copia de todo un sistema de gestión de una empresa que se ha vendido y entregado al comprador. Los requisitos financieros y legislativos obligan a la empresa vendedora a conservar los datos durante varios años después de la transacción.

O bien, puede tratarse de una empresa que ha sido adquirida. Tal vez se trate de un sistema SAP o de algún otro sistema ERP instalado de forma local. Al fusionar los procesos empresariales, se decidió reimplantar los procesos en los sistemas existentes de las empresas compradoras, pero solamente se trasladaron los elementos abiertos. Todas las transacciones históricas, que podrían ser necesarias para el cumplimiento de la normativa o como referencia, se mantienen en el sistema ‘desmantelado’.

Incluso podría ser el resultado de abandonar SAP por otra tecnología. Aunque muchas organizaciones están modernizando sus inversiones en SAP, algunas inevitablemente abandonarán el sistema y se pasarán a proveedores más pequeños y especializados en su sector. Otro caso podría ser el de organizaciones que están migrando a S/4HANA, pero que han decidido hacerlo a través de una nueva implementación, en lugar de arrastrar su sistema SAP reciente, o más antiguo, mediante otra actualización.

Todos estos ejemplos, y es muy posible que existan otros, nos llevan al mismo destino: un sistema SAP, o varios, que solo tiene como objetivo permitir el acceso a la visualización de los datos a un número muy reducido de usuarios.

Acceso a los datos necesarios desde SAP ERP

En un principio, puede parecer ridículo mantener todo un sistema ERP estándar de calidad para que un puñado de usuarios pueda utilizarlo únicamente para visualizar datos. Ahora bien, cuando se empieza a contemplar la extracción de los datos necesarios para el cumplimiento de la normativa y las futuras consultas, es cuando se abre la caja de Pandora de un modelo de datos extremadamente complicado y profundo.

Un sistema SAP típico tiene más de 30 000 tablas de datos de aplicación. Un simple código de transacción en SAP puede afectar a 50, 60, 70 o más tablas subyacentes, y los vínculos entre esas tablas no siempre son sencillos. Y en muchos casos, existen dependencias de otros tipos de datos. Al consultar un pedido de ventas, ¿estoy viendo la dirección de entrega de los datos maestros de clientes o se ha añadido una dirección específica y a medida para este pedido? Ambas opciones son posibles.

Al consultar ese pedido de venta, es posible que tenga que integrar varios elementos que se encuentran en distintas tablas. Cada elemento puede (o no) hacer referencia a los datos maestros de materiales que se almacenan en un conjunto de datos completamente distinto. Y cuando se investiga una consulta sobre el pedido de venta, es posible que también se necesiten los documentos anteriores o posteriores: entrega, contrato, documento de facturación, etc. Así que, a menos que el usuario se conforme con abrir un archivo CSV y buscar el pedido 40231100 y luego abrir otro archivo CSV para comprobar los elementos 10, 20 y 30 con el fin de ver que el material 801-110 se vendió al cliente A3000 en la dirección 34677, vamos a necesitar algo mucho más avanzado para poder acceder al significado de los datos, no solo a los datos sin procesar.

Se trata de ir mucho más allá. En las tablas de datos de la aplicación habrá referencias a la personalización de los valores. ¿Bastará con ver si estos datos se refieren a la planta 3000, o necesitaremos saber en una tabla de personalización cuál es la descripción de esa planta? O bien los datos pueden contener campos que tienen rangos de valores de dominio asignados. El usuario podría necesitar saber qué significan realmente 01, 02 y 03, no solo los códigos. La personalización en SAP es de 50 000 tablas adicionales, pero ¿cuáles son las que utiliza nuestro sistema? ¿Cuáles contienen datos predeterminados que SAP envía y que no necesitamos?

Muchas organizaciones comienzan este viaje de investigación de cómo ‘descargar solo los datos SAP’ y ver lo suficiente del modelo de datos para darse cuenta de la inutilidad del ejercicio y detenerse ahí. Esto suele estar influenciado por una visión simplista de los costes de mantenimiento de un sistema de visualización solamente, que subestima el verdadero coste en el futuro.

Mantenimiento de sistemas de solo visualización

El primer paso para convertir un sistema en uno de solo visualización es limitar las autorizaciones a solo las transacciones de visualización. Todas las interfaces ya se habrán trasladado al sistema de transacciones, pero es lógico revisar también los sistemas de comunicación (ALE, IDoc, correo electrónico, etc.) para asegurarse de que los mensajes no se envíen de forma accidental. En cuanto a la licencia, ya no es necesario el soporte de SAP en el sistema, así que no importa si este ha vencido. Puntualmente, es posible que tengamos que reiniciar el sistema para aplicar parches del sistema operativo, por lo que puede ser necesario un pequeño conocimiento de SAP Basis para ello.

Por otro lado, están los costes de disco e informática o de hardware en términos tradicionales. Si se trata de un sistema local, es probable que los servidores existentes puedan seguir funcionando con este sistema de solo visualización. No suena tan mal, ¿verdad? Quedémonos con eso y todos contentos. Los usuarios pueden acceder a los datos de la manera que deseen y no es necesario un proyecto complicado para intentar extraer los datos.

Con todo, avancemos dos o tres años en la vida de este sistema y ha sucedido lo siguiente:

• Los usuarios clave que aprovechaban SAP se han marchado. Los usuarios clave que aprovechaban SAP se han marchado. Los usuarios del departamento de finanzas están ahora familiarizados con la solución XXX para la gestión de la empresa y no tienen ni idea (ni ganas de aprender) cómo ejecutar un código de transacción de la interfaz gráfica de usuario de SAP e interpretar las pantallas de aspecto arcaico (¿alguien quiere jugar al PONG?). Además, el departamento de TI no tiene ni idea de cómo incorporar la interfaz gráfica de usuario de SAP en sus equipos de sobremesa.

• El director de TI quiere adoptar un enfoque de ‘solo en la nube’ y la sala de servidores se va a vender como parte de una transacción inmobiliaria. Alguien tiene que trasladar este sistema a Azure/AWS/GCP. ¿Funcionarán las herramientas de migración y gestión de esa plataforma en la nube con este antiguo sistema operativo?

O BIEN

• El centro de datos funciona ahora con servidores totalmente virtualizados. Hemos logrado migrar el servidor 'tal cual' a una máquina virtual, pero ahora la solución que gestiona todas las máquinas virtuales se está actualizando y no es compatible con Windows 2012. Tendremos que actualizar el servidor host SAP. Sí, pero la versión de la base de datos en uso solo es compatible con Windows 2012, así que debemos actualizar la base de datos. Eso sí, luego tenemos que aplicar un parche al sistema SAP para que funcione con las nuevas versiones del sistema operativo y de la base de datos. ¿Alguien recuerda cómo se aplica un parche a SAP? Un momento, hemos dejado de pagar el mantenimiento, así que no podemos descargar los parches.

De repente, el camino más fácil hace unos años es hoy como darse de bruces contra un muro.

Puesta a cero de una parte del sistema

Los observadores (y los más aplicados, ya que han llegado hasta aquí) habrán notado que al principio he intercambiado muchas veces ‘sistema’ y ‘datos’, pero luego me he centrado en el fin del sistema. Este es el caso de uso más común para la extinción, pero, con la creciente importancia de la privacidad de los datos en los últimos tiempos, puede haber situaciones en las que los datos deben eliminarse, incluso si el sistema continúa.

Por ejemplo, un sistema SAP con HCM en transición a SuccessFactors Employee Central. ¿Se eliminarán los datos históricos de los empleados del sistema en un futuro? Cinco años más tarde, cuando un proveedor externo tenga acceso a un sandbox para un nuevo proyecto, ¿considerará alguien que los datos de los empleados han permanecido sin cambios durante media década? Sé que mi fecha de nacimiento y mi número de la seguridad social no han cambiado en los últimos cinco años. Esos datos son tan valiosos ahora como el día en que los procesos empresariales abandonaron el sistema SAP. Por otro lado, esto puede suponer el mismo reto: tenemos que disponer de la información histórica de los salarios de esos empleados por razones de cumplimiento de la normativa. Así que, ¿dónde podríamos ponerla de modo que sea accesible para los pocos que la necesitan, en un sistema seguro y fácil de usar, y que podamos eliminarla de un sistema que hace tiempo que el departamento de RR HH. ha olvidado?

Esto podría aplicarse también a los datos de los clientes que se han trasladado a SAP Cloud for Customer, pero que todavía residen en el sistema SAP local mientras se transforma en el centro digital.