Transformación a SAP S/4 Hana: La agilidad necesita automatización

Ningún tema ocupa actualmente más a los departamentos de SAP que el cambio a SAP S/4 Hana: ¿Deben transferirse los datos, los procesos y la personalización sin cambios al nuevo mundo?

¿O puede aventurarse un inicio greenfield con la introducción? ¿Y cuál de las muchas gradaciones entre los dos enfoques extremos, brownfield y greenfield, se adapta mejor a la situación de cada cliente?

No hay respuestas sencillas a estas preguntas fundamentales. Al fin y al cabo, las empresas han invertido mucho tiempo y dinero en la personalización. Además, por razones empresariales, dependen de funcionalidades que sólo estarán disponibles con las próximas versiones de S/4.

Por lo tanto, es probable que muchos clientes actuales de SAP emprendan el camino hacia el nuevo mundo paso a paso: primero consolidarán sus distintos sistemas SAP ERP/ECC 6.0, luego pasarán a la base de datos Hana y, por último, implantarán las primeras aplicaciones S/4.

Como resultado, ejecutarán ambas generaciones de software en paralelo. Con este "mantenimiento dual", los equipos de SAP tienen que desarrollar, probar y aplicar cambios e innovaciones para ambos mundos y aplicar actualizaciones en ambos entornos.

Además, las plantillas de los sistemas SAP ERP/ECC y S/4 deben protegerse y mantenerse para evitar dificultades causadas por diferentes cambios en una misma configuración en ambos mundos.

Para que esta complejidad no vaya en detrimento de la agilidad, los responsables de SAP se plantean cada vez más la conversión de sus procesos a DevOps. Las ventajas asociadas de poder reaccionar más rápidamente a los requisitos empresariales y ofrecer innovaciones gracias a la estrecha integración del desarrollo y las operaciones son demasiado evidentes.

Sin embargo, especialmente en proyectos de gran envergadura como la introducción de SAP S/4, no se puede permitir que nada salga mal, hay que evitar a toda costa las caídas del sistema y, por tanto, las pérdidas de negocio.

Control frente a riesgo: ante esta disyuntiva, muchos responsables de SAP siguen aferrándose al modelo de cascada, de eficacia probada. Y ello a pesar de que no cuestionan el concepto DevOps per se y de que SAP también hace mucho por convencer a sus clientes de las ventajas de DevOps.

Por ejemplo, los métodos ágiles han sido soportados en SAP SolMan desde 2010 y han formado el núcleo de SAP Activate, la metodología de implementación para S/4, desde 2015. Específicamente en la implementación de requisitos, SAP Activate prevé la implementación en ciclos cortos e iterativos -los llamados sprints- por equipos pequeños, efectivos e interdisciplinarios de desarrolladores, administradores y gestores de calidad, siguiendo el modelo del enfoque ágil Scrum.

Para abordar el problema de la complejidad en el camino hacia S/4 y pasar del modelo en cascada a métodos más modernos como SAP Activate o DevOps en su totalidad, la solución para los equipos de SAP pasa por la automatización.

Esto beneficia no sólo a los procesos de desarrollo y entrega, sino también a los procesos de prueba. Esto se aplica por igual a las pruebas de nuevas funciones como parte de la migración y a las pruebas de regresión de los procesos existentes en SAP ECC.

Debido al tamaño y la complejidad de los entornos SAP antiguos y nuevos, estos procedimientos de prueba exhaustivos sólo pueden realizarse mediante la automatización. Por el contrario, si los transportes y los cambios se realizan manualmente y a un ritmo elevado, la integración y el despliegue continuos conllevan riesgos.

De hecho, solo la automatización crea la confianza necesaria en DevOps en entornos SAP. Y cuanto mayor sea el nivel de automatización en Continuous Delivery, Continuous Integration y Continuous Testing, más rápido tendrán éxito la migración y la transformación a S/4.

Para que los responsables de SAP ya no tengan que elegir entre control y riesgo, es necesaria una cadena de herramientas integrada y altamente automatizada para todas las fases de la migración, incluido el mantenimiento dual.