En este panel conversatorio nos compartieron su conocimiento y experiencia las siguientes colegas, expertas en esta área: Rosa Quiroz, Marcela León y Annia La O Thaureaux, centrándose en el cambio de paradigma del rol de QA. Se critica el modelo tradicional de trabajo en silos (roles aislados) y la entrega secuencial, donde el tester actuaba como un ejecutor de checklists. La visión moderna aboga por la colaboración y el testing holístico, donde la responsabilidad de la calidad es de todos. Esta transformación se define por el movimiento Shift Left, que enfatiza la necesidad de anticipar problemas e involucrar la calidad y las pruebas desde las fases tempranas de desarrollo, idealmente desde los requerimientos.
Entrando en tema
Los proyectos de migración o implementación SAP, especialmente hacia plataformas modernas como S/4HANA, representan una «transformación profunda» y estratégica para las organizaciones. El panel de expertos coincidió en que estos emprendimientos son «gigantes» y requieren una preparación que se extiende durante años, no meses. La realidad de estos proyectos impone una tensión constante entre la adhesión a metodologías estructuradas (como SAP Activate) y la necesidad de adaptabilidad y resiliencia del equipo de Aseguramiento de la Calidad (QA).
I. La Dimensión y escala de la transformación
El principal reto que define la estrategia de QA es la escala operativa del proyecto. Marcela León relató la migración en una empresa educacional que, aunque exitosa, involucró la selección de 40 usuarios clave de 1000 potenciales, gestionando 13 transacciones y 350 desarrollos customizados o «Zetas». Por su parte, el proyecto de COPEC, que se encontraba en etapa explore, anticipaba una magnitud considerablemente mayor, con un volumen de 300 o más usuarios que tendrían que probar, y una previsión de más de 3,000 casos de prueba.
La complejidad no solo recae en el volumen de datos o usuarios, sino en la naturaleza de la migración:
• Modelo Híbrido (COPEC): COPEC enfrentaba una migración híbrida de datos, con un 80% en modelo Brownfield (mantener desarrollos existentes) y un 20% en Greenfield (nuevas implementaciones). Esta combinación exige estrategias de prueba duales y una gestión estricta del riesgo.
• Mantenimiento Dual (Dual Maintenance): Un desafío recurrente y «superdesafiante» es que la compañía debe seguir operando y desarrollando en el sistema antiguo mientras se implementa la migración (HANA). Esto requiere una estrategia clara sobre qué nuevos desarrollos entran al scope de la migración y cómo se incorporan en las pruebas de regresión.
II. Gestión de procesos y la búsqueda de gobierno
La aplicación del «filtro de realidad» comienza al inicio de estos proyectos, donde la falta de gobernanza de procesos es común. Annia La O reveló que partieron de una realidad sin «un gobierno total de los procesos de la compañía». La solución crítica fue invertir en la fase preparatoria (un año antes de la migración) para crear un catálogo de procesos.
La estrategia de COPEC se centró en utilizar el enfoque de proceso como una «herramienta de acercamiento entre el área de negocio y las áreas de tecnología». El negocio aportaba el know-how (qué se hacía) y tecnología complementaba con la información técnica (qué transacciones y tablas). Esto era crucial para alcanzar un diseño de proceso completo, no solo un flujo de actividades, sino un insumo funcional para las pruebas.
Este enfoque es vital porque, en palabras de Marcela León, la idea de la migración se centra en la preocupación por las Transacciones Z, aquellas que son modificaciones o customizaciones críticas para la empresa.
III. El rol pivote del QA: de la ejecución a la colaboración
La necesidad de QA en proyectos SAP es innegable; los expertos lo calificaron de «impensable» y enfatizaron que el QA es el «puente» o el cross de procesos y pruebas entre las células técnicas y la operación.
1. El desafío de habilidades y recursos
Una de las realidades más difíciles en el ecosistema SAP es la escasez de talento especializado en QA. Los tester de SAP no son abundantes, y la industria enfrenta dificultades para conseguir este perfil.
La solución pragmática es la reconversión:
• Buscar consultores SAP especialistas en módulos específicos (como HCM o perfiles) que conozcan el negocio, y luego enseñarles «cómo hacer casos de prueba».
• El conocimiento del negocio es la base: «es preferible que lo haga el que el que sabe cómo funciona su proceso».
2. La Importancia de las habilidades blandas
Dada la alta interacción requerida, la colaboración y las «habilidades blandas» se volvieron un factor crítico para el éxito. Marcela León relató la necesidad de «fidelizar al negocio,» actuando con el tester «al lado del usuario» para entender el proceso y transmitir la importancia de su trabajo: «¿Qué te pasaría si una orden de compras [falla]?». Esta presión psicológica y el trabajo de convencimiento son parte del delivery de QA.
IV. Estrategias de pruebas y uso de herramientas
La estrategia de prueba debe ser Ad Hoc a la magnitud y los recursos disponibles.
1. Planificación anticipada y criterios de automatización
Los proyectos SAP exigen que la automatización se planifique «desde antes de tener el proyecto» o en las «fases iniciales». La decisión clave sobre cuándo automatizar se basa en que los procesos sean «críticos, repetitivos y estables» y, fundamentalmente, cuando se tenga «tiempo suficiente».
2. Herramientas y ejecución
Para manejar el volumen masivo de pruebas, la gestión de pruebas es crucial:
• Solman (Solution Manager): Fue utilizado en una migración anterior para la simulación de pruebas en un ambiente de QA.
• Xray/Jira: Aunque no se especificó su uso en el panel para SAP, las herramientas de gestión de pruebas son vitales para vincular la ejecución a los requerimientos, proporcionando trazabilidad y cobertura. COPEC buscaba que sus casos de prueba estuvieran en un estándar que les permitiera «gobernar tantos casos de prueba en la ejecución».
• Automatización: La automatización es vista como un objetivo maduro para reducir los tiempos de ejecución manual. Sin embargo, la automatización en SAP, especialmente para la interfaz de escritorio (SAP GUI), es «muy rígido» y requiere herramientas probadas y validadas por SAP, como las de Tricentis (Tosca).
V. El desafío humano: gestión del cambio y resistencia
En un proyecto de transformación, la resistencia al cambio por parte del usuario final es una realidad. Las estrategias para mitigarla fueron:
1. Soporte estratégico de la alta gerencia: Los proyectos SAP se declaran «estratégicos de la compañía,» lo que moviliza a la alta gerencia e involucra a gerentes de todas las áreas. En el caso de SMU, se le asignó un «porcentaje de dedicación» a los usuarios clave para las pruebas, lo cual era esencial dado el pequeño plazo.
2. Equipo de gestión del cambio (GDC): El GDC fue «clave», responsable de la comunicación, la consolidación de requerimientos, y el apoyo a las capacitaciones, actuando como un «refuerzo humano».
3. Involucramiento constante: COPEC exigía la dedicación «100%» de las células de negocio y aseguraba que el usuario que definía los escenarios es el mismo que después los ejecutaría.
VI. Beneficios y lecciones futuras
Los beneficios concretos de una migración limpia son significativos y se traducen en valor de negocio:
• Capacidad de integración (SMU): Rosa Quiroz destacó que, tras la migración, pueden «conectar muchas otras plataformas» que antes eran inviables por el RP antiguo. El proyecto fue tan «limpio» que no identificó puntos clave de mejora en el ERP actual.
• Nuevas capacidades (general): La migración a S/4HANA permite implementar nuevas soluciones (como Success Factors) e incluso que reportes que antes eran «Zetas» (customizados) ahora se «sacaban solos,» eliminando la necesidad de desarrollos previos.
• Activo de procesos (COPEC): COPEC aspiraba a entregar un «activo super importante» a la compañía: un banco de procesos y casos de prueba que sirva como punto de partida para futuros desarrollos y gestión de incidencias.
Las lecciones aprendidas para futuros proyectos se centran en la preparación y el compromiso:
• Tiempo y equipo: Se debe destinar suficiente tiempo y recursos, evitando que las personas trabajen con las «mismas manos» en el proyecto y en el día a día.
• Conocimiento y Shift Left: Es vital que el equipo llegue preparado, sabiendo de la metodología Activate y de los módulos a implementar. Además, se debe hablar de testing y planificarse desde antes de la ejecución.
• Consenso: Es fundamental «consensuar y analizar el requisito» en la etapa inicial de la iniciativa, incluso cuando no está claro si el proyecto prosperará. Un proyecto no puede avanzar si no hay un «dolor» que cubrir, y la educación del cliente sobre cómo solicitar y refinar los requerimientos es el inicio de todo
La charla inicia en el track 2:20:50 y finaliza en 3:2:06
