Cómo comunicar un rango de remediación sin perder credibilidad
Por qué el rango deja de ser una excusa cuando se presenta con calendario de estrechamiento: qué evidencia entra, en qué fase, y qué extremo cae con cada una.
· 6 min de lectura
Hay un momento en toda remediación de facturación masiva o de gestión de activos de red en el que el cliente deja de preguntar “¿qué encontraron?” y empieza a preguntar “¿cuánto cuesta?”. En la pieza anterior de esta serie describimos cómo se estrecha un rango con evidencia parcial sin fabricar precisión. Esta pieza responde a lo que viene después: qué se le dice al cliente cuando ese número firme todavía no existe, y cómo ese rango se convierte en un compromiso contractual sin que el proveedor asuma un riesgo que no le corresponde.
El rango deja de ser una excusa cuando tiene calendario
El error habitual no es presentar un rango — es presentarlo como si fuera un vacío temporal que algún día se llenará con un número exacto. Esa forma de comunicarlo invita al cliente a presionar por precisión antes de que exista evidencia para sostenerla, y a leer cualquier ajuste posterior como un fallo de estimación en vez de como el resultado esperado del proceso.
La literatura de estimación de software documenta que la exactitud alcanzable en cualquier punto de un proyecto está limitada por cuánta variabilidad se ha eliminado hasta ese momento, no por cuánto esfuerzo adicional se invierte en refinar el cálculo (Construx Software, 2016). Ese mismo marco documenta que un estrechamiento significativo ocurre durante el primer 20-30% del calendario total del proyecto (Construx Software, 2016). Traducido a una remediación sobre código IS-U, interfaces AMI y cargas de integración: el rango inicial es ancho porque todavía no se sabe, no porque el consultor no quiera comprometerse.
Qué entra en cada fase, y qué extremo del rango cae
En nuestros proyectos sobre plataformas de Meter-to-Cash y gestión de activos de red, el rango inicial suele estar dominado por hallazgos de diagnóstico que todavía no se han cuantificado en esfuerzo de remediación: lecturas duplicadas que generan desbalance entre Comercial y Facturación, tiempos de transmisión inconsistentes que rompen la secuencia de eventos en la capa de integración, o eventos de medición sin timestamp normalizado que quiebran flujos downstream. Cada uno de estos hallazgos empuja el extremo superior del rango hacia arriba mientras no se sabe cuántas interfaces lo replican.
El estrechamiento no ocurre por el paso del calendario en sí, sino por decisiones que reducen esa variabilidad — exactamente el punto que documenta la práctica ágil de estimación: proveer un rango no es una alternativa cómoda a la cifra exacta, es la única entrega honesta posible mientras la definición del alcance sigue evolucionando (iamagile.io, 2026). En una remediación AMI-M2C, eso se traduce en hitos concretos:
Cada fase no reduce el rango de forma pareja: normalmente comprime el extremo superior primero, porque la evidencia temprana suele descartar los escenarios de mayor alcance antes de confirmar el volumen exacto del extremo inferior.
Cómo se contractualiza sin asumir un riesgo que no es tuyo
Contractualizar un rango no significa firmar sobre la cifra más baja para ganar el trato ni sobre la más alta para protegerse. Significa anclar el contrato a los hitos de evidencia, no a la fecha del calendario. Un rango con calendario de estrechamiento se sostiene con tres elementos explícitos en la propuesta o el anexo técnico:
- Qué evidencia entra en cada hito — por ejemplo, el resultado del muestreo de concentradores AMI, o el conteo real de interfaces con desbalance M2C, no una fecha genérica de “revisión”.
- Qué extremo del rango se mueve con esa evidencia — declarar de antemano si el hito reduce el techo, el piso, o ambos, evita que el cliente interprete cualquier movimiento como una corrección arbitraria.
- Quién asume el costo de la variabilidad restante — mientras el rango no se ha cerrado, el riesgo de la parte no evidenciada del alcance no debe transferirse íntegramente al proveedor solo porque el cliente prefiere una cifra fija; ese es precisamente el punto que la organización cede cuando compromete un número antes de que el cono de incertidumbre lo permita (Construx Software, 2016).
La conversación con el cliente
Cuando el rango se presenta como un compromiso con calendario, la pregunta del cliente deja de ser “¿por qué no me dan un número?” y pasa a ser “¿qué necesito aprobar para que el rango se cierre?”. Esa segunda pregunta es la que permite avanzar el proyecto sin que el proveedor especule sobre un alcance de remediación que la evidencia todavía no sostiene, y sin que el cliente quede atado a una cifra que ninguna de las dos partes puede defender con datos.
Esta pieza cierra la serie sobre cómo se dimensiona una remediación antes de conocer completamente el sistema. El punto de partida y el punto de llegada son el mismo: el rango no es una debilidad de la propuesta técnica — es la forma correcta de comunicar lo que todavía no se puede medir, mientras se construye la evidencia para medirlo.
Fuentes
- Construx Software, The Cone of Uncertainty, 2016. https://www.construx.com/books/the-cone-of-uncertainty/
- iamagile.io, Cone of Uncertainty in Agile Estimation, 2026. https://iamagile.io/blog/cone-of-uncertainty-agile-estimation
¿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.
