El quality gate que se firma sin evidencia: qué artefacto exigir
En la conversión a S/4HANA, un gate aprobado sin artefacto no prueba nada. Qué evidencia exigir en cada fase de SAP Activate para que la firma valga.
· 12 min de lectura
El semáforo verde que no prueba nada
Hay un momento reconocible en toda conversión a SAP S/4HANA de una distribuidora eléctrica: el comité de proyecto se reúne para cerrar una fase, alguien proyecta un tablero con semáforos, todos están en verde, se firma el acta y la siguiente fase arranca el lunes. Nadie mintió. Y aun así, nadie puede decir con qué evidencia se pintó ese verde.
El problema no es que falte el marco. SAP Activate lo trae. En la metodología, al final de la fase Realize, para pasar el quality gate e iniciar Deploy se verifica que todas las configuraciones estén finalizadas, probadas y aprobadas en un documento firmado por el cliente (SAP Community, 2024). Es una exigencia explícita. El problema es que, en la práctica, la firma se convierte en el entregable — y el artefacto que debía sustentarla nunca se pidió.
En la pieza anterior de esta serie planteamos que clean core no es una fase del proyecto sino un eje que cruza las seis. Esta pieza baja ese eje a lo concreto: qué documento, extracto o reporte generado por una herramienta debería estar sobre la mesa antes de que alguien levante la mano en cada gate.
El marco ya existe y es más exigente de lo que se usa
Cada fase de SAP Activate tiene un objetivo, entregables definidos y un quality gate que debe superarse antes de iniciar la siguiente; ese punto es donde la gobernanza justifica su costo o donde falla en silencio cuando los equipos la tratan como formalidad (Henka Digital). La metodología define cuatro quality gates obligatorios sobre las fases Prepare, Explore, Realize y Deploy (SAP Community, 2025).
Y no son casillas genéricas: los checklists de quality gate contienen preguntas específicas de la solución, diseñadas para mitigar riesgos, y no deberían ignorarse (SAP Community, 2024). En SAP Cloud ALM, el Quality Gate Checklist ya está disponible dentro del sistema: se responden las preguntas, se rastrea el estado de cada ítem, se agregan comentarios y se etiqueta al responsable, sin descargar un archivo Excel (SAP Community, 2026).
Es decir: el instrumento existe, está trazado y tiene dueño asignable. Lo que falla es el estándar de prueba.
Qué convierte una respuesta en artefacto
Un artefacto de gate no es una afirmación en una minuta. Es un objeto verificable, y en nuestra práctica SAP lo evaluamos contra cuatro condiciones:
Si la respuesta a “¿está limpio el core?” no cumple las cuatro, el gate no está aprobando nada: está registrando una intención.
Qué debería exigir cada gate en una conversión IS-U
La lente aquí es concreta: el ERP que sostiene lectura, facturación, recaudación y gestión de reclamos de una distribuidora. Cada gate tiene un artefacto natural.
Prepare: datos de uso, no inventario de objetos
El inventario de Z code dice qué existe. No dice qué se ejecuta. En un sistema SAP ECC promedio, una parte grande del código propio nunca se ejecuta en productivo, y removerlo reduce significativamente el esfuerzo de adaptación (SAP Community, 2026); estimaciones de SAP ubican ese código no ejecutado entre el 40% y el 60% del total (SAP Community, 2026). La recomendación de SAP es recolectar datos de uso en los sistemas productivos con ABAP Call Monitor (SCMON) y la transacción SUSG al menos un año antes del proyecto de conversión (SAP Community, 2026).
El artefacto del gate Prepare es ese extracto, con su ventana de captura declarada. Y en una utility esa ventana importa más que en cualquier otra industria: si no cubre un ciclo completo de facturación, incluyendo cierre, corte y reconexión, los programas estacionales aparecerán como muertos y se decomisionará algo que se ejecuta una vez al mes.
Explore: hallazgos ATC contra el release objetivo
La herramienta para los chequeos de S/4HANA es el ABAP Test Cockpit con análisis remoto de código, ejecutado desde un sistema central de verificación (SAP Community, 2026). El resultado se exporta desde ATC para SAP Readiness Check y se incorpora al análisis (SAP Community, 2026).
El artefacto no es “corrimos ATC”. Es el archivo de hallazgos con la variante de verificación del release objetivo declarada, más la lista de decisiones de alcance: durante el scoping, la app Custom Code Migration permite especificar los objetos que no se llevarán a la conversión y genera la orden de transporte correspondiente (SAP Community, 2026). Esa lista es el primer lugar donde la limpieza deja de ser un propósito y se vuelve un objeto transportable con dueño.
Realize: distribución de niveles, no solo la firma
Aquí es donde el documento firmado por el cliente necesita un anexo medible. El tablero de la metodología RISE with SAP en SAP Cloud ALM incorpora el concepto de Clean Core Levels, un modelo de madurez que clasifica las extensiones en cuatro niveles —A, B, C y D— según su integridad arquitectónica y su seguridad ante upgrades, alimentado por la importación de resultados de ATC (SAP Community, 2026).
Eso permite firmar algo verificable: no “el core quedó limpio”, sino la distribución de objetos por nivel y, para cada objeto del nivel más comprometido, una decisión explícita —remover, refactorizar, reemplazar o aceptar el riesgo con dueño y fecha de retiro.
Deploy: el artefacto de operación
El último gate no debería pedir más chequeos de código. Debería pedir el registro de excepciones vivas: qué desarrollos propios sobrevivieron, por qué, quién los mantiene y cuándo se revisan. Sin ese documento, la deuda técnica entra a productivo sin propietario y la próxima actualización la vuelve a descubrir desde cero.
Por qué el calendario regulatorio no espera al acta
En Colombia, la Resolución CREG 108 de 1997 fija los criterios generales de protección de los derechos de los usuarios en relación con la facturación y la comercialización de energía eléctrica y gas combustible (CREG, 1997). Y el artículo 158 de la Ley 142 de 1994 obliga a resolver peticiones, quejas y recursos dentro de quince días hábiles, bajo pena de configurarse el silencio administrativo positivo a favor del usuario (Ley 142 de 1994, art. 158).
Traducido al proyecto: un gate aprobado sin evidencia no elimina el riesgo, lo traslada. Lo traslada al proceso regulado, donde un Z code que rompe la facturación después del go-live no se paga en horas de consultoría sino en reclamos con reloj legal corriendo. En EvoTech Consulting insistimos en que el estándar de prueba del gate se defina antes de que la fase empiece, no cuando ya hay presión de cronograma.
Del gate a la siguiente pregunta
Exigir el artefacto correcto en cada gate convierte la gobernanza en algo que se puede auditar. Pero deja abierta una decisión anterior y más incómoda, que abordamos en la siguiente pieza de esta serie: si conviene limpiar el ERP de origen una sola vez antes de convertir, o asumir que habrá que volver a limpiarlo en cada ciclo.
Fuentes
- SAP Community — SAP Activate Realize and Deploy phase activities in the context of Scaled Agile Framework (2024)
- SAP Community — Quality gates with Activate methodology and RISE with ALM (2025)
- SAP Community — SAP Ariba Roadmap: Quality Gates Checklist in SAP Cloud ALM (2026)
- SAP Community — Get started with the ABAP custom code migration process (2026)
- SAP Community — SCMON Setup and Execution Guide (2026); ABAP Call Monitor (SCMON): Analyze usage of your code (publicación original 2016)
- SAP Community — SAP S/4HANA System Conversion: Custom code adaptation process (2026)
- SAP Community — New Clean Core Extensibility KPIs arrive on the RISE with SAP Dashboard (2026)
- Henka Digital — SAP Activate Reference Sheet
- CREG — Resolución CREG 108 de 1997
- Congreso de Colombia — Ley 142 de 1994, artículo 158
¿Este análisis mapea un mercado donde ya operas o estás evaluando entrar?
Revisamos tu caso específico, mapeamos los riesgos que aplican, y te decimos honestamente si es oportunidad para ti —sin pitch comercial, solo discusión técnica y estratégica.
