Conversión a S/4HANA: el costo oculto está en las interfaces
En una conversión ECC→S/4HANA de utilities LATAM con IS-U customizado, las sorpresas de costo aparecen en las interfaces, no en la migración de datos.
· 12 min de lectura
Un comité aprueba la conversión ECC→S/4HANA con una lámina que dice “actualización de plataforma”. Doce semanas después el equipo no está atascado en la carga de datos maestros: está atascado en una interfaz de lecturas que hoy rechaza registros que ayer procesaba sin protestar. Ese desfase entre lo aprobado y lo ejecutado no es mala suerte. Es la consecuencia directa de un modelo mental equivocado.
La pieza anterior de esta serie describió qué cambia de raíz por debajo: modelo de datos simplificado, procesamiento in-memory y vistas CDS en lugar de tablas agregadas. Aquí interesa la consecuencia operativa de ese cambio. Cuando el modelo de datos se simplifica, cada interfaz que dependía de la forma anterior queda con un contrato tácito roto. Y esas roturas no esperan el go-live para manifestarse.
El modelo mental que subestima el perímetro
El modelo mental de “upgrade” asume tres continuidades: mismas tablas, mismos contratos de intercambio, motor nuevo. Las dos primeras no se sostienen.
Un ejemplo concreto y documentado: en S/4HANA el número de material admite 40 caracteres en lugar de 18, y las validaciones custom, los mapeos de interfaz y las rutinas de conversión construidas alrededor de la longitud anterior pueden truncar datos, corromper integraciones o fallar los chequeos del sistema (smartShift, 2026). Conviene precisar el alcance: la extensión del campo llega con el diccionario de S/4HANA, pero la funcionalidad de número de material extendido viene desactivada por defecto y, mientras no se active, la comunicación vía BAPI, IDoc, servicios web y RFC liberados sigue operando con normalidad (SAP Note 2215424); el impacto inmediato recae sobre el código y los mapeos custom que comparan o concatenan contra el campo estándar. Un solo cambio de longitud de campo, multiplicado por cada endpoint que lo toca.
El riesgo relevante no es el programa que deja de compilar; ese se detecta rápido. El riesgo es el código que corre y produce salidas que parecen correctas hasta que el problema emerge aguas abajo — en el cierre financiero, en el reporte regulatorio o en el ciclo de atención al cliente (smartShift, 2026). En una distribuidora eléctrica, “aguas abajo” significa facturación emitida.
Por qué la migración de datos no es donde duele
La migración de datos duele, pero duele de forma prevista. Tiene dueño único, checklist, ciclos de prueba repetibles y un criterio binario de éxito. El perímetro de integración es lo opuesto: está distribuido entre terceros, documentado de forma parcial y nadie lo posee completo.
SAP entrega herramienta propia para dimensionarlo. El análisis de integración de SAP Readiness Check identifica interfaces que podrían dejar de funcionar —o funcionar distinto— tras la conversión a S/4HANA o un upgrade entre versiones de S/4HANA; las interfaces impactadas pueden caer con error de sintaxis por acceso a un objeto ausente, o volverse inestables porque el objeto estándar referenciado ya no se mantiene en S/4HANA (SAP Community, 2023).
El dato que mejor ilustra el problema de gobierno viene de la propia experiencia de SAP con la versión previa de ese análisis: el conteo de interfaces IDoc resultó inesperadamente alto, llegando al millón y más, porque cada combinación IDoc-interlocutor se contaba por separado (SAP Community, 2023). El número exacto importa menos que la lección: la organización no sabe cuántas interfaces tiene hasta que las mide.
A esto se suma la evidencia de desvío de programa. Un estudio con 200 ejecutivos reporta que las transformaciones S/4HANA toman en promedio 30% más de lo planificado, que más del 60% de las empresas registra desviaciones de presupuesto, plazo y calidad, y que 65% reporta déficits de calidad fuertes o muy fuertes; entre las causas citadas están la expansión de alcance durante el proyecto y las fases de prueba subestimadas (Horváth, 2025). La muestra es europea y estadounidense, no LATAM: sirve como referencia de patrón, no como cifra regional.
El perímetro real en una utility LATAM con IS-U customizado
En una distribuidora o una operación de oil & gas de la región, el inventario de interfaces rara vez es corto. Y su punto más frágil suele ser la cadena de medición.
Medición y ciclo meter-to-cash
Los patrones que rompen el balance M2C son conocidos por cualquier equipo comercial: lecturas duplicadas que generan desbalance entre Comercial y Facturación; tiempos de transmisión inconsistentes que producen pérdida de secuencia en el middleware; eventos de medidor sin timestamp normalizado que rompen flujos aguas abajo; latencia alta en concentradores AMI que congestiona los flujos de integración. Ninguno de estos cuatro aparece en un plan de migración de datos. Los cuatro aparecen en integración.
Especificidad IS-U
IS-U ya opera sobre el modelo de Business Partner, por lo que la conversión CVI genérica no aplica igual que en un ECC estándar: la solución de industria tiene sus propios reportes y prechequeos de conversión, referenciados en la nota SAP 2344100 «S4TWL – CVI Integration for SAP IS-U», que define reportes propios distintos del cockpit estándar de sincronización (SAP Note 2344100). Además, toda aplicación externa que cree o actualice datos maestros de Business Partner debe invocar el módulo de función RFC correspondiente, no escribir directo contra tablas (SAP Learning, 2026). Cada punto de recaudación, cada gestor de cobranza y cada aplicación de terreno que hoy escribe “por atajo” es un ítem de alcance que nadie presupuestó.
El middleware amortigua, no elimina
La buena noticia es documentada por SAP: la experiencia muestra que las soluciones de middleware suelen facilitar la adaptación de una interfaz, e incluso volverla innecesaria, y el propio Readiness Check identifica cuántas interfaces están mediadas (SAP Community, 2023).
Eso convierte la arquitectura de integración en una palanca de costo, no en un gasto accesorio. Con SAP Integration Suite, Cloud Integration aporta mapeo y transformación para convertir la estructura origen a la estructura destino, API Management habilita acceso seguro y políticas de tráfico sobre los sistemas de registro, y la capacidad de Event Mesh permite publicar y consumir eventos de negocio desacoplando emisores y consumidores; para escenarios de mayor escala y gobierno del ciclo de vida del evento existe SAP Integration Suite, advanced event mesh (SAP, 2026). Desacoplar AMI del core IS-U mediante eventos, normalizar antes de entrar al core y sostener un buffer resiliente para colas de alto tráfico son decisiones que reducen la superficie de reescritura.
Cómo se gobierna el alcance de integración
Retirar el código que no se usa tiene respaldo cuantificado: típicamente hasta 50% del código custom heredado está obsoleto o sin uso, y con datos de uso productivo es posible retirar entre 25% y 40% de la huella antes de empezar a remediar; cargar ese código dormido infla ciclos de prueba y plazos (smartShift, 2026). También ayuda saber que más del 90% de los cambios requeridos son técnicos y que la fracción que exige rediseño funcional suele quedar por debajo del 10% (smartShift, 2026): el alcance es grande, pero es acotable con medición.
Qué cambia en la conversación con el directorio
El reloj es real: el mantenimiento estándar de ECC 6.0 EHP 6-8 termina el 31 de diciembre de 2027, con mantenimiento extendido opcional hasta fines de 2030 por un cargo adicional (All for One, 2025). Pero la fecha no es el argumento; el alcance sí.
En AGT acompañamos a operadores de la región a poner el inventario de interfaces sobre la mesa antes de comprometer un cronograma, porque un perímetro medido se negocia y un perímetro supuesto se paga. Reencuadrar el proyecto ante el comité no es admitir un error de estimación: es cambiar la unidad de medida del riesgo, de “tablas migradas” a “contratos de intercambio validados”.
La pregunta que queda abierta —y que aborda la siguiente pieza de esta serie— es cuánto cuesta descubrir ese reset a mitad de proyecto, expresado en semanas de cronograma.
Fuentes
- smartShift, How to Reduce S/4HANA Migration Risk in 2026 (julio 2026). Nota de veracidad: fuente de proveedor con interés comercial en remediación de código custom; las cifras de obsolescencia y de proporción de cambios técnicos son atribuidas por el proveedor, no auditadas de forma independiente.
- SAP Community, blogs de SAP sobre Extended Integration Analysis in SAP Readiness Check (2023). Fuente del fabricante, publicada en su comunidad oficial.
- SAP, nota 2344100 «S4TWL – CVI Integration for SAP IS-U» (documentación oficial del fabricante), complementada con publicaciones de la comunidad SAP sobre conversión CVI en IS-Utilities. Nota de veracidad: las publicaciones de comunidad son de miembros y no documentación oficial; la nota SAP es la referencia vinculante para diseñar el plan de conversión.
- SAP, páginas de producto y ayuda de SAP Integration Suite (Cloud Integration, API Management, Event Mesh y advanced event mesh), 2026.
- SAP Learning, material sobre Business Partner y llamados externos vía módulo de función RFC, 2026.
- Horváth, Business Transformation Unlocked – Maximizing the Benefits of SAP S/4HANA (abril 2025), 200 empresas encuestadas. Nota de veracidad: muestra de DACH, norte y este de Europa y EE. UU.; no incluye LATAM.
- All for One, síntesis de fechas de mantenimiento SAP con referencia a la nota SAP correspondiente (2025).
¿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.
