Un fabricante AMI, un proyecto repetido: el lock-in en SAP IS-U
Integrar la medición avanzada pensando en un solo proveedor AMI crea lock-in en SAP IS-U. Cómo el modelo MDUS y las capacidades evitan repetir el proyecto.
· 12 min de lectura
Hay una asimetría poco discutida en los proyectos de medición avanzada de la región: la arquitectura de referencia que SAP documenta es multi-fabricante por diseño, y la integración que se construye encima suele ser de un solo fabricante por omisión. MDUS —Meter Data Unification and Synchronization— describe sistemas que unen las interfaces entre diferentes sistemas de medición avanzada y sincronizan los datos y procesos de esos sistemas con los del back-office; la comunicación entre las aplicaciones SAP y el sistema MDUS se realiza mediante enterprise services (SAP Learning, 2026). El plural no es decorativo.
Es decir: el lock-in de medición no lo impone SAP. Lo escribe el proyecto. Y se cobra cuando llega el segundo proveedor.
SAP no modela fabricantes: modela capacidades
Vale la pena releer cómo la propia documentación de SAP plantea la arquitectura, porque contradice la práctica habitual del proyecto punto a punto.
La idea decisiva para gobernar un parque mixto es esta: los procesos de SAP Utilities solo se pueden ejecutar completos si las capacidades requeridas están soportadas tanto por el sistema de medición avanzada como por el dispositivo (SAP Learning, 2026). SAP no pregunta de qué marca es el medidor. Pregunta qué sabe hacer. Los enterprise services asociados a SAP AMI Integration for Utilities están documentados en la nota SAP 1754249, referida explícitamente a la integración con sistemas MDUS (SAP Note 1754249).
Cuando la integración se diseña alrededor de capacidades y no de proveedores, agregar un fabricante deja de ser un proyecto y pasa a ser una configuración. Cuando se diseña alrededor de un head-end concreto, ocurre lo contrario: cada fabricante nuevo reabre el proyecto entero.
La primera oleada escribe las reglas de todas las demás
Una distribuidora eléctrica en América Latina rara vez despliega medición avanzada de un solo golpe. Despliega por oleadas: un piloto en un circuito urbano, una licitación para decenas de miles de puntos, otra tres o cuatro años después para grandes clientes, y una más cuando el regulador aprieta o cuando las pérdidas no técnicas dejan de ser tolerables. Cada oleada abre su propio proceso de compra. Y cada proceso de compra puede traer un fabricante distinto.
Cuando el alcance del proyecto se define como “integrar el AMI con SAP”, el equipo hace lo razonable: toma la documentación del head-end ya contratado, mapea sus mensajes contra los objetos de Device Management e IS-U, y entrega. El resultado funciona. Se factura, se corta, se reconecta. Nadie tiene motivo para cuestionarlo.
La factura llega con el segundo fabricante. Y no llega como una línea de “integración”: llega como reapertura de decisiones que se creían cerradas. El modelo de datos de la lectura, el tratamiento del timestamp, la política de reintentos, el criterio de qué evento es crítico y cuál puede esperar. Todo eso quedó escrito en la lógica del primer proveedor, no en un contrato propio de la utility. Sin que nadie lo decida formalmente, la integración de la primera oleada se convierte en la arquitectura de medición de toda la empresa.
Qué queda atado cuando la integración se escribe para un solo AMI
El lock-in de medición avanzada no es contractual. Es semántico y operativo. Se manifiesta en cuatro capas que rara vez se auditan juntas:
- El contrato de mensajes. El formato del proveedor se vuelve el formato de la empresa. Cuando entra un segundo head-end, no hay un modelo canónico contra el cual mapearlo: hay un modelo ajeno que hay que imitar.
- La semántica del evento. Eventos de medidores sin timestamp normalizado rompen los flujos aguas abajo. Si el primer fabricante entregaba hora local y el segundo entrega UTC con otra convención de fin de intervalo, el desalineamiento no falla con error: factura mal.
- La lógica de negocio incrustada en el mapeo. Prioridades de corte, reconexión y lectura quedan codificadas dentro del flujo del proveedor en lugar de vivir en una capa de orquestación propia.
- La operación. Tiempos de transmisión inconsistentes y alta latencia en concentradores producen pérdida de secuencia y congestión en los integration flows. El monitoreo que se construyó para el comportamiento de un solo AMI no reconoce el patrón del otro.
El síntoma más caro es conocido en cualquier área de Comercial y Facturación: lecturas duplicadas que generan desbalance en el ciclo Meter-to-Cash. No es un problema de medidores. Es un problema de que dos sistemas de medición escriben sobre el mismo objeto sin un árbitro común — exactamente el rol que la arquitectura documentada reserva para la capa MDUS.
La segunda oleada no es hipotética: es aritmética regional
El contexto de LATAM hace que este riesgo sea casi universal. La penetración de medidores eléctricos inteligentes en América Latina y el Caribe alcanzó 9,7 % en 2025, y se proyecta que el parque instalado crezca con una tasa compuesta anual de 22,7 % entre 2025 y 2030, pasando de unos 22,1 millones a 61,3 millones de unidades (Berg Insight, 2026). La región suma más de 223 millones de clientes eléctricos, y las altas pérdidas no técnicas siguen siendo un motor central de la inversión en medición (Berg Insight, 2026).
Traducido a lenguaje de arquitectura: la enorme mayoría de las utilities de la región está al inicio de la curva. Prácticamente ninguna integración AMI que se construya hoy va a ser la última. Va a ser extendida.
La paradoja es que la capa física está más estandarizada que la capa de integración que se construye encima. DLMS/COSEM se usa en más del 65 % de los medidores inteligentes del mundo, excluyendo China, con más de 2.300 productos certificados desplegados (Itron, 2025). El medidor habla un idioma común; el proyecto de integración suele inventar uno propio por cada proveedor.
Las decisiones que se toman hoy y se cobran en tres años
No hace falta esperar al segundo fabricante para protegerse de él. Hay un orden de diseño que mantiene abierta la puerta:
SAP Integration Suite ofrece las piezas para sostener ese esquema: Cloud Integration aporta mapeo y transformación para convertir la estructura de origen a la de destino, y API Management habilita el acceso seguro a las APIs involucradas (SAP, 2026). El advanced event mesh permite comunicación asíncrona en tiempo real entre aplicaciones SAP y de terceros a través de entornos híbridos y multi-nube, con filtrado dinámico de eventos (SAP, 2026). Un buffer resiliente para colas AMI de alto tráfico y una priorización explícita de eventos críticos —corte, reconexión, lectura— completan el patrón.
En AGT acompañamos a operadores de utilities y oil & gas de la región a auditar exactamente este punto antes de la siguiente licitación: dónde vive hoy la semántica de la medición y cuánto costaría que viviera en un modelo propio. La respuesta suele ser incómoda y, casi siempre, corregible.
En la próxima entrega de esta serie entramos de lleno en la pieza que sostiene el esquema: qué es exactamente la Meter Data Unification & Synchronization y qué problema de fondo resuelve.
Fuentes
- SAP Learning — Configuring Device Management in SAP S/4HANA Utilities: Understanding Advanced Meter Infrastructure (2026).
- SAP Note 1754249 — Frequently Asked Questions about AMI Integration with MDUS systems.
- Berg Insight — Smart Metering in Latin America and the Caribbean (2026), vía cobertura sectorial.
- Itron — DLMS/COSEM Explained: The Backbone of Interoperability for Modern Utilities (2025).
- SAP — SAP Integration Suite: Advanced Event Mesh y documentación de capacidades de Cloud Integration y API Management (2026).
¿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.
