DevOps antes del proyecto: gobernar la fase de planificación en implementaciones SAP S/4HANA

Esta guía está dirigida a líderes de proyecto, arquitectos y responsables de TI de utilities, oil & gas y empresas de tecnología en América Latina que están por iniciar —o están replanificando— una implementación de SAP S/4HANA bajo el modelo RISE with SAP / SAP Cloud ERP Private. Su objetivo es mostrar cómo la disciplina DevOps, aplicada desde la fase de planificación y no como un ajuste posterior, determina si el proyecto sostiene su costo total de propiedad (TCO) en el tiempo o si empieza a inflarlo desde antes del primer sprint.

Fundamento conceptual

DevOps se entiende, en su definición más operativa para organizaciones de TI, como un conjunto de prácticas donde los equipos de desarrollo y operaciones se integran junto con control de calidad y otras áreas, de modo que todos —sin importar su rol— trabajan juntos para idear, desarrollar, probar, liberar y operar un sistema, en lugar de hacerlo en silos separados (AWS, “What is DevOps?”). Esta integración de equipos, cuando se establece antes de iniciar el desarrollo, es lo que permite tomar decisiones de planificación con visibilidad compartida entre quienes construyen y quienes van a operar el sistema después del go-live.

La fase de planificación de DevOps para una implementación en SAP S/4HANA es crítica para el éxito del proyecto. Incluye definir objetivos y alcance con criterio SMART (específico, medible, alcanzable, relevante y acotado en el tiempo), analizar requisitos junto a los stakeholders, planear el proceso de desarrollo bajo una metodología ágil con sprints y revisiones regulares, definir el entorno de desarrollo, identificar los requisitos de testing —unitario, de integración y de aceptación de usuario— y definir de antemano el proceso de despliegue, incluyendo aprobaciones, control de cambios y el rol del Change and Transport System (CTS/CTS+), así como la estrategia de monitoreo y mantenimiento posterior al go-live (buenas prácticas de planificación ágil de proyectos SAP).

Este enfoque de planificación no ocurre en el vacío: se apoya en un portafolio de herramientas que SAP ofrece nativamente para S/4HANA. abapGit provee control de versiones de objetos ABAP vía Git, integrado con el editor ABAP y con el CTS clásico. SAP Cloud ALM se presenta como una herramienta de gestión del ciclo de vida de aplicaciones que cubre desde el levantamiento de requisitos hasta el despliegue y la operación, con funciones de gestión de proyecto, aseguramiento de calidad, testing y gestión de despliegues. El CTS clásico se extiende mediante CTS+ para sistemas no-ABAP, y gCTS permite gestionar transportes ABAP usando Git como sistema de control de versiones externo, disponible desde SAP S/4HANA 1909. SAP Solution Manager, por su parte, se ofrece como plataforma central para gestionar todo el ciclo de vida de las soluciones SAP, desde la implementación hasta la operación (SAP Help Portal, Git-Enabled Change and Transport System). De hecho, gCTS ya es hoy el único mecanismo de transporte disponible para SAP BTP ABAP Environment en su edición pública (conocida como Steampunk), lo que confirma que dejó de ser una opción marginal para convertirse en el estándar de facto en paisajes cloud [3].

Para paisajes construidos sobre SAP BTP, la fase de planificación se apoya en el SAP BTP cockpit y su interfaz de línea de comandos para configurar el landscape, en guías de mejores prácticas disponibles en help.sap.com y en el SAP Discovery Center para acceder a misiones de ejemplo. Para configurar un pipeline de CI/CD desde esta misma fase, SAP ofrece tres caminos con distintos niveles de control: SAP Continuous Integration and Delivery, orientado a casos de uso SAP-céntricos con baja curva de aprendizaje; Project “Piper”, con plantillas de pipeline predefinidas y mayor flexibilidad; y una guía de mejores prácticas de CI/CD para equipos que quieren construir y controlar su propio pipeline por completo (SAP Help Portal, SAP Continuous Integration and Delivery / Project “Piper”).

SAP Cloud ALM merece un párrafo aparte porque se presenta como una plataforma única que unifica gestión de proyectos, gestión de requisitos, aseguramiento de calidad y gestión de cumplimiento normativo desde el arranque del proyecto. Su enfoque de implementación basado en contenido, alineado con SAP Activate y las mejores prácticas de SAP, busca acortar el tiempo de valor, mientras que el enfoque orientado a requisitos permite adaptar la solución a necesidades específicas de cada organización sin actividades adicionales de despliegue o configuración, lo que reduce tiempo y costo de implementación desde la fase de planificación (SAP Help Portal, SAP Cloud ALM). En la práctica actual, SAP Cloud ALM se entrega como solución SaaS sin licencia separada: los clientes con suscripciones que incluyen Enterprise Support tienen derecho a un tenant por número de cliente sin costo adicional, lo que reduce la barrera de entrada para adoptarlo desde el día uno del proyecto [1].

Finalmente, el principio de “fail fast” en DevOps promueve la experimentación y prueba rápida y frecuente del software, con el objetivo de detectar y corregir errores lo antes posible en el ciclo de vida, idealmente desde las fases tempranas de planificación y diseño, en línea con el concepto de “shift left” —mover el testing y la validación lo más temprano posible—. Entre las prácticas recomendadas para habilitar esto desde el diseño del proyecto están: implementar prácticas de CI/CD, fomentar una cultura de experimentación segura, invertir en testing automatizado desde el inicio y usar metodologías ágiles con tableros que permitan visibilizar cuellos de botella tempranamente (prácticas estándar de “shift left” en ingeniería de software).

Aplicación práctica

En utilities y oil & gas de América Latina, la fase de planificación de DevOps enfrenta una tensión particular: los paisajes rara vez son limpios. Es común encontrar un núcleo ECC o S/4HANA on-premise conviviendo con extensiones cloud sobre SAP BTP, integraciones con sistemas de medición (AMI), facturación (IS-U) y reportes regulatorios de tarifas o regalías. Definir en la fase de planificación si un flujo de cambios se gestiona con CTS clásico, con CTS+ para componentes no-ABAP, o con gCTS para desarrollo versionado en Git, no es un detalle técnico menor: es una decisión de gobierno que condiciona cuánto esfuerzo manual —y cuánto riesgo de inconsistencia— va a acumular el proyecto en cada ciclo de transporte durante meses o años.

La recomendación de SAP Activate de “standard-first” —cuestionar cada requisito de personalización antes de aceptarlo como alcance— es especialmente relevante en mercados LATAM donde la presión por adaptar el sistema a procesos locales de facturación, cumplimiento fiscal o gestión de pérdidas no técnicas es alta. La experiencia documentada muestra que el mayor riesgo en las fases tempranas de un proyecto Activate no es omitir un requisito, sino aceptar demasiados requisitos de personalización sin desafiarlos lo suficiente: cada brecha aprobada sin justificación rigurosa se convierte en alcance en la fase de construcción, en testing en el despliegue, y en carga de mantenimiento en la operación [2]. Esto conecta directamente con el argumento de costos ocultos en contratos RISE / SAP Cloud ERP Private: una planificación DevOps débil no solo genera fricción técnica, sino que es una de las vías por las que el TCO se infla antes de que el proyecto llegue a producción.

Con presupuestos acotados, definir en la fase de planificación quién es dueño de la estrategia de testing automatizado también es crítico, porque SAP Cloud ALM ofrece orquestación de pruebas —vinculando procesos, requisitos y casos de prueba en una cadena trazable— pero no incluye un motor de automatización propio; depende de integrarse con herramientas externas como Tricentis Test Automation, que SAP ofrece sin costo adicional a clientes con Enterprise Support, aunque con alcance limitado a aplicaciones web (Fiori, Ariba, SuccessFactors) [4]. Dejar esta decisión para la fase de construcción, en lugar de resolverla durante la planificación, es un anti-patrón frecuente que después se traduce en retrabajo o en cobertura de pruebas insuficiente antes del go-live.

Mejores prácticas y consideraciones

• Definir el mecanismo de transporte antes del primer sprint. Elegir entre CTS clásico, CTS+ y gCTS no es una decisión que deba quedar abierta durante la construcción; condiciona la trazabilidad de cambios durante toda la vida del proyecto y, en paisajes híbridos típicos de utilities LATAM, define cuánto esfuerzo manual absorbe cada ciclo de despliegue.
• Tratar SAP Cloud ALM como columna vertebral de gobierno, no solo como herramienta de testing. Su capacidad de unificar gestión de proyecto, requisitos, calidad y compliance desde el inicio reduce la necesidad de reconciliar herramientas distintas más adelante, algo especialmente valioso cuando el equipo de gobierno regulatorio y el equipo técnico no comparten el mismo lenguaje.
• Aplicar el principio “standard-first” con disciplina real, no como formalidad. Cada requisito de personalización que se aprueba sin justificación rigurosa en la planificación se convierte en deuda técnica silenciosa que aparece después como sobrecosto de mantenimiento.
• Resolver la estrategia de automatización de pruebas en la planificación, no en el camino. Dado que SAP Cloud ALM orquesta pero no ejecuta pruebas automatizadas por sí solo, definir qué herramienta de automatización se integrará —y su alcance real— evita descubrir limitaciones de cobertura recién antes del go-live.
• Anti-patrón a evitar: planificar el “qué” del proyecto (alcance funcional) sin planificar en paralelo el “cómo” del gobierno técnico (transporte, testing, compliance). Cuando la planificación DevOps se trata como un checklist administrativo y no como una decisión de arquitectura, el costo de esa omisión no aparece en el contrato inicial: aparece meses después, en operación.

Referencias

1. SAP Cloud ALM — SAP Help Portal / Support — https://support.sap.com/en/alm/sap-cloud-alm.html
2. SAP Activate: A Practitioner’s Reference — henkadigital — https://www.henkadigital.com/methodologies/sap-activate-reference-sheet
3. SAP gCTS Explained — Git, ABAP and DevOps Finally Together — SAP Community — https://community.sap.com/t5/technology-blog-posts-by-sap/sap-gcts-explained-git-abap-and-devops-finally-together/ba-p/14418355
4. Usage Rights — SAP Cloud ALM / Tricentis Test Automation — SAP Support Portal — https://support.sap.com/en/alm/usage-rights.html