Un catalizador para el cambio

Sin embargo, la misma encuesta también reveló que "el 74% de los miembros del DSAG y el 13% de los miembros de ASUG creen que la introducción tendrá un impacto en los procesos empresariales". Por tanto, es probable que sea una transformación que vaya mucho más allá de las meras cuestiones técnicas y perdure mucho después de la puesta en marcha.

Esta es una de las razones por las que muchas empresas están aprovechando la migración a S/4 para reexaminar los enfoques arraigados de la gestión de los sistemas SAP y aprovechar esta oportunidad para preguntarse cómo sería un enfoque óptimo (o el mejor para su empresa en particular), teniendo en cuenta los avances tecnológicos, las cadenas de herramientas fragmentadas y las crecientes demandas de los clientes. 

En esta serie, exploro tres cambios forzados o permitidos por la migración a S/4, aunque no sean un requisito obligatorio para el éxito desde una perspectiva técnica.

Los equipos de SAP utilizan cada vez más conceptos modernos de desarrollo de software. Los beneficios de CI/CD y DevOps están ampliamente reconocidos. En este contexto, una nueva encuesta de Google descubrió que los mejores del sector pueden desplegar código nuevo unas impresionantes 6570 veces más rápido que los peores. Sin duda, los equipos de SAP pueden obtener beneficios similares.

Un proyecto de transformación de S/4 proporciona la justificación ideal para explorar nuevas formas de trabajar, no solo para acelerar el proyecto, sino también para proporcionar una mayor agilidad y productividad una vez que el sistema esté en funcionamiento. Las empresas con visión de futuro pueden incluso decidir implantar DevOps como parte de su proyecto S/4 antes de que comience, de modo que la nueva forma de trabajar ya esté en marcha y pueda añadir valor cuando se complete el paso a S/4.

La automatización es el requisito previo clave para el éxito de DevOps, ya sea en el contexto de una transformación de S/4 o no. En ambos casos, se necesita una automatización adaptada a la arquitectura técnica de SAP. El software de este tipo -como -ActiveControl de Basis Technologies- también debe proporcionar la flexibilidad, agilidad y gestión ajustada para permitir una respuesta rápida a la evolución de los procesos DevOps.

Y lo que es quizás más importante, la automatización de SAP DevOps debe vincular las cadenas de herramientas existentes para proteger aún más el proceso de cambio frente al despilfarro y el riesgo a medida que se construyen y optimizan los sistemas S/4. Esto puede ser tan sencillo como actualizar automáticamente los requisitos gestionados en Jira o ServiceNow en lugar de volver a introducirlos manualmente, o tan complejo como integrar SAP en una canalización de entrega orquestada y multiaplicación a través de productos como Jenkins o GitLab.

El mapeo del flujo de valor es un tema candente en el mundo DevOps. Es el proceso de definir cada paso que forma parte del cambio y los flujos de información necesarios para todo el recorrido de un producto de software, desde el diseño hasta la entrega. Por lo tanto, debería ser una aportación importante a la hora de diseñar su canal de entrega de software. La automatización de DevOps no facilita necesariamente la definición de flujos de valor, pero sin duda desempeña un papel central en su gestión, mediante la integración de cadenas de herramientas, la orquestación de la entrega de software, la supervisión de KPI y mucho más.

A pesar de los beneficios potenciales de DevOps para SAP, algunas empresas lo ven como un estado al que hay que llegar una vez superado el reto de la migración a S/4 con toda su complejidad. El desarrollo ágil, en cambio, es un primer paso más fácil de realizar para ellas. En la próxima edición, analizaré cómo el desarrollo ágil puede ayudar a los equipos SAP.