HES, MDM y SAP IS-U: las tres capas antes de facturar
Antes de prometer facturación automática en un piloto AMI, hay que distribuir responsabilidades entre HES, MDM y SAP IS-U Device Management. Así se reparte el trabajo.
· 6 min de lectura
La pregunta que casi nunca queda por escrito en un proyecto de integración AMI no es qué protocolo usa el concentrador: es quién certifica que un dato de medición es correcto antes de que cruce hacia SAP IS-U. Sin esa respuesta explícita, el proyecto avanza a ciegas — y el presupuesto tampoco lo contempló.
Tres capas, tres responsabilidades
La forma más clara de exponerlo es como una jerarquía de tres niveles, donde cada capa entrega un objeto distinto a la siguiente: el HES, el MDM y SAP IS-U Device Management.
El HES es la capa de campo: habla el idioma del concentrador y del medidor, y su responsabilidad termina cuando entrega un flujo de eventos crudo, con marca de tiempo de origen, hacia arriba. Según la documentación de Cuculus, el MDM recibe, valida y procesa los datos del medidor y los comparte con los sistemas de facturación, integrándose con el Head-End System para habilitar procesos de smart metering de extremo a extremo (Cuculus, 2023). Esa es precisamente la función bisagra: el MDM no reemplaza al HES ni a SAP IS-U — arbitra entre ambos, aplicando reglas de validación (VEE: validation, estimation, editing) antes de que un solo registro cruce hacia el ERP.
SAP IS-U Device Management, por su parte, no está diseñado para absorber telemetría cruda de campo. Su rol es gobernar el maestro técnico del dispositivo — instalación, remoción, reemplazo, agrupación de registros — y recibir datos de medición ya depurados para alimentar los procesos de facturación y gestión comercial. Cuando un equipo de proyecto intenta que SAP IS-U “reciba directo” del HES, sin capa de MDM en el medio, está pidiéndole a la capa de gobierno de activos que haga el trabajo de validación de datos de campo. Ahí es donde aparecen las lecturas duplicadas y los desbalances entre Comercial y Facturación.
Qué pasa cuando nadie define esa frontera
Es habitual que, al evaluar un Head-End System (HES) para AMI, la conversación se quede en la capa de comunicaciones: protocolo, concentrador, frecuencia de sondeo. Eso resuelve cómo llega el dato del medidor a la red de la utility. Pero no resuelve qué sistema es responsable de qué una vez que el dato llegó. Y en un flujo Meter-to-Cash (M2C), esa ambigüedad se paga cara: lecturas duplicadas que desbalancean Comercial y Facturación, eventos sin timestamp normalizado que rompen procesos posteriores, o una secuencia de transmisión inconsistente que hace perder el orden de los eventos antes de que lleguen a integración.
Ninguno de esos problemas se origina en el medidor. Se originan en la frontera entre capas — en la zona gris donde cada sistema asume que “eso lo hace el otro”.
Qué significa esto para un piloto AMI en LATAM
Para una distribuidora eléctrica que está evaluando o ya ejecutando un piloto AMI, esta distribución de responsabilidades tiene una traducción práctica: el criterio de selección de un HES o de un MDM no puede limitarse a la cobertura de protocolo de comunicación. Esto importa aún más en una región donde la madurez AMI todavía es incipiente: la penetración de medidores eléctricos inteligentes en América Latina y el Caribe se ubicaba apenas en 7,7% en 2024, con una proyección de crecimiento hasta 24,8% para 2030 (Berg Insight, 2026), lo que significa que buena parte de las utilities de la región está definiendo estas arquitecturas de integración por primera vez, sin un precedente interno al cual recurrir. Hay que preguntar, con la misma prioridad que el protocolo de comunicación, cómo maneja cada capa la alta latencia de concentradores en zonas de cobertura irregular, cómo normaliza eventos sin timestamp consistente y cómo prioriza eventos críticos de medición — corte, reconexión, lectura — frente al tráfico masivo de lecturas rutinarias. Un patrón que ayuda aquí es el uso de mecanismos de desacople orientados a eventos (event-driven), como los que ofrece SAP Integration Suite, advanced event mesh, para que el volumen de tráfico AMI no golpee directamente al core de SAP IS-U y pueda amortiguarse antes de llegar a los flujos de integración.
Esta distinción de capas también importa para la gobernanza del proyecto: si el contrato con el proveedor de HES/MDM no deja explícito quién certifica la calidad del dato antes de que entre a SAP IS-U, la utility termina depurando en producción lo que debió depurarse en el MDM. Y esa depuración tardía es, casi siempre, la razón real por la que un piloto AMI “funciona técnicamente” pero no logra facturación automática.
Lo que viene
En la pieza anterior de esta serie describimos el síntoma que suele delatar esta ambigüedad: el medidor inteligente ya transmite, pero SAP IS-U sigue esperando una lectura manual para poder facturar. Repartir responsabilidades entre HES, MDM y SAP IS-U Device Management resuelve ese síntoma en condiciones normales de operación. Pero ¿qué pasa cuando el concentrador pierde la señal a mitad del ciclo de lectura? En la próxima pieza de esta serie exploramos ese evento de quiebre — y qué capa debe hacerse cargo de reconstruir la continuidad del dato.
Fuentes
- Cuculus, Datasheet MDM (2023): https://www.cuculus.com/wp-content/uploads/2023/02/Cuculus_Datasheet_MDM_EN.pdf
- Berg Insight (2026), Latin America and the Caribbean Smart Metering Research Report 2026
- SAP Help Portal, SAP Integration Suite, advanced event mesh: https://help.sap.com/docs/sap-integration-suite/advanced-event-mesh/what-is-sap-integration-suite-advanced-event-mesh
¿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.
