¿Cómo se puede cotizar responsablemente la migración del cerebro digital de Lima si la ingeniería básica del sistema actual no está sobre la mesa?
La reacción a mi último análisis sobre la desconexión tecnológica del Concurso Público N.° 28-2025 ha sido clara y contundente.
La comunidad técnica lo sabe: el sector agua necesita modernización, no simples renovaciones de licencias ni cambios cosméticos.
Sin embargo, tras una revisión técnica de las Bases y Términos de Referencia (TDR), emerge un riesgo estructural mucho más grave que la obsolescencia tecnológica: la asimetría de la información técnica.
Y cuando se trata de infraestructura crítica, la asimetría no es un detalle administrativo; es un factor que condiciona costos, competencia, continuidad operativa y, eventualmente, conflictos contractuales.
Un proyecto complejo… sobre terreno incierto
El objetivo del proyecto es ambicioso: implementar un sistema SCADA estandarizado que reemplace y unifique un ecosistema heterogéneo y crítico, valorizado en 8 M€.
El verdadero desafío no está en las plataformas menores, sino en la migración de los tres SCADA neurálgicos que hoy sostienen el servicio de agua potable de Lima y Callao:
- OASYS: Controla y supervisa las Plantas de Tratamiento de Agua Potable de La Atarjea, con una producción de 20 a 24 m³/s (457 a 548 MGD), abasteciendo a casi 11 millones de habitantes.
- InfoPlus: Controla y supervisa cientos de estaciones remotas de regulación de presión y caudal en las redes primarias de Lima y Callao.
- Survalent: Controla y supervisa cientos de pozos, estaciones de rebombeo y reservorios, distribuidos por toda la ciudad.
Hasta aquí, el desafío es evidente.
Pero al analizar la Secuencia de Actividades establecida en las Bases, surge una alerta roja.
1. Ítem 8.2: ¿Un estudio de mercado a ciegas?
En la página 31, ítem 8.2, las Bases establecen que el contratista deberá realizar el: “Levantamiento de Información de los Actuales SCADA”.
Este punto es crítico.
SEDAPAL realizó un estudio de mercado por 8 M€, bajo la modalidad de Suma Alzada, sin entregar como parte de las Bases la ingeniería básica detallada del sistema existente.
La pregunta técnica es inevitable: ¿Puede considerarse válido un estudio de mercado cuando los postores desconocen el alcance real del sistema a migrar?
En la práctica, el ítem 8.2 traslada al contratista la responsabilidad de descubrir, definir y cuantificar el alcance real del proyecto, después de firmado el contrato.
Estamos hablando de un entorno Brownfield de enorme complejidad:
- más de 1,000 PLCs y RTUs de múltiples marcas y generaciones,
- miles de variables (tags), alarmas e interlocks acumulados durante décadas,
- diversos protocolos y medios de comunicación en operación continua.
Ante este escenario, cabe plantear la interrogante de fondo:
¿Acaso no será que la entidad carece de la información actualizada de su propia Ingeniería Básica (SCADAs, PLCs, comunicaciones) y, al no poder incluirla en las Bases, ha decidido trasladar ese riesgo estructural al contratista para subsanar un vacío de gestión?
2. Lo que debió ser un dosier técnico (y hoy no existe)
El ítem 8.2 reconoce implícitamente que la información crítica no está consolidada. Pero esa información no es trabajo futuro del contratista: es conocimiento operativo que la entidad ya posee (o debería poseer) y que debió formar parte de las Bases.
Un dosier técnico (ingeniería básica detallada) mínimo debió incluir:
Arquitectura y funcionalidad AS-IS
- Descripción técnica (no narrativa) de la función específica de cada SCADA, entre ellos: OASYS (Planta), InfoPlus (Redes Primarias) y Survalent (Bombeo), que operan separadamente con un intercambio mínimo de datos entre ellos.
- Qué controla cada sistema, qué supervisa y qué queda fuera de su alcance.
- Inventario del hardware legacy crítico (servidores HP, Dell, almacenamiento IBM).
Análisis functional por SCADA
- Memorias descriptivas reales.
- Filosofía de control y operación vigente.
- Gestión de setpoints, alarmas, reportes críticos, etc.
- Versiones exactas de software de cada SCADA, entre ellos: InfoPlus, OASyS DNA, Survalent y sus dependencias críticas.
Ingeniería SCADA–PLC (la “carne” del proyecto)
- Inventario auditado de PLCs y RTUs (marca, modelo, firmware).
- Diccionario completo de variables (EA, ED, SA, SD, diagnósticos, variables internas, etc).
- Frecuencias reales de polling por zona.
Conunicaciones y red
- Protocolos exactos por enlace.
- Diagramas lógicos y físicos de red (con direccionamiento IP y topología real).
- Estado de los medios de comunicación y redundancias.
- Detalle de la red MPLS en los 7 Centros de Servicios, configuración de los routers de borde, direccionamiento IP real y topología de la red de microondas (Ceragon/NEC) que hoy transporta la data crítica.
Históricos y bases de datos
- Cantidad real (no estimada) de tags históricos a migrar.
- Políticas de retención vigentes.
- Estructura y volumetría real de las bases de datos Oracle y SQL Server existentes.
Migración y coexistencia
- Estrategia de Operación en Paralelo (Coexistencia): ¿Cómo operará el SCADA nuevo mientras convive con el antiguo durante la transición?
- Plan detallado para la Planta La Atarjea, cuya operación es de misión crítica y no admite paradas (cero downtime).
- Pruebas FAT / SAT y criterios de aceptación objetivos.
Sin este dosier, no existe cierre técnico del alcance.
3. Cuando el levantamiento se convierte en riesgo contractual
(Y cuando el problema deja de ser técnico para ser legal)
El ítem 8.2 no es un paso operativo menor.
Desde la perspectiva de la Ley General de Contrataciones Públicas del Perú, evidencia un traslado de obligaciones propias de la fase preparatoria hacia la etapa de ejecución contractual.
La normativa es clara: el requerimiento debe estar técnica y funcionalmente definido antes de convocar.
Las Bases no son un documento exploratorio; son el instrumento que permite a los postores formular ofertas comparables, diligentes y económicamente responsables.
Cuando el levantamiento AS-IS se exige después de la adjudicación:
- el alcance real no está definido al licitar,
- la ingeniería básica no forma parte del expediente técnico,
- el riesgo tecnológico no ha sido identificado ni gestionado por la entidad, sino desplazado al contratista.
Y hacerlo bajo Suma Alzada agrava el problema.
En este tipo de contratos, el precio se sustenta en:
- un alcance cerrado,
- riesgos identificados,
- condiciones técnicas conocidas.
Si el contratista descubre, ya firmado el contrato, la magnitud real de la infraestructura, la lógica heredada o las incompatibilidades técnicas, el precio ofertado no refleja eficiencia, sino incertidumbre.
Cuando se rompe el principio de valor por dinero
No puede existir valor por dinero cuando:
- los postores no conocen el alcance real,
- las ofertas no se construyen sobre la misma base técnica,
- el presupuesto referencial carece de sustento verificable.
El mercado responde con sobreprecio, ventaja informativa o apuestas contractuales.
Ninguna maximiza el interés público.
Cuando se afecta la predictibilidad contractual
Sin un AS-IS técnico claro:
- la exigibilidad del contrato se debilita,
- la supervisión se vuelve reactiva,
- y la entidad queda expuesta a controversias evitables.
El levantamiento del ítem 8.2 no gestiona el riesgo: lo posterga y lo traslada.
Es en este contexto que la lógica implícita del proceso queda expuesta: “Primero gana, firma el contrato… y luego averigua qué es exactamente lo que tienes que migrar.”
4. La “caja negra” y la ilusión de la competencia
Cuando la ingeniería básica detallada de los sistemas existentes no está en las Bases, la competencia deja de ser técnica y pasa a ser asimétrica por conocimiento previo.
Un proveedor con presencia histórica conoce los vicios ocultos del sistema.
Un integrador que entra desde cero compite a ciegas.
La pregunta es inevitable: ¿todos los postores compiten realmente en igualdad de condiciones?
Conclusión: transparencia o incertidumbre institucional
La modernización del agua en el Perú es urgente.
Pero la prisa no puede justificar la opacidad técnica.
Un SCADA no es un software más:
es el sistema nervioso de una infraestructura que no puede detenerse.
La pregunta final no es tecnológica, es institucional:
¿Cómo puede diseñarse el “SCADA del Futuro” si no se transparenta primero como funciona los “SCADAs actualmente”?
Cuando la ingeniería básica detallada no está en las Bases, la competencia no se da por capacidad, sino por cercanía histórica al sistema.
Y eso no es transformación digital. Eso es gestión de incertidumbre disfrazada de modernización.
