Configuraciones no transportables en la configuración inicial del sistema de prueba para proyectos de implementación Greenfield de S/4 HANA

Antes de comenzar con el primer ciclo de pruebas integradoras, uno de los muchos desafíos que enfrenta un proyecto es garantizar que el sistema de prueba esté «listo para probar». En este artículo quiero profundizar en este desafío particular y mostrar una herramienta simple pero efectiva para enfrentarlo. Mis observaciones se realizaron particularmente en los proyectos de implementación de S/4 Hana Greenfield desde el punto de vista de la gestión de prueba/corte, pero reconozco que este artículo también puede aplicarse a un alcance más amplio de proyectos de TI.

Cuando se trata de que su sistema de prueba esté «listo para probar», a menudo hay un enfoque muy fuerte en tener todos los transportes necesarios en el sistema de prueba. Sin embargo, por lo general, el despliegue de los transportes en el entorno de prueba es solo el primer paso de una larga lista. Es más apropiado pensar en la configuración inicial del sistema de prueba como un mini corte, ya que involucra tareas de diferentes equipos/personas que dependen unas de otras y deben realizarse en un orden específico.

Si bien allí, por lo general, los equipos (o subproyectos, que comúnmente representan áreas funcionales clásicas) son conscientes de qué configuraciones deben realizarse para su área de especialización. Las dependencias de la configuración de otros equipos y el orden de ejecución son la mayoría de las veces menos transparentes. Tener que averiguar las dependencias y, por lo tanto, en última instancia, el orden de los pasos a base de prueba y error puede resultar una tarea muy frustrante y que requiere mucho tiempo para todos los involucrados.
En el peor de los casos: mientras se enfrenta a los desafíos antes mencionados, es probable que el proyecto ya esté gastando un tiempo valioso que debería haberse destinado a probar la ejecución.

Para evitar estos obstáculos y tener un sistema de prueba que realmente esté «listo para probar», la idea es crear conciencia sobre estos entornos no transportables y sus interdependencias. Esto se logra mejor creando una lista. La creación de una lista de este tipo es un proceso iterativo. El conocimiento relevante generalmente se encuentra en los equipos/subproyectos, pero establecer la transparencia con respecto a las dependencias entre tareas y entre equipos requiere recopilar comentarios de cada equipo varias veces.

Captura de pantalla de ejemplo de una lista de configuraciones no transportables como una hoja de cálculo

Esta lista de configuraciones no transportables para la configuración del sistema de prueba también se puede reutilizar como plantilla para el plan de transición para la puesta en marcha. Lo más probable es que involucrar al administrador de transición del proyecto sea una muy buena idea, ya que esto le permite maximizar el potencial de reutilización de la lista.

(Dependiendo del proyecto, la Gerencia de Transición también puede asumir la propiedad de esta lista e impulsar el proceso por sí misma).

• Tener transparencia sobre las configuraciones no transportables para la configuración inicial del sistema de prueba puede ahorrarle mucho tiempo y frustración a su equipo de proyecto.
• Establecer esta transparencia en forma de lista es un proceso iterativo que requiere aportes de todos los equipos de proyecto/áreas funcionales.
• Una lista de configuraciones no transportables se puede reutilizar más tarde como base para un plan de transición.