HES/MDM agnóstico: la decisión antes del primer contrato AMI

Una distribuidora eléctrica que ya aprobó el caso de negocio de su piloto AMI llega a un punto de decisión que rara vez recibe la atención que merece: la firma del primer contrato de medidores. Es la pieza anterior de esta serie la que explicó cómo convertir el ROI del piloto en un caso de negocio que convence a finanzas. Esta pieza se detiene en la cláusula que suele pasar desapercibida en ese primer contrato: qué plataforma de gestión de medidores (HES/MDM) queda instalada detrás de esos primeros dispositivos, y si esa plataforma podrá seguir sirviendo cuando la oleada 2 traiga un fabricante distinto.

Un HES no es solo hardware: es la puerta de entrada a SAP IS-U

flowchart TD
  A([Lecturas del medidor]) --> B{Arquitectura HES/MDM}
  B -->|Tres capas| C[Un MDMS externo media entre el HES y SAP]
  C --> D([El MDMS media el dato de medición])
  B -->|Dos capas| E[SAP se conecta directo al HES vía AMI/MDUS]
  E --> F([SAP es el maestro del dato de medición])
  class A inicio
  class B decision
  class C,E proceso
  class D,F neutro
classDef inicio fill:#19284a,stroke:#2563eb,color:#ffffff
classDef decision fill:#473519,stroke:#f59e0b,color:#ffffff
classDef proceso fill:#33363c,stroke:#9aa0aa,color:#ffffff
classDef neutro fill:#33363c,stroke:#9aa0aa,color:#ffffff

El Head-End System (HES) es el punto donde los medidores inteligentes entregan sus lecturas antes de que esa información llegue a SAP. En arquitecturas IS-U/S/4HANA Utilities, esa entrada puede resolverse de dos formas: un esquema de tres capas, donde un sistema externo de Meter Data Management (MDMS) media entre el HES y SAP, o un esquema de dos capas, donde SAP se conecta directamente al HES mediante los servicios empresariales de AMI y la sincronización MDUS, asumiendo el rol de maestro de los datos de medición (SAP Community, 2017). Ninguna de las dos rutas es genérica: ambas dependen de que el HES hable el mismo idioma que Device Management de SAP IS-U, sin importar qué fabricante fabricó el medidor físico.

Ahí está el punto ciego del primer contrato: cuando la distribuidora negocia con un solo fabricante de medidores para la oleada 1, es común que ese mismo fabricante ofrezca “incluido” su propio HES propietario. Funciona bien mientras todos los medidores sean de esa marca. El problema aparece en la oleada 2, cuando el presupuesto obliga a licitar con otro proveedor —porque ningún distribuidor en LATAM reemplaza su parque completo de una sola vez— y el HES original no reconoce ni certifica el nuevo hardware.

El costo oculto de un HES propietario

Un HES atado a un fabricante no bloquea la operación de inmediato: bloquea la siguiente decisión de compra. Cada oleada adicional queda condicionada a negociar con el mismo proveedor, sin la palanca competitiva de un segundo postor, o a duplicar la inversión en una segunda plataforma de gestión de medidores que corra en paralelo con la primera. Ambas rutas presionan el capex de exactamente el proyecto que se diseñó para escalar por fases y proteger el presupuesto.

Qué exige un HES/MDM agnóstico al fabricante

La alternativa es exigir, desde el primer contrato, que el HES/MDM certifique interoperabilidad sobre protocolos abiertos y no sobre el firmware de una sola marca. En la práctica de la industria, eso significa soporte nativo a estándares como DLMS/COSEM, wMBus, LoRaWAN y NB-IoT, de forma que medidores de generaciones y fabricantes distintos convivan en la misma red sin adaptadores a medida por cada nuevo proveedor. Es el mismo criterio detrás de plataformas comerciales como ZONOS de Cuculus, proveedor europeo de smart metering, que hoy opera más de dos millones de dispositivos en utilities de cuatro continentes precisamente sobre esa base multiprotocolo y multifabricante (AGT Consultoría, 2026). Evotech, la firma del grupo especializada en integración SAP para utilities de la región, remarca que el valor de este tipo de plataforma no está en el volumen de dispositivos que gestiona, sino en que ese volumen proviene de mezclas de fabricantes distintas conectadas al mismo backend.

Cómo blindar el contrato de la oleada 1

Tres condiciones concretas conviene incorporar antes de la firma. Primero, exigir al proveedor del HES una certificación explícita de interoperabilidad multifabricante sobre los protocolos mencionados, no una promesa genérica de “compatibilidad SAP”. Segundo, incluir en el alcance del piloto la conexión de al menos un medidor de una segunda marca, para validar en la práctica —y no solo en el papel— que la plataforma no depende del fabricante original. Tercero, confirmar cómo se resuelve la integración con Device Management de SAP IS-U: si el esquema es de dos o tres capas, quién es el maestro del dato de medición, y qué servicios estándar de AMI se usan para sincronizar esa información, evitando interfaces propietarias que solo el proveedor original sabe mantener.

Ninguna de estas condiciones exige renunciar al fabricante que ya ganó la licitación de la oleada 1. Exige, simplemente, que la plataforma que queda instalada detrás de esos medidores no sea la que decida, de facto, con quién se puede negociar en la oleada 2.

Antes de firmar

La lección de esta pieza es puntual: el primer contrato de medidores no solo compra hardware, compra —o hipoteca— la flexibilidad de las siguientes tres oleadas. Verificar la interoperabilidad del HES/MDM antes de firmar cuesta una revisión técnica adicional en la etapa de contratación. No verificarla puede costar, oleadas después, una renegociación en desventaja o una segunda plataforma paralela. El siguiente artículo de esta serie aborda cómo gobernar esas oleadas 2, 3 y 4 sin perder el hilo del negocio una vez que la decisión de plataforma ya está tomada.

Fuentes

• AGT Consultoría (2026). Página de soluciones Cuculus ZONOS — smart metering IoT integrado con SAP IS-U.
• SAP Community (2017). Blog técnico sobre arquitecturas de Meter Data Management con SAP: esquemas de dos y tres capas, servicios empresariales de AMI y rol de MDUS.
• SAP Learning (2026). Curso “Configuring Device Management in SAP S/4HANA Utilities” — funciones de negocio de Advanced Metering Infrastructure y sincronización MDUS.