Fase Run: el eje de limpieza que no termina con el go-live

El comité de dirección declara el go-live exitoso, la oficina de proyecto se disuelve y el equipo vuelve a sus áreas. En ese instante, en buena parte de las conversiones a SAP S/4HANA, el eje de limpieza del código propio se queda sin dueño. Nadie lo cancela: simplemente estaba inscrito en un cronograma que acaba de cerrarse.

La discusión previa era dónde limpiar y cuántas veces. Esta es otra: qué sobrevive al cierre del proyecto. Porque el core no se ensucia el día de la conversión. Se ensucia después, transporte a transporte, absorción a absorción, mientras la operación de lectura, facturación, recaudación y gestión de reclamos sigue corriendo sin pausa.

Run no es soporte: es una fase con metodología propia

En SAP Activate, Run es la fase posterior al go-live, y no equivale al escritorio de atención de incidentes. SAP la describe como una fase que tiene metodología propia y que agrupa estándares de operación que van desde la gestión de incidentes y cambios hasta el monitoreo de sistemas y aplicaciones y la gestión de upgrades (SAP Learning, 2024). Materiales de la comunidad de implementadores lo formulan en los mismos términos: Run incluye preparar los sistemas y a los usuarios para absorber las innovaciones y upgrades del ciclo de releases, y establecer un modelo de gobierno de releases que permita innovar sin interrumpir la operación (Consulting Solutions, 2025).

La diferencia con soporte es de naturaleza, no de intensidad. El soporte reacciona a lo que se rompió. Run administra lo que va a cambiar: qué entra al core, cuándo entra y bajo qué criterio se acepta. El eje de limpieza pertenece a esta segunda categoría. No termina; cambia de forma.

El transporte deja de ser trámite y se vuelve punto de control

---
config:
  theme: base
  fontFamily: 'Inter Variable, system-ui, sans-serif'
  themeVariables:
    darkMode: true
    fontFamily: 'Inter Variable, system-ui, sans-serif'
    fontSize: '15px'
    background: '#111113'
    primaryColor: '#1A1A1D'
    primaryTextColor: '#F4F5F8'
    primaryBorderColor: '#B89C5C'
    secondaryColor: '#242428'
    tertiaryColor: '#1A1A1D'
    mainBkg: '#1A1A1D'
    secondBkg: '#242428'
    tertiaryBkg: '#2E2E33'
    lineColor: '#B89C5C'
    textColor: '#F4F5F8'
    titleColor: '#F4F5F8'
    nodeBorder: '#B89C5C'
    clusterBkg: '#1A1A1D'
    clusterBorder: '#2E2E33'
    edgeLabelBackground: '#242428'
    pie1: '#B89C5C'
    pie2: '#f59e0b'
    pie3: '#22c55e'
    pie4: '#d1bf95'
    pie5: '#f97316'
    pie6: '#ef4444'
    pieTitleTextColor: '#F4F5F8'
    pieSectionTextColor: '#F4F5F8'
    pieLegendTextColor: '#F4F5F8'
    pieStrokeColor: '#111113'
    pieOuterStrokeColor: '#111113'
---
flowchart TD
  A([Un desarrollador libera una tarea u orden]) --> B[Chequeo contra el ATC central]
  B --> C{¿Prioridad del hallazgo?}
  C -->|P1 y P2| D[Bloqueo de la liberación]
  D --> E[Corrección o exención formal]
  E --> F([Transporte hacia QA y producción])
  C -->|P3| G([Notificación del hallazgo])
  class A inicio
  class C decision
  class B,D,E proceso
  class F bueno
  class G neutro
classDef inicio fill:#3a352b,stroke:#B89C5C,color:#ffffff
classDef decision fill:#473519,stroke:#f59e0b,color:#ffffff
classDef proceso fill:#33363c,stroke:#9aa0aa,color:#ffffff
classDef bueno fill:#193e2b,stroke:#22c55e,color:#ffffff
classDef neutro fill:#33363c,stroke:#9aa0aa,color:#ffffff

El cambio concreto es este: durante el proyecto, la calidad del código propio se controlaba con hitos y revisiones de arquitectura. En Run, el punto de control se traslada al momento en que un desarrollador libera una tarea o una orden de transporte.

SAP recomienda montar un sistema ATC central conectado contra todos los sistemas relacionados con desarrollo —DEV y Q— y activar el modo de bloqueo en los sistemas DEV para todos los hallazgos de Prioridad 1 y Prioridad 2 en tareas y órdenes de transporte (SAP Community, 2025). En el entorno ABAP de SAP BTP el comportamiento es equivalente y automático: la liberación de transportes y tareas que contienen hallazgos de Prioridad 1 y 2 se bloquea, mientras que los de Prioridad 3 generan notificación (SAP Community, 2025).

El mecanismo tiene dos válvulas que evitan que se vuelva impracticable el primer día. La línea base permite exentar los hallazgos iniciales sobre objetos heredados, de modo que los desarrolladores no queden bloqueados por deuda preexistente mientras los desarrollos nuevos sí quedan controlados desde el comienzo (SAP Community, 2025). Y las exenciones se gestionan con un flujo de aprobación y un visor que permite observar su estado agregado (SAP Community, 2025). Ese visor es, en la práctica, el tablero del eje de limpieza en Run: no mide cuánto código Z existe, mide cuánta excepción se está acumulando y quién la autorizó.

Absorber releases sin volver a ensuciar el core

La segunda mitad de Run es la absorción del ciclo de releases. Desde la versión 2023, SAP S/4HANA opera con un ciclo de releases de dos años, siete años de mantenimiento mainstream por release y feature packs previstos cada seis meses durante los dos primeros años de cada release (SAP News, 2022).

Para una distribuidora eléctrica eso significa que el meter-to-cash se enfrenta a una decisión de compatibilidad varias veces por año, no una vez por proyecto. Cada absorción reabre la misma pregunta sobre las modificaciones, las ampliaciones y las interfaces que sostienen la lectura, el cálculo y la emisión. Si el control de calidad corre en la liberación del transporte, la mayor parte de esa deuda nunca llega a existir. Si no corre, cada absorción se convierte en un miniproyecto de remediación que compite por el mismo presupuesto y el mismo calendario que la operación.

El eje de limpieza necesita un dueño distinto en Run

Durante el proyecto el dueño era el gerente de proyecto. En Run no puede serlo, porque el proyecto ya no existe. El dueño pasa a ser un rol operativo permanente con tres atribuciones concretas:

• Administrar la configuración del ATC central y la variante de verificación vigente, incluyendo cuándo se endurece.
• Aprobar o rechazar exenciones con fecha de vencimiento explícita, de modo que una excepción no se transforme en permiso indefinido.
• Reportar al comité de TI el saldo de exenciones abiertas antes de cada absorción de release, no después.

Nada de esto exige una estructura nueva. Exige que alguien cuya evaluación de desempeño no dependa de cerrar un cronograma sea quien decida qué se libera.

Qué mirar en una distribuidora eléctrica de LATAM

El contexto regional aprieta el mecanismo por dos lados. Por el lado regulatorio, los prestadores de servicios públicos domiciliarios están sujetos a obligaciones de reporte de información al ente de vigilancia —en Colombia, la inscripción en el RUPS y el reporte al Sistema Único de Información son obligaciones de los prestadores vigilados conforme al artículo 79 de la Ley 142 de 1994 (SSPD, Concepto 266 de 2025)—, lo que en la práctica tiende a estrechar las ventanas de cambio alrededor de los cierres. Por el lado presupuestal, la conversión ya consumió el capital político y financiero disponible: el eje de limpieza en Run compite con la operación, y pierde si no está automatizado.

De ahí que la recomendación práctica sea invertir el orden habitual. No se trata de asignar horas de limpieza en el presupuesto de Run: se trata de que la limpieza sea la condición para liberar un transporte, y que las horas se gasten solo cuando alguien decide saltarse esa condición. El proyecto cerró. El mecanismo, si quedó bien montado, sigue corriendo solo.

Fuentes

• SAP Community. ABAP test cockpit (ATC) recommendations for governance of clean core ABAP development, 2025.
• SAP Community. Usage of ABAP Test Cockpit (ATC) for developments in SAP BTP ABAP Environment, 2025.
• Consulting Solutions. SAP Activate Blog Series, Post 6: Deploy & Run Phases – Go-Live & Beyond, 2025.
• SAP Learning. Describing the Methodology Structure — Discovering SAP Activate Implementation Tools and Methodology, 2024.
• SAP News. New SAP S/4HANA Release and Maintenance Strategy to Deliver Greater Innovation and Flexibility, 2022.
• Superintendencia de Servicios Públicos Domiciliarios (SSPD). Concepto 266 de 2025, sobre obligaciones de inscripción en el RUPS y reporte al SUI conforme a la Ley 142 de 1994, 2025.