Evaluar al próximo proveedor AMI sin romper tu integración
Criterio de gobierno para evaluar proveedores de medición avanzada sin comprometer la arquitectura de integración hacia SAP IS-U en utilities de LATAM.
· 10 min de lectura
En las utilities de América Latina el próximo rollout de medición casi nunca llega solo: llega con un proveedor nuevo, un pliego nuevo y una promesa de interoperabilidad. La decisión se toma en la mesa de compras, con criterios de hardware, precio unitario y plazo de entrega. La factura, en cambio, se paga en la capa de integración, meses después, cuando alguien descubre que el head-end recién adquirido no expresa los mismos mensajes que el anterior y que el equipo de facturación heredó un mapeo que nadie especificó en el contrato.
En AGT acompañamos a operadores eléctricos, de agua y de gas que ya resolvieron la convivencia técnica de dos o tres fabricantes sin duplicar el dato de medición. El paso que suele quedar pendiente es el de gobierno: convertir esa arquitectura, que costó esfuerzo estabilizar, en un criterio explícito de evaluación para el siguiente proveedor. De eso trata este cierre de serie.
El pliego evalúa el medidor; la deuda se contrae en la integración
La pregunta que domina los procesos de adquisición es “¿qué medidor compramos?”. La pregunta que determina el costo total es otra: “¿qué le exige este proveedor a nuestra arquitectura de integración para que el dato llegue utilizable a SAP IS-U?”.
Ese salto importa porque la interoperabilidad no es una propiedad del medidor. Es una propiedad del contrato semántico entre el sistema de medición y el core comercial. El estándar internacional lo dice con claridad: IEC 61968-9:2024 especifica el contenido de información de un conjunto de tipos de mensaje para lectura, eventos de dispositivo, control remoto y sincronización de datos de cliente, y deja fuera de su alcance los protocolos de comunicación que cada sistema use (IEC, 2024). Traducido a la mesa de negociación: el proveedor puede tener la radio más eficiente del mercado y aun así no compartir vocabulario con lo que ya está en producción.
En el ecosistema SAP ese vocabulario tiene nombre concreto. MDUS (Meter Data Unification and Synchronization) describe los sistemas que unifican las interfaces entre distintas infraestructuras de medición avanzada y SAP, y sobre esa base operan las funciones de conexión y desconexión remota disponibles en SAP S/4HANA Utilities (SAP Learning, 2026). El adaptador de un fabricante establecido documenta más de 50 operaciones de servicio soportadas —incluidas operaciones masivas— y más de 35 casos de uso en áreas como creación y configuración de dispositivos, registros y tareas de medición, alcance que su propia ficha de producto declara sobre la base de SAP ERP EhP7 (Landis+Gyr, 2025). En un escenario S/4HANA esa matriz debe revalidarse contra la versión vigente del producto. Ese nivel de especificidad es exactamente lo que debe pedirse al candidato: no una declaración de compatibilidad, sino una lista de operaciones y casos de uso verificable contra el estándar.
Cuatro criterios de gobierno antes de firmar
1. Conformidad semántica declarada y versionada
No basta con “soporta CIM”. El criterio operable es una matriz que cruce, mensaje por mensaje, qué tipos de IEC 61968-9 emite y consume el candidato, en qué versión del estándar, y qué operaciones de servicio MDUS cubre. Lo que el proveedor no documente debe registrarse como no documentado —no como ausencia de riesgo—. Esa distinción es la que evita que el equipo de integración descubra el hueco cuando ya hay medidores instalados en campo.
2. Trazabilidad temporal del evento
Un evento de medidor sin hora normalizada no es evidencia: es una fila que alguien tendrá que defender ante el regulador. La documentación de SAP for Utilities describe una función de negocio que, al activarse junto con su switch correspondiente, permite registrar la fecha, la hora exacta y la zona horaria de la actividad física del dispositivo —instalación, retiro, reemplazo— y transferirla al sistema MDUS mediante servicios enterprise (SAP Help Portal — Utilities, Advanced Metering Infrastructure 4C). El criterio de evaluación se deriva solo: exigir al candidato que emita marca temporal con zona horaria en origen, y no que la infiera la capa de integración.
3. Comportamiento bajo carga y reproceso
La pregunta no es cuánto transmite el proveedor en condiciones nominales, sino qué hace cuando el concentrador se atrasa. Aquí la arquitectura ya tiene herramientas: la capacidad Event Mesh de SAP Integration Suite permite publicar y consumir eventos de negocio entre aplicaciones, desacoplando el flujo del core (SAP Help Portal — Event Mesh), y la propia SAP consolidó esa funcionalidad dentro de las ediciones estándar y premium de Integration Suite junto con Cloud Integration (SAP Community, 2024). Para escenarios de streaming distribuido a mayor escala existe la oferta especializada SAP Integration Suite, advanced event mesh, comercializada por separado (SAP Community, 2024). El proveedor candidato debe declarar qué garantías de entrega, reintento y orden ofrece —y qué asume que hará el buffer del lado del comprador.
4. Reversibilidad contractual
Un proveedor que no puede ser reemplazado sin rehacer la integración no es un proveedor: es una condición de la arquitectura. La cláusula que conviene negociar antes de firmar es la de salida: propiedad de los mapeos, entrega de la documentación de interfaces, y compromiso de que la misma semántica seguirá disponible si el operador decide mover el volumen a otro fabricante en el siguiente rollout.
Un tablero de resiliencia, no un informe de proyecto
El criterio de gobierno se sostiene solo si se mide de forma continua, con un tablero que siga los cuatro criterios anteriores: conformidad semántica declarada y versionada, trazabilidad temporal del evento, comportamiento bajo carga y reproceso, y reversibilidad contractual.
Cada indicador se reporta por fabricante, no agregado. El agregado esconde justamente lo que hay que ver: qué proveedor está degradando el meter-to-cash.
Qué cambia en el pliego
- Anexo técnico de interoperabilidad con la matriz de mensajes IEC 61968-9 y operaciones MDUS, firmado por el proveedor.
- Requisito explícito de marca temporal con zona horaria emitida en origen.
- Declaración de garantías de entrega, reintento y orden en la transmisión.
- Prueba de aceptación en ambiente de integración antes de la orden masiva de medidores.
- Cláusula de reversibilidad con propiedad documental de los mapeos.
En AGT ayudamos a traducir estos criterios en anexos contractuales y tableros operativos, para que el próximo proveedor entre por la puerta que la arquitectura ya tiene abierta —y no por una que haya que abrir a golpes.
Fuentes
- IEC. IEC 61968-9:2024 — Enterprise business function interfaces for utility operations, Part 9: Interfaces for meter reading and control. https://webstore.iec.ch/en/publication/75041
- Landis+Gyr. MDUS — SAP for Utilities Adaptor. https://www.landisgyr.com/product/mdus-sap-for-utilities-adaptor/
- SAP Help Portal. Utilities, Advanced Metering Infrastructure 4C. https://help.sap.com/doc/c369ce53118d4308e10000000a174cb4/3.6/en-US/eff6d4525af74a4ee10000000a423f68.html
- SAP Learning. Understanding Advanced Meter Infrastructure — Configuring Device Management in SAP S/4HANA Utilities. https://learning.sap.com/courses/configuring-device-management-in-sap-s-4hana-utilities/understanding-advanced-meter-infrastructure
- SAP Help Portal. Event Mesh — SAP Integration Suite. https://help.sap.com/docs/integration-suite/sap-integration-suite/event-mesh
- SAP Community. SAP Integration Suite, advanced event mesh vis-à-vis SAP Event Mesh and SAP Integration Suite. https://community.sap.com/t5/technology-blog-posts-by-sap/sap-integration-suite-advanced-event-mesh-vis-%C3%A0-vis-sap-event-mesh-and-sap/ba-p/13531535
¿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.
