Conversión a S/4HANA: el lenguaje correcto para el directorio

Una sola palabra decidió el destino de este proyecto, y se pronunció mucho antes de que alguien tocara un sistema: “upgrade”. Con ella el programa entró al comité de inversiones, con ella se aprobó, y con ella quedó fijada una expectativa que el equipo va a tener que desmentir a pedazos durante los próximos dos años. Esta pieza no trata de rutas de transición ni de arquitectura: trata del vocabulario con el que un director de TI se sienta frente a su directorio y corrige la definición de un programa que ya está en marcha.

El equipo técnico casi siempre sabe qué hay que hacer. Lo que suele faltar es el lenguaje para que el comité entienda por qué lo que viene no cabe en la palabra con la que lo aprobó. Y ese lenguaje tiene reglas: qué se dice primero, quién lo dice, con qué evidencia se sostiene y qué se le pide exactamente a la mesa al final de la sesión.

Lo que un comité aprueba cuando aprueba un “upgrade”

Cuando un directorio escucha “actualización de plataforma”, aprueba mentalmente tres cosas que nadie escribió en el acta: ventana de indisponibilidad corta, alcance contenido dentro de TI y continuidad de los procesos exactamente como existen hoy. Nadie mintió al usar la palabra. Se eligió el término que pasaba más rápido por el comité de inversiones, y funcionó.

El costo aparece después. Cuando el equipo pide presupuesto para trabajo que la palabra “upgrade” nunca contempló, el directorio no escucha “avance del proyecto”: escucha “sobrecosto imprevisto”. Desde ese marco, cada solicitud legítima se lee como una falla de estimación, y el patrocinio se erosiona justo cuando más se necesita.

Ese error de encuadre tiene consecuencias documentadas más allá del presupuesto. La experiencia recogida por EY en programas de SAP S/4HANA identifica la concepción del programa como un proyecto puramente técnico como una de las dinámicas que retrasan la participación real del negocio, y sitúa la alineación de procesos punta a punta, la decisión interfuncional y el gobierno conducido por el negocio como los factores más críticos; el liderazgo empoderado es lo que evita que cada definición termine escalada a la alta dirección (EY, 2025). Es decir: la palabra no solo fija expectativas de costo, fija quién decide.

Reencuadrar, entonces, no es admitir un error de planificación. Es corregir el vocabulario para que las decisiones que vienen se tomen en la mesa correcta.

Cuatro reformulaciones que cambian la conversación

El vocabulario importa porque determina qué comité es competente para decidir.

• De “actualizar la versión” a “convertir el sistema”: la conversión es un procedimiento con precondiciones obligatorias, no un salto de release.
• De “sobrecosto” a “alcance que siempre estuvo ahí”: el trabajo de remediación y depuración no se agregó al proyecto; se hizo visible.
• De “proyecto de TI” a “programa de negocio con ejecución técnica”: si el resultado afecta el ciclo de medición a cobro, el dueño no puede ser exclusivamente el CIO.
• De “riesgo técnico” a “riesgo de continuidad comercial”: en una distribuidora, un error de conversión no se manifiesta como caída de servidor, sino como facturación observada por el regulador y por el cliente.

Esa última traducción es la que mueve al directorio en América Latina, donde la exposición regulatoria y la recaudación son el eje de la conversación ejecutiva. Las tres primeras cambian el presupuesto; la cuarta cambia el patrocinio.

Cómo se conduce la sesión de reencuadre

La sesión no se improvisa ni se mezcla con el reporte de avance mensual. Es una reunión propia, con un solo objetivo: cambiar la definición del proyecto antes de la siguiente decisión de inversión.

El orden no es decorativo. Si se presenta la evidencia antes de reconocer la definición vigente, el directorio percibe que se le está corrigiendo. Si se piden fondos antes de traducir el riesgo a lenguaje de negocio, la petición compite con cualquier otra inversión sin contexto.

La evidencia que se lleva a la sesión

El reencuadre funciona cuando no depende de la credibilidad del área de TI, sino de hechos que un director puede contrastar por su cuenta. Tres bastan, y ninguno es una opinión de consultor.

El calendario del proveedor. SAP definió mantenimiento mainstream para las aplicaciones centrales de SAP Business Suite 7 hasta el 31 de diciembre de 2027, seguido de mantenimiento extendido opcional hasta el 31 de diciembre de 2030, y un compromiso de innovación para SAP S/4HANA hasta el final de 2040 (SAP Support Portal, 2020). El mantenimiento extendido no es gratuito: se ha reportado como un recargo de dos puntos porcentuales sobre la base de mantenimiento existente (E3 Magazine, 2025). La pregunta estratégica no es si ECC sigue funcionando hoy, sino si permanecer en él más allá de 2027, o depender del mantenimiento extendido hasta 2030, se alinea con los objetivos de riesgo, costo y modelo operativo de largo plazo (SM-C, 2025). A ese cuadro se sumó después la opción SAP ERP, private edition, transition option, que extiende el soporte hasta 2033 para un conjunto acotado de clientes con paisajes complejos que se comprometen con RISE with SAP, con prerrequisitos ya publicados por SAP —entre ellos migrar los sistemas a SAP ERP, private edition sobre SAP HANA antes de fin de 2030 y combinar la suscripción con el max success plan— y un precio con recargo respecto de la suscripción vigente a fin de 2030 (SAP News, 2025). Es una excepción negociada, no una prórroga general: el directorio debe saber que existe y también que no es el escenario base.

El cambio obligatorio de modelo de datos. La conversión a SAP S/4HANA exige convertir clientes y proveedores al objeto Business Partner mediante Customer/Vendor Integration como paso previo obligatorio; en el caso de SAP IS-U el procedimiento es específico y utiliza reportes propios como REU_CVI_CUST_LINK y REU_CVI_EKUN_TO_BUTOID, documentados en la nota SAP 2344100 (SAP Community, 2025). Eso no es una tarea de infraestructura: es depuración de datos comerciales, con dueños de negocio, no de TI.

La naturaleza del código propio. El análisis de código personalizado de SAP Readiness Check identifica áreas de cambio obligatorio derivadas de la arquitectura simplificada de la versión destino, y clasifica hallazgos que requieren rediseño funcional con participación de un experto de aplicación, no una corrección mecánica (SAP Community, 2023). En un IS-U con veinte años de desarrollos sobre facturación, cortes y reconexiones, esa categoría concentra el riesgo.

Presentados así, los tres mueven la conversación de “¿le creo a mi CIO?” a “¿qué decidimos frente a esto?”.

Qué decisión se le pide al directorio

El error frecuente es cerrar la sesión pidiendo aprobación de presupuesto. Lo que corresponde pedir es una redefinición de alcance y de gobierno: quién patrocina, qué áreas de negocio aportan personas dedicadas, y bajo qué criterio se aceptará que un requerimiento no se replique tal cual en el destino.

Ese último punto es el que más resistencia genera y el que más ahorra. SAP Activate organiza el trabajo en seis fases —Discover, Prepare, Explore, Realize, Deploy y Run— y sitúa los talleres de fit-to-standard en la fase Explore, donde se confirma el diseño de la solución (SAP, s.f.). Si el directorio no entendió que habrá decisiones de proceso, esos talleres se convierten en sesiones de levantamiento de requerimientos para desarrollo a medida, y el programa reproduce en S/4HANA la deuda que venía a resolver. El mandato ejecutivo para decir que no es, en la práctica, el entregable más valioso de la sesión.

También conviene poner sobre la mesa un elemento comercial que suele ignorarse: en escenarios de conversión, SAP contempla derecho de uso dual sobre Business Suite 7 y SAP S/4HANA hasta completar la transición (SAP Support Portal, s.f.). Es un dato que reduce la ansiedad ejecutiva sobre el período de coexistencia y ayuda a discutir plazos con menos presión artificial.

Un directorio bien informado rara vez rechaza un reset arquitectónico. Lo que rechaza es enterarse tarde. En AGT acompañamos a utilities y operadoras de la región a construir ese lenguaje común entre el equipo técnico y el comité ejecutivo, con evidencia del producto y no con estimaciones sin respaldo. La conversación difícil se paga una vez; la expectativa mal fijada se paga en cada comité que viene.

Fuentes

• SAP Support Portal (2020). Maintenance strategy: SAP S/4HANA and SAP Business Suite 7.
• SAP Support Portal (s.f.). SAP Maintenance Strategy for Business Suite 7 and SAP S/4HANA (resumen de compromisos de mantenimiento).
• SM-C (2025). SAP ECC End of Mainstream Maintenance 2027: What Enterprise Organisations Should Be Planning Now.
• E3 Magazine (2025). Deadline Extension for ECC 6.0.
• SAP News (2025). Navigating Your RISE with SAP Journey: Updates for SAP ERP, Private Edition, Transition Option.
• SAP Community (2025). Customer & Vendor Integration (CVI).
• SAP Community (2023). Enhanced Custom Code Analysis in SAP Readiness Check for SAP S/4HANA Upgrades.
• SAP (s.f.). SAP Activate Methodology.
• EY (2025). Maximize value in SAP S/4HANA transformations.