Dimensionar remediación SAP: el rango vale más que la cifra

La pregunta llega siempre en el mismo momento: en la reunión donde todavía no hay acceso al sistema. Un comité de inversión de una distribuidora eléctrica, o el gerente de TI de un operador de hidrocarburos, necesita cerrar el presupuesto del año y pide una cifra para la remediación del código, las interfaces y las cargas que sostienen la facturación masiva y la gestión de activos de red. No pide un rango. Pide un número, y lo pide antes de que exista una sola medición del landscape que va a remediar.

Quien responde con una cifra firme en ese momento no está estimando: está apostando. Y la apuesta se pierde en las dos direcciones.

El número se pide antes de que el sistema se pueda medir

Esta es la primera entrega de una serie sobre un problema que en nuestra práctica SAP vemos repetirse en casi todos los procesos de compra: se exige el dimensionamiento del alcance de remediación antes de que exista la evidencia técnica que permitiría dimensionarlo.

No es un vicio local ni un defecto de disciplina. La literatura de estimación lo tiene medido desde hace décadas. En una encuesta a profesionales de proyectos, el 53% respondió que el dimensionamiento se hace una sola vez, en la etapa de propuesta o licitación, y más del 85% lo hace una o dos veces en todo el ciclo de vida (Khan y Beg, JSCSE, 2013). El momento con menos información disponible es, en la práctica, el único momento en que se mide.

Para una distribuidora que corre facturación masiva sobre un ECC con veinte años de acumulación, esa foto inicial no distingue entre el código que sostiene el ciclo comercial todos los meses y el que quedó de un proyecto abandonado. Y sin embargo, sobre esa foto se firma.

Los dos errores no cuestan lo mismo, pero ambos se cobran

---
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([Se entrega una cifra firme sin sistema medido]) --> B{¿Hacia dónde erró el número?}
  B -->|De más| C[El proyecto no se adjudica]
  C --> D[El comité elige al proveedor que dio menos]
  D --> E([Costo invisible para el cliente y total para quien estimó bien])
  B -->|De menos| F[El proyecto se adjudica y el faltante lo absorbe alguien]
  F --> G{¿Modalidad contractual?}
  G -->|Precio fijo| H([Lo absorbe el proveedor])
  G -->|Bolsa de horas| I([Lo absorbe el presupuesto del cliente a mitad de camino])
  class A inicio
  class B,G decision
  class C,D,F proceso
  class E,H,I malo
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 malo fill:#462226,stroke:#ef4444,color:#ffffff

Aquí está la asimetría que da título a esta pieza. Errar el número tiene dos salidas, y ninguna es neutra.

Si el número sale de más, el proyecto no se adjudica. La cifra alta se lee como falta de método —“no saben lo que están haciendo, por eso ponen colchón”— y el comité elige al proveedor que dio menos. El costo es invisible para el cliente y total para quien estimó bien.

Si el número sale de menos, el proyecto se adjudica y el faltante lo absorbe alguien. En modalidad de precio fijo, lo absorbe el proveedor. En modalidad de bolsa de horas, lo absorbe el presupuesto del cliente a mitad de camino, cuando ya no hay marcha atrás y la ventana de mantenimiento se está cerrando. El dato incómodo es que este es el error dominante: en la totalidad de los proyectos analizados en un estudio de campo sobre iniciativas con desempeño deficiente, se encontró subestimación de tamaño, costo y cronograma frente al tamaño real del software (Khan y Beg, JSCSE, 2013).

Y el problema no es solo estimar mal, sino congelarlo. En el 82% de esos proyectos, las estimaciones tempranas se convirtieron en compromisos contractuales legalmente vinculantes sin ninguna diligencia previa que las validara (Khan y Beg, JSCSE, 2013).

La exactitud es mínima justo cuando más se decide

El cono de incertidumbre explica por qué esto no se resuelve pensando más. Las estimaciones creadas en la etapa de concepto inicial pueden desviarse por un factor de 4x hacia arriba o de 0,25x hacia abajo, lo que da un rango total de 16x entre el extremo alto y el bajo (Construx Software, 2020). Dedicarle una semana más al ejercicio no lo corrige: la exactitud de la estimación depende del nivel de refinamiento de la definición del sistema, no del esfuerzo puesto en calcular (Construx Software, 2020).

Ese es el dilema de fondo. Las estimaciones tienen su máximo valor al inicio del proyecto —es cuando se deciden presupuesto y asignación de personal— y es exactamente el punto donde su exactitud es la más baja de todo el ciclo (Khan y Beg, JSCSE, 2013). El cono no se estrecha por convicción: se estrecha por decisiones que eliminan variabilidad. Cuando un proyecto no converge, la incertidumbre deja de ser un cono y se vuelve una nube que persiste hasta el final (Construx Software, 2020).

Lo que sí se puede medir, y cuánto tarda medirlo

La buena noticia para un landscape SAP es que la variabilidad no es un misterio: es un dato que todavía no se recolectó. La mala es que recolectarlo toma tiempo real.

SAP recomienda iniciar la recolección de datos de uso en los sistemas productivos al menos un año antes del proyecto de conversión a SAP S/4HANA (SAP Community, 2026). Ese año no es un trámite: es la ventana que captura los cierres trimestrales y el cierre de ejercicio, sin los cuales el ciclo comercial de una utility queda representado a medias. Cargados esos datos, la app Custom Code Migration define el alcance inicial de la migración sobre lo que efectivamente se usa, y el alcance puede ajustarse manualmente después (SAP Help Portal, Custom Code Migration Guide for SAP S/4HANA, 2025).

Hay un segundo factor que mueve el número de forma material: las Quick Fixes en ABAP Development Tools para Eclipse permiten adaptar aproximadamente el 60% del código a SAP S/4HANA de manera semiautomatizada (SAP Community, 2026). Estimar sin saber qué proporción de los hallazgos cae en ese grupo es estimar dos proyectos distintos con el mismo precio.

El calendario aprieta: el mantenimiento mainstream de las aplicaciones core de SAP Business Suite 7 se extiende hasta fines de 2027, con mantenimiento extendido opcional hasta fines de 2030 (SAP, estrategia de mantenimiento, 2020). Quien todavía no encendió la recolección de uso ya está estimando con menos evidencia de la que podría haber tenido.

Cómo se entrega un rango que un comité acepta

Un rango sin método es una excusa. Un rango con método es un instrumento de gobierno, y se construye con tres piezas:

• Los supuestos explícitos, cada uno con su impacto en el número. Qué pasa con la cifra si el volumen de objetos en alcance resulta la mitad; qué pasa si las interfaces de la gestión de activos de red están más acopladas de lo declarado.
• El disparador de convergencia: la medición concreta que estrecha el cono y la fecha en que estará disponible. Sin esto, el rango nunca se cierra.
• El compromiso diferido. La recomendación de la literatura es explícita: los compromisos contractuales de costo y cronograma deberían postergarse hasta la etapa de diseño de la solución, y todo lo anterior debe declararse tentativo y sujeto a cambio significativo (Khan y Beg, JSCSE, 2013). Los compromisos significativos se vuelven posibles alrededor del 30% de avance del proyecto (Construx Software, 2020).

En nuestros proyectos con utilities y operadores de O&G en América Latina, EvoTech Consulting entrega el rango con esas tres piezas visibles. No porque suene más prudente, sino porque un rango que declara qué lo va a cerrar es verificable, y una cifra firme dada sin sistema medido no lo es.

El rango honesto vale más que la cifra firme por una razón simple: es el único de los dos que se puede defender cuando el proyecto avanza.

En la siguiente entrega de esta serie abordamos la primera fuente concreta de sobreestimación del alcance: el código de industrias que la empresa nunca operó, y por qué el conteo bruto de objetos infla el número desde el primer día.

Fuentes

• Construx Software — The Cone of Uncertainty. https://www.construx.com/books/the-cone-of-uncertainty/
• Khan, P. M. y Beg, M. M. S. — Application of Sizing Estimation Techniques for Business Critical Software Project Management, International Journal of Soft Computing and Software Engineering (JSCSE), Vol. 3, No. 6, 2013. https://arxiv.org/pdf/1405.6335
• SAP Help Portal — Custom Code Migration Guide for SAP S/4HANA 2025. https://help.sap.com/doc/9dcbc5e47ba54a5cbb509afaa49dd5a1/2025.001/en-US/CustomCodeMigration_EndtoEnd.pdf
• SAP Community — Get started with the ABAP custom code migration process (actualización agosto 2026). https://community.sap.com/t5/technology-blog-posts-by-sap/get-started-with-the-abap-custom-code-migration-process/ba-p/13531886
• SAP Community — Custom code adaptation for SAP S/4HANA – FAQ. https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/custom-code-adaptation-for-sap-s-4hana-faq/ba-p/13418880
• SAP Support Portal — Innovation Commitment for SAP S/4HANA until 2040 / Maintenance Strategy. https://support.sap.com/en/release-upgrade-maintenance/maintenance-information/maintenance-strategy/s4hana-business-suite7.html