Presupuestar a ciegas: por qué ningún plan de conversión vale sin el Readiness Check
El SAP Readiness Check define alcance real: simplification items, código a medida, add-ons y sizing de HANA. Sin él, cualquier presupuesto de conversión es una apuesta.
· 8 min de lectura
Todo proyecto de conversión SAP arranca con la misma pregunta incómoda: ¿cuánto va a costar y cuánto va a durar? Y casi siempre, la primera respuesta que llega a la mesa es una estimación de consultoría —basada en experiencia, en proyectos comparables, en reglas de dedo probadas en otros clientes—. Es un punto de partida razonable. El problema es tratarlo como si fuera el alcance real.
La pieza anterior de esta serie situó la decisión de fondo: convertir en vez de reimplementar para preservar histórico y continuidad meter-to-cash. Esta pieza entra en el terreno donde ese buen criterio se vuelve, sin querer, un mal presupuesto: la diferencia entre estimar y medir.
Una estimación no es un alcance

Una consultoría experimentada puede acercarse bastante con una estimación basada en patrones. Pero un patrón describe el proyecto promedio, no el sistema específico que una utility o una empresa de oil & gas en LATAM ha operado, parcheado y extendido durante años. Cada desarrollo a medida, cada add-on de terceros, cada tabla que creció sin que nadie la archivara, es una variable que una estimación por comparables no puede ver.
La fuente real del alcance no es una conversación de kickoff: es el SAP Readiness Check, la herramienta que SAP pone a disposición para diagnosticar, sistema por sistema, qué exige realmente la conversión (Agisolo, 2026). No reemplaza el criterio del consultor —lo alimenta con datos del sistema real en vez de con promedios de otros proyectos.
Qué mide el Readiness Check que una estimación no puede medir
El Readiness Check cubre cuatro frentes que definen el esfuerzo real de una conversión, y ninguno de los cuatro es adivinable desde afuera del sistema:
El Readiness Check ofrece un análisis integral que cubre estos cuatro frentes —simplification items, desarrollos a medida, sizing de hardware y compatibilidad de add-ons—, a diferencia de un chequeo puramente técnico de consistencia, que solo verifica que el sistema esté en un estado apto para la conversión sin dimensionar el esfuerzo (Agisolo, 2026). Esa distinción importa: una cosa es confirmar que el sistema puede convertirse; otra es saber cuánto trabajo exige convertirlo.
Simplification items: lo que cambia, no lo que se rompe
Los simplification items documentan los cambios incompatibles o disruptivos entre el ERP actual y S/4HANA para una versión de destino específica. No todos aplican a todos los clientes —la relevancia depende de qué módulos y procesos usa cada sistema—, y esa es precisamente la razón por la que una lista genérica de “problemas típicos de conversión” no sirve como sustituto: cada sistema tiene su propio subconjunto relevante, y solo el Readiness Check lo calcula contra el sistema real.
Código a medida: años de desarrollos que nadie ha vuelto a mirar
En una utility con años de operación sobre SAP, es común que existan desarrollos a medida que dejaron de tocarse hace tiempo pero que siguen afectando el rendimiento o la lógica de negocio en producción. El Readiness Check identifica esos desarrollos y qué tan afectados quedan por la arquitectura simplificada del sistema de destino, distinguiendo entre ajustes con corrección automática disponible y casos que requieren rediseño funcional con revisión de un experto de negocio.
Compatibilidad de add-ons: el punto donde un proyecto se detiene sin aviso
El Maintenance Planner de SAP verifica los add-ons, business functions y soluciones de industria instaladas contra la versión de destino de S/4HANA, y genera el archivo que habilita técnicamente la conversión. Si encuentra un add-on incompatible que no puede desinstalarse ni actualizarse, el proceso de planificación simplemente no continúa hasta resolverlo. Para una utility que corre soluciones de industria específicas sobre IS-U, o integraciones de terceros para telemetría y AMI, este chequeo no es un trámite: es el punto donde un proyecto bien intencionado puede detenerse en seco si no se hizo antes de comprometer fechas con el negocio.
Sizing de HANA: memoria real, no una tabla de referencia

El dimensionamiento de hardware para S/4HANA se calcula con reportes de sizing que analizan los datos reales del sistema actual —volumen de tablas, patrones de uso, crecimiento histórico— y no con tablas de referencia genéricas por tamaño de empresa. El Readiness Check incorpora este cálculo dentro del mismo diagnóstico, lo que evita que el sizing de infraestructura se convierta en una sorpresa de última hora, después de que el presupuesto ya se aprobó con otro número.
Por qué esto es distinto para meter-to-cash
Cada uno de estos cuatro frentes toca directamente los procesos que sostienen la operación diaria de una utility: los simplification items pueden afectar cómo se procesan las lecturas de consumo; el código a medida suele concentrarse justo en la lógica de facturación y corte/reconexión que se construyó para el marco regulatorio local; los add-ons de industria a menudo son los que conectan IS-U con la infraestructura de medición; y el sizing de HANA determina si el sistema convertido puede sostener los volúmenes de transacciones de facturación sin degradar el rendimiento.
Presupuestar sin este diagnóstico no es solo un riesgo financiero. Es aceptar que el cronograma y el alcance de un proyecto que va a tocar facturación, corte y reconexión se construyan sobre una estimación genérica en vez de sobre datos del sistema real.
Lo que sigue
Una vez que el Readiness Check pone el alcance sobre la mesa, casi siempre aparece el mismo hallazgo: años de código a medida esperando revisión. La siguiente pieza de esta serie entra en ese terreno — por qué veinte años de código Z no se corrigen objeto por objeto, y qué significa remediar a escala antes de tocar producción.
Fuentes
- Agisolo — SAP Readiness Check vs Simplification Item Check: The Key Differences, 2026: https://agisolo.de/en/iqhub/sap-readiness-check-vs-simplification-item-check-the-key-differences/
- Eursap — SAP Readiness Check 2.0 for SAP S/4HANA Conversion, 2026: https://eursap.eu/blog/sap-readiness-check-2-0-for-sap-s-4hana-conversion
- SAP Community — Handling Add-Ons during a system conversion/upgrade to SAP S/4HANA: https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/handling-add-ons-during-a-system-conversion-upgrade-to-sap-s-4hana/ba-p/13517061
¿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.