¿Dónde colocar los desarrollos internos bajo SAP?

Muchos responsables de SAP se preguntan actualmente dónde y de qué forma deben implantarse los desarrollos internos y las mejoras personalizadas.

En el pasado, antes de la llegada de las aplicaciones en la nube, las personalizaciones y adiciones se programaban siempre en el núcleo del sistema (espacio de nombres Z con modificaciones Abap), y se aceptaba el elevado esfuerzo que suponía la actualización y, a menudo, las pérdidas de rendimiento. Sin embargo, desde hace algunos años, la máxima de la empresa de software con sede en Walldorf es: Mantener limpio el núcleo.

La aplicación central, S/4, debe permanecer libre de código personalizado. Los desarrollos propios deben implementarse en escenarios side-by-side. Para ello son ideales plataformas como SAP Cloud Platform (SCP), que permiten una programación rápida y ágil, así como la integración de apps y microservicios.

Por tanto, las actualizaciones de los sistemas centrales, que ahora son mucho más frecuentes, se realizan con rapidez y sin problemas. Pero, ¿deberían desarrollarse todas las personalizaciones y ampliaciones fuera del sistema central?

Si, por ejemplo, sólo se quiere reducir el número de campos de formulario mostrados para un grupo específico de usuarios, ¿necesitas una extensión desde la nube?

De hecho, programar fuera del sistema central no siempre es la mejor solución. Las cuestiones fundamentales tienen que ver con el grupo de usuarios, los datos que hay que integrar, los escenarios de aplicación y la duración del uso.

Si hay que formar a los empleados en SAP por primera vez, hay que sopesar el esfuerzo que supone. Si se trata de grupos de usuarios externos, como socios o partes interesadas, que quizá solo utilicen algunas funciones en dispositivos móviles, el uso de una interfaz de usuario sencilla e intuitiva tiene prioridad. Esto habla a favor del desarrollo en la plataforma en nube.

Si hay una sincronización constante de datos y acceso a los datos de la aplicación central, es aconsejable hacer los ajustes directamente en el sistema central. Esto también se aplica en los casos en los que es muy importante tener un control propio sobre los datos.

En cambio, los desarrollos propios en la plataforma son el método preferido si los datos del sistema central sólo se utilizan predominantemente en el acceso de lectura a través de interfaces o si los datos están disponibles de forma redundante y si basta con una sincronización ocasional de los datos.

Estrechamente vinculada a los requisitos de integración está la cuestión de la función y el escenario de aplicación respectivo: si la ampliación se utiliza exclusivamente -y con la misma intensidad- en el sistema SAP in situ, sin que se integren servicios externos adicionales, las ampliaciones también deberían realizarse directamente en el sistema.

Por último, el periodo de uso también desempeña un papel: si la aplicación o extensión que se va a crear sólo se necesita temporalmente, por ejemplo para promociones de temporada en el comercio minorista o con fines de prueba, el propio sistema de la empresa no debe cargar con ella.

Especialmente para pruebas y prototipos, la plataforma en la nube con herramientas y aplicaciones ofrece el entorno ideal para un desarrollo flexible y ágil. Por otro lado, un desarrollo interno maduro destinado a funcionar de forma estable y a largo plazo junto con el sistema central es mejor en las instalaciones.