R/3 y ECC heredados

Pero lo que nosotros y muchos de mis compañeros habituales de SAP celebramos en su día como una ventaja competitiva está resultando ser un legado plomizo frente a la transformación digital a S/4. Los crecidos monolitos de SAP ERP, entremezclados con millones de líneas de código específico de nuestros clientes, parecen ahora excavaciones arqueológicas más que arquitecturas informáticas modernas. Con el paso de los años, muchos de estos sistemas se han convertido en meros colosos, modificados hasta resultar irreconocibles, con hasta un 60% del código que a menudo ya no se utiliza durante el funcionamiento -como pude comprobar-, pero que sigue ocasionando costes de mantenimiento y albergando riesgos de seguridad.

El reto de la conversión a Abap es mucho más que una tarea de diligencia técnica; es un corte brutal en la historia de nuestro Grupo. Mientras que los cambios de versiones anteriores eran a menudo de naturaleza puramente técnica y confirmaban el lema „Nunca cambies un sistema en funcionamiento“ (como el redactor jefe Färbinger no se cansa de subrayar), S/4 exige un cambio radical de paradigma. El cambio a Hana y el nuevo modelo de datos ERP dejan obsoletas muchas viejas construcciones Abap. Las sencillas sentencias SQL que dependían de la existencia de determinados agregados o índices se quedan en nada, y los llamados elementos de simplificación de SAP obligan a los desarrolladores a revisar a fondo o incluso a desechar su código.

Tenga en cuenta lo siguiente: Muchas funciones antiguas que siguieron funcionando en el marco de la primera migración a S/4, véase Paquetes de compatibilidad, tuvieron que convertirse a nuevas funciones de S/4 a finales de 2025. La lista de simplificación de SAP define miles de cambios y omisiones funcionales para cada versión de S/4, que determinan de forma significativa el proceso de migración del sistema. Ya no basta con adaptar sintácticamente el código, sino que hay que alinearlo semánticamente con la nueva lógica del „Principio de Uno“, que elimina rigurosamente las funciones redundantes. En esta zona de tensión entre preservación y renovación, SAP propaga la estrategia „Clean Core“ como única salida de la trampa de la modificación. La filosofía es sencilla, pero la puesta en práctica nos resulta cuando menos dolorosa. Pero vemos la luz al final del túnel: un antiguo compañero del profesor Hasso Plattner en el HPI de la Universidad de Potsdam, el profesor Dr. Alexander Zeier, presentó un sistema de IA como estrategia de salida para Clean Core y las modificaciones de Abap.

El núcleo digital del sistema ERP debe permanecer limpio y libre de modificaciones para garantizar la capacidad de actualización y la agilidad en la nube. Los días en que se retocaba directamente el programa estándar de SAP (modificación) han pasado a la historia. El nuevo modelo exige una separación estricta entre el código estándar y las mejoras. Para los clientes actuales de SAP, esto significa que tienen que transferir sus queridos programas Z y aplicaciones de pantalla a arquitecturas modernas y nativas de la nube.

Pero, ¿cómo lograr este equilibrio sin paralizar los procesos empresariales? La respuesta está en un modelo de extensión diferenciado. Las extensiones críticas que están estrechamente entrelazadas con los datos y las transacciones del núcleo pueden realizarse como „extensiones on-stack“ utilizando Abap Cloud. Todo lo demás, especialmente las innovaciones puntuales o las aplicaciones móviles, pertenece como una extensión lateral en el BTP, desacoplada del núcleo del ERP. Para los sistemas heredados, esto significa a menudo una refactorización masiva: el código tiene que ser analizado, limpiado y, si no se ajusta a la norma, envuelto en una envoltura o completamente reescrito.

En esta tormenta de transformación, el Customer Centre of Expertise (CCoE) de SAP ha adquirido un significado existencial completamente nuevo, que ha dado lugar a acaloradas discusiones en nuestra mesa de habituales de SAP. En el mundo on-prem, el CCoE (CCC cuando yo era director de TI en activo) era a menudo el principal responsable del soporte de primer nivel y de la gestión de licencias, pero ahora tiene que transformarse en el centro de control estratégico del panorama de la TI híbrida. El CCoE ya no es sólo responsable de las operaciones, sino de la gobernanza de toda la arquitectura. Debe supervisar el cumplimiento de los principios básicos de limpieza y garantizar que los departamentos especializados no vuelvan a caer en viejos patrones y produzcan un crecimiento incontrolado.