Si queremos hacer la conversión a S/4 Hana debemos saber que la migración de código custom es parte de este proceso. En este contexto sigue existiendo la incógnita de cómo enfrentarnos a un proyecto de este tipo, con el menor impacto posible en los procesos de negocio.
En la búsqueda de alternativas fiables nos encontramos con la solución de Focused Build de Solution Manager. Desde esta solución, es posible realizar la gestión de todo el proyecto incluyendo el proceso de testeo del sistema. Debemos recalcar que no es obligatorio utilizar toda la solución que nos proporciona SAP, sino que podemos hacer un uso reducido de esta herramienta, para el seguimiento de las pruebas asociado al código de cliente.
Como punto inicial, debemos saber cuál es el código que se verá afectado en nuestra transformación a S/4 Hana. Para ello, SAP nos proporciona las siguientes herramientas:
- Abap Test Cockpit (SAP GUI)
- Custom Code Migration (Fiori app)
Para que la información obtenida en ambas herramientas sea fiable, se recomienda tener las estadísticas de uso activas, durante al menos un año usando el ABAP Call Monitorig (transacción SCMON) o Usage Procedure Log (UPL) en nuestro sistema productivo. La finalidad de la activación de las estadísticas de uso es detectar el código usado y no usado en el sistema de producción. Siendo mejor usar el SCMON ya que, además de detectarnos el uso del objeto también nos detecta en que proceso de negocio se usó. Podría decirse que el SCMON es la “evolución” del UPL.
Gracias a la activación de las estadísticas de uso, podemos saber cuál es el código que no se usa en nuestro sistema de producción y así poder eliminarlo, incluso antes de realizar la conversión a S/4 Hana, con esto se ahorrará tiempo y dinero en el proceso, ya que tendremos menos objetos custom que debemos modificar.
De las dos herramientas que tenemos para detectar el código impactado en el proceso de conversión, recomendamos usar la segunda: Custom Code Migration, ya que, con esta herramienta además de obtener el código que debemos modificar, obtenemos una serie de entry points que usaremos más adelante para poder hacer el plan de testeo de nuestro sistema. Es decir, una vez hecho el análisis, obtendremos el código custom que debemos adaptar en nuestra transformación y además nos indica en que transacciones, report, jobs, etc se ha usado este código en nuestro sistema de producción. Adicionalmente, obtenemos el número de veces que se ha usado cada transacción, report, job, etc, para así poder elegir la mejor opción para la ejecución de las pruebas.
También debemos señalar que con la herramienta Custom Code Migration tenemos la opción de borrar el código Z, que no se usa en el sistema directamente con el SUM al hacer la conversión a S/4 HANA.
Con toda la información obtenida del análisis de nuestro sistema y con el objetivo de darle continuidad a nuestro proyecto, podemos utilizar el Focused Build de Solution Manager para la gestión de los casos de pruebas. En esta herramienta nos crearemos un plan de pruebas donde añadiremos todas las transacciones, reports, jobs, etc, que hemos obtenido del análisis anterior y así poder probar que nuestro sistema funciona correctamente después de la conversión a S/4 HANA. Dentro del plan de pruebas que hemos creado, podemos asignar las distintas tareas a los usuarios que vayan a testear el sistema. Además, estos usuarios pueden acceder directamente al sistema backend, donde deben comprobar que todo funciona correctamente. Una vez finalizado el testeo pueden poner comentarios en sus tareas, subir documentos y poner el estado de la prueba que han realizado.
Con todo esto conseguimos que con una única herramienta ver el estado general del proyecto. Que test han sido satisfactorios y cuales hay que revisar. Por lo que Focused build puede ser una buena herramienta para la gestión de nuestro proyecto de conversión a S/4 Hana.