En las últimas semanas, hemos analizado las capas técnicas de la licitación del SCADA Estandarizado de SEDAPAL (€ 8M). Tras examinar en el Artículo 1: SEDAPAL y el SCADA Estandarizado: alineando la inversión pública con la vanguardia tecnológica el desfase hacia el pasado, y en el Artículo 2: ¿8 M€ por una Caja Negra? El riesgo técnico y contractual oculto detrás del Nuevo SCADA de SEDAPAL la incertidumbre contractual, hoy publicamos la tercera y más crítica parte de este análisis.
En infraestructura crítica, ¿son las bases de licitación simplemente un documento administrativo, o son el "blueprint" (diseño) que condiciona el resultado del proceso?
Para entender la arquitectura de esta licitación, debemos analizar lo que denomino los 4 Vectores de Direccionamiento Técnico:
- Umbral de Experiencia Diluido: ¿Se puede mitigar el riesgo de un sistema para 11 millones de habitantes con una experiencia de apenas un tercio del valor del contrato?
- Ecosistema Local Restrictivo: ¿Priorizamos la excelencia tecnológica o el blindaje territorial mediante integradores físicos?
- Perfiles Técnicos a Medida: ¿Las especificaciones describen un resultado funcional... o una marca específica?
- Ausencia de Ingeniería ‘As-Is’: ¿Quién se beneficia realmente de la "Caja Negra" del sistema actual?
Cuando estos vectores se alinean, ¿el resultado es una competencia abierta... o está estructuralmente condicionado?
Cuando el direccionamiento técnico no se escribe, se diseña
En la contratación pública contemporánea, ¿sigue el "direccionamiento" técnico tomando la forma de exigencias explícitas o referencias directas a marcas y fabricantes?
¿O se construye hoy de una manera más sofisticada, a través de combinaciones de requisitos que, analizados individualmente, parecen razonables, pero que en conjunto comienzan a describir un perfil técnico específico y reconocible?
La pregunta relevante entonces es: ¿Puede cada criterio justificarse de forma aislada, o qué sucede cuando todos apuntan sistemáticamente hacia el mismo tipo de solución, el mismo modelo operativo y el mismo tipo de actor?
¿No es desde esta perspectiva que deberíamos analizar los ejes centrales de la licitación del SCADA Estandarizado?
1. Experiencia del Postor: ¿Gestión de riesgos o una valla estratégicamente baja?
Las bases establecen como requisito obligatorio acreditar una experiencia mínima de S/ 10M (€ 2.5M) en proyectos similares.
Frente a este umbral, ¿no resultan inevitables ciertas preguntas técnicas?
- ¿Desde cuándo se mitiga el riesgo de un proyecto que integra la operación de una ciudad de 11 millones de habitantes con una experiencia equivalente a aproximadamente un tercio del valor estimado del contrato?
- ¿Qué tipo de capacidad técnica real se pretende garantizar cuando el umbral de experiencia no escala proporcionalmente con la criticidad, complejidad y alcance metropolitano del sistema?
- En proyectos de infraestructura digital crítica, ¿debería la experiencia mínima medirse únicamente en montos contractuales, o también en magnitud operativa, número de activos gestionados y responsabilidad sobre servicios esenciales continuos?
- ¿Filtra este umbral efectivamente a operadores con trayectoria probada en sistemas urbanos de gran escala, o ensancha el espectro hacia actores con menos historial en proyectos equivalentes pero con conocimiento previo del entorno específico?
- Cuando el requisito de experiencia no parece alineado con el riesgo sistémico del proyecto, ¿es la prioridad la mitigación del riesgo operativo o la compatibilidad con perfiles ya conocidos dentro del ecosistema local?
2. El Ecosistema de Integradores: ¿Garantía de soporte o blindaje territorial?
Las bases exigen que el software ofertado deba contar con 03 integradores locales y 02 integradores regionales, certificados por el fabricante.
¿Responde este criterio a una necesidad técnica objetiva, o plantea interrogantes más estructurales?
- En una industria dominada por arquitecturas web, microservices, contenedores, monitoreo proactivo y soporte remoto 24/7, ¿es el número de integradores físicos un indicador real de calidad técnica y continuidad operativa?
- ¿Depende la resiliencia de un SCADA moderno más del número de integradores en un territorio específico o de la arquitectura de soporte, los SLAs, la trazabilidad de incidentes y la capacidad de escalamiento global?
- ¿Cómo pueden competir las plataformas nativas en la nube (cloud-native), con soporte especializado centralizado y operación remota avanzada, frente a requisitos diseñados bajo paradigmas de soporte predominantemente presencial?
- ¿Busca este criterio una redundancia operativa real, o refuerza modelos de distribución tradicionales que solo ciertas tecnologías han consolidado históricamente en la región?
- Cuando se favorecen estructuras comerciales extensas y distribuidas geográficamente, ¿se está evaluando la excelencia técnica o se está privilegiando la presencia histórica de ciertos actores en el mercado local?
3. Neutralidad Tecnológica: ¿Diseño de ingeniería o especificaciones con firma implícita?
El principio de neutralidad tecnológica establece que las especificaciones técnicas deben describir resultados funcionales, no imponer arquitecturas internas ni lógicas de diseño específicas.
Sin embargo, ¿no surgen dudas relevantes al analizar el nivel de detalle técnico del documento?
- ¿Por qué ciertas especificaciones describen estructuras funcionales internas con un grado de precisión que coincide notablemente con la arquitectura de plataformas ya existentes?
- Si el entorno SCADA actual —topología OT, inventario de RTU/PLC, capas de redundancia— no ha sido auditado ni revelado, ¿no se está forzando al ganador a realizar una ingeniería inversa en vivo y bajo plena carga operativa?
- ¿Cómo pueden competir soluciones maduras si deben alinearse con un diseño que no es genérico, sino reconocible solo para quienes ya conocen el ecosistema?
- ¿Es posible hablar de neutralidad tecnológica cuando el lenguaje técnico reduce significativamente el margen para enfoques arquitectónicos alternativos?
- ¿Se está promoviendo una estandarización abierta, o se está trasladando la lógica interna de una solución preexistente a un documento normativo?
4. La Ingeniería Básica Ausente: ¿Gestión de riesgos o ventaja informativa implícita?
Las bases de la licitación no incorporan la ingeniería básica "AS-IS" del sistema SCADA actual.
¿Es esto un detalle administrativo menor o un elemento estructural del proceso?
- ¿Cómo pueden los postores dimensionar correctamente alcances, costos y riesgos si la ingeniería básica no forma parte del expediente técnico?
- ¿Puede considerarse que existe competencia simétrica cuando el conocimiento detallado del sistema actual no está disponible para todos los participantes?
- En un contrato a Suma Alzada, ¿no aumenta la ausencia de ingeniería básica el riesgo de sobrecostos ocultos, contingencias no declaradas y disputas contractuales?
- ¿Quién asume realmente el riesgo técnico cuando la ingeniería solo se "descubre" después de la adjudicación?
- ¿Beneficia la falta de información técnica a quien entra "a ciegas" o a quien ya conoce las interdependencias, atajos y fragilidades del sistema actual?
Es en este contexto donde la lógica implícita del proceso queda expuesta por una pregunta incómoda:
"¿No parece que el mensaje técnico subyacente es: '¿Gana primero, firma el contrato... y luego descubre qué es exactamente lo que tienes que migrar’?"
- Si no se revela el entorno SCADA AS-IS —topología OT, inventario de RTU/PLC, pila de protocolos, capas de redundancia y dependencias de telecomunicaciones— ¿no se transforma la modernización en una ingeniería inversa de un sistema en producción y bajo carga operativa?
- ¿No implica esto ejecutar la migración mientras el sistema sigue abasteciendo de agua a millones de usuarios, sin una comprensión completa del comportamiento real del tráfico OT?
- ¿Cómo se gestiona la estabilidad de la integración y el riesgo de falla durante el cutover (migración) si los patrones de tráfico y dependencias no fueron modelados previamente?
- ¿No se generan exposiciones latentes de ciberseguridad cuando existen interfaces legadas no documentadas que solo se descubren durante la ejecución?
- Para una empresa operadora de escala metropolitana, ¿no debería el proceso lógico iniciar con una auditoría técnica independiente, seguida de una arquitectura de referencia y una hoja de ruta de migración por fases, antes de fijar un modelo de ejecución a Suma Alzada?
- Cuando estas etapas se omiten y se incorporan implícitamente dentro del contrato de ejecución, ¿no se está trasladando el riesgo de la infraestructura pública a asunciones comerciales opacas?
Cuando cuatro criterios convergen
Si estos cuatro factores se analizaran de forma aislada, ¿podrían interpretarse como decisiones técnicas independientes?
Pero cuando se observan en conjunto, ¿no aparece un patrón reconocible?
- ¿Qué sucede cuando el umbral de experiencia, el modelo de integradores, el detalle arquitectónico y la ausencia de ingeniería básica apuntan simultáneamente hacia el mismo perfil técnico?
- ¿Sigue siendo razonable hablar de competencia abierta cuando solo ciertos actores pueden cumplir con los cuatro criterios sin necesidad de rediseños forzados o exposición a riesgos no cuantificados?
- ¿Puede considerarse una coincidencia que estos cuatro elementos encajen como piezas de un mismo rompecabezas?
- ¿No es precisamente esa suma, y no cada requisito por separado, lo que configura un posible direccionamiento técnico?
¿Ayuda un esquema visual que represente estos cuatro criterios como vectores independientes que, al solaparse, convergen en un único resultado posible?
¿No facilita esa visualización entender que el direccionamiento no se declara, emerge?
Cuando las preguntas dejan de ser académicas
Cuando se licita el sistema nervioso digital de una ciudad, ¿no son los criterios los que definen el modelo tecnológico que quedará instalado por décadas?
- ¿Está la entidad adquiriendo la mejor tecnología para el futuro —Agua 4.0, IA, Gemelos Digitales— o está formalizando una solución que simplemente "encaja" en un documento preconfigurado?
- Al ignorar los patrones de tráfico OT y las dependencias de telecomunicaciones, ¿estamos "licitando una crisis durante la migración"?
- ¿Se están mitigando los riesgos sistémicos, o se están dejando las interfaces legadas como puntos ciegos para la ciberseguridad?
Porque el futuro del agua de una ciudad, ¿debería ser un resultado previsible redactado en un escritorio?
¿O el resultado de una competencia técnica genuina, abierta y transparente?
¿Qué sentido tendría el direccionamiento técnico si no es para entregar una transformación verdaderamente disruptiva para la ciudad, sino meramente para aplicar un "lavado de cara" tecnológico sobre un núcleo sistémico que permanece fundamentalmente inalterado?
