Tu SCADA ya detectó la falla: por qué no llega a mantenimiento SAP
Las señales de salud del activo viven en SCADA y el mantenimiento en SAP. Por qué la alarma no se vuelve orden en plantas de gas de LATAM.
En una planta de compresión de gas, el rodamiento de un compresor rara vez falla de un día para otro. Durante semanas deja rastro: sube la vibración, se desplaza la temperatura del cojinete y el historiador lo registra todo. El problema no es que nadie lo haya medido; es que esa señal nunca se convirtió en una orden de trabajo.
Esa paradoja abre esta serie. Las máquinas ya hablan: acelerómetros, sondas de temperatura, los PLC de cada línea y el SCADA de la sala de control transmiten de forma continua información sobre la salud del activo (OxMaint, 2026). Pero esos datos viven en el mundo de la tecnología operativa (OT), mientras el sistema de mantenimiento SAP vive en el de la tecnología de información (IT), y ambos rara vez se encuentran (OxMaint, 2026). Muchos jefes de mantenimiento de la región reconocerán el resultado: un rodamiento puede pasar semanas acercándose a la falla dentro del historiador mientras SAP sigue programando preventivos por calendario que no lo detectan (OxMaint, 2026).
La señal existe; la orden no
Para un ejecutivo de una operación de gas en América Latina, la pregunta incómoda no es si la planta tiene instrumentación. Muchas plantas de generación y compresión de la región operan con un SCADA maduro, fruto de años de inversión en sensores, comunicaciones y pantallas. La pregunta es qué pasa cuando una variable crítica cruza su umbral: ¿llega esa información al sistema donde se planifica, se presupuesta y se ejecuta el mantenimiento?
En muchas instalaciones, la respuesta honesta es «depende de quién estaba mirando». La alarma aparece en la HMI y el operador de turno la reconoce; quizás la anota en la bitácora o la comenta por radio. Que termine como un aviso en SAP o se quede donde nació depende de que alguien la lleve a tiempo al planificador.
---
config:
theme: base
fontFamily: 'Inter Variable, system-ui, sans-serif'
themeVariables:
darkMode: true
fontFamily: 'Inter Variable, system-ui, sans-serif'
fontSize: '15px'
background: '#111113'
primaryColor: '#1A1A1D'
primaryTextColor: '#F4F5F8'
primaryBorderColor: '#8B5CF6'
secondaryColor: '#242428'
tertiaryColor: '#1A1A1D'
mainBkg: '#1A1A1D'
secondBkg: '#242428'
tertiaryBkg: '#2E2E33'
lineColor: '#8B5CF6'
textColor: '#F4F5F8'
titleColor: '#F4F5F8'
nodeBorder: '#8B5CF6'
clusterBkg: '#1A1A1D'
clusterBorder: '#2E2E33'
edgeLabelBackground: '#242428'
pie1: '#8B5CF6'
pie2: '#f59e0b'
pie3: '#22c55e'
pie4: '#b495f9'
pie5: '#f97316'
pie6: '#ef4444'
pieTitleTextColor: '#F4F5F8'
pieSectionTextColor: '#F4F5F8'
pieLegendTextColor: '#F4F5F8'
pieStrokeColor: '#111113'
pieOuterStrokeColor: '#111113'
---
flowchart TD
A([Una variable crítica cruza su umbral]) --> B[La alarma aparece en la HMI]
B --> C[El operador de turno la reconoce]
C --> D{¿Alguien la traslada a tiempo al planificador?}
D -->|Sí| E([Se crea un aviso en SAP])
D -->|No| F([La información se queda donde nació])
class A inicio
class D decision
class B,C proceso
class E bueno
class F malo
classDef inicio fill:#30274d,stroke:#8B5CF6,color:#ffffff
classDef decision fill:#473519,stroke:#f59e0b,color:#ffffff
classDef proceso fill:#33363c,stroke:#9aa0aa,color:#ffffff
classDef bueno fill:#193e2b,stroke:#22c55e,color:#ffffff
classDef malo fill:#462226,stroke:#ef4444,color:#ffffff
Nada de esto es una falla tecnológica de alguno de los dos sistemas: ambos hacen bien su trabajo. Lo que falla es el tramo entre ellos.
Dos mundos con relojes distintos
Para entender por qué la brecha persiste conviene mirar cómo está organizada una planta. El estándar internacional ISA-95 describe la empresa industrial en cinco niveles (ISA, 2026). Para este problema importan tres: el nivel 2, con los PLC y los sistemas de control distribuido; el nivel 3, con sistemas como MES y SCADA que gestionan las operaciones; y el nivel 4, el de la gestión del negocio, donde se ubica el ERP (ISA, 2026).
La diferencia no es solo de software: cada mundo cuida algo distinto y describe la planta con objetos distintos. OT prioriza la continuidad del proceso y la seguridad de las personas, con datos en tiempo real, de alta frecuencia y en formatos propios de cada fabricante. IT prioriza la trazabilidad, el costo, el inventario y la planificación, y razona en equipos, ubicaciones técnicas, avisos y órdenes. Por eso una lectura de vibración, por sí misma, no se convierte en un aviso ni en una orden: alguien tiene que definir cómo llega a SAP y qué debe disparar allí.
ISA-95 nació justamente para dar a ambos equipos un lenguaje común: entre sus propósitos está ayudar al personal de manufactura y al de IT a colaborar definiendo términos clave para los proyectos de integración (ISA, 2026). Que el estándar exista desde hace décadas y la brecha siga abierta en tantas plantas revela que el problema no es de conocimiento, sino de prioridad y de diseño.
Cómo se ve la brecha en una planta de gas de la región
En una estación de compresión o en una planta de generación a gas en LATAM, la brecha suele dejar estas huellas: alarmas de condición que se gestionan y se cierran en el SCADA sin dejar rastro en el historial del equipo en SAP; un plan preventivo construido sobre frecuencias fijas aunque la planta tenga datos de condición disponibles; fallas imprevistas registradas en SAP como correctivos, sin vínculo con las señales que las anticiparon; y operación y mantenimiento discutiendo sobre los mismos activos con datos distintos, cada uno desde su sistema.
En una región donde la continuidad operativa pesa directamente sobre los compromisos de suministro y los presupuestos de modernización son acotados, este desencuentro tiene un costo que rara vez aparece en un solo reporte: horas de parada no planificada, repuestos comprados de urgencia y técnicos que llegan a reparar lo que se pudo intervenir antes.
Por qué más sensores no lo resuelven
Ante una falla que «se pudo ver venir», la reacción habitual es invertir en más instrumentación o en un nuevo tablero de monitoreo. Pero monitorear sin integrar produce, sobre todo, tableros que nadie atiende con la rapidez necesaria (OxMaint, 2026). Una alarma de vibración en el SCADA no cambia nada si no llega al planificador de mantenimiento como una orden de trabajo con el activo, la prioridad y los repuestos correctos (OxMaint, 2026).
Ese último tramo, el que va de la señal o la predicción a una orden real en SAP, es donde suelen estancarse los proyectos de monitoreo y, a la vez, donde está el valor (OxMaint, 2026). Para una planta con SCADA maduro, la buena noticia es que el punto de partida ya existe: los PLC, el SCADA y los historiadores actuales pueden conectarse mediante protocolos estándar, sin reemplazar la instrumentación (OxMaint, 2026). El desafío no es medir más, sino decidir qué señales merecen convertirse en una acción de mantenimiento y cómo llegan a SAP con el contexto correcto.
Lo que esta serie va a recorrer
En Consultoría Venezuela, especializados en IS-U y en el sector utilities y oil & gas, vemos esta brecha con frecuencia en operaciones de la región que ya tienen las dos piezas, un SCADA confiable y un SAP productivo, pero no el puente entre ellas. Esta serie de seis artículos la recorre por etapas, desde el diagnóstico hasta las decisiones de diseño necesarias para que una alarma relevante termine, de forma trazable, en una acción de mantenimiento.
La serie se apoya en lo que ya publicamos sobre gestión de activos en SAP. Si la señal del SCADA va a terminar en una orden, primero tiene que encontrar el activo correcto, con su criticidad y su ubicación, y un flujo que lleve esa orden hasta el campo:
| Artículo | Qué aporta a esta serie |
|---|---|
| Ubicación técnica vs. equipo en SAP: por qué tu jerarquía falla | La estructura del maestro de activos donde debe quedar registrado lo que detecta el SCADA. |
| Criticidad sin criterio: por qué todos tus activos pesan igual | Cómo priorizar el mantenimiento con criterio; sin esa base, todas las alarmas parecen igual de urgentes. |
| Taxonomía de activos: de proyecto a gobierno continuo en S/4HANA | La disciplina que mantiene vigente el maestro de activos después del proyecto. |
| Del defecto en campo a la orden sobre el tramo exacto en SAP | Cómo un hallazgo se convierte en aviso, orden y operación sobre el activo lineal correcto. |
| Crear la orden de mantenimiento desde el mapa con SAP GEF | El planificador ubica el activo en el mapa y crea la orden en SAP PM antes de despachar. |
| Orden de servicio a llamada de campo: cómo replica S/4HANA a FSM | Qué pasa con la orden una vez liberada: cómo llega al técnico en SAP Field Service Management. |
| IA embebida en SAP: no se construye, se activa y se gobierna | El mantenimiento predictivo como capacidad que ya viene en las apps SAP y que hay que activar y gobernar. |
Esta primera pieza sitúa el problema: la información ya existe, pero vive en un mundo distinto al de quien debe actuar sobre ella. En la próxima entrega veremos por qué monitorear no es lo mismo que actuar, y por qué un dashboard sin conexión al mantenimiento no cambia nada.
Fuentes
- OxMaint (2026). SAP IoT Integration for Predictive Maintenance: Connecting Sensors, PLCs, and SAP PM. https://oxmaint.com/sap-integration/sap-iot-integration-predictive-maintenance
- International Society of Automation – ISA (2026). ISA-95 Series of Standards: Enterprise-Control System Integration. https://www.isa.org/standards-and-publications/isa-standards/isa-95-standard
Artículo de Edward Camacho Guerra, elaborado con apoyo de herramientas de inteligencia artificial y revisado y aprobado por el autor.
¿Este análisis describe un mercado donde ya opera o que está evaluando?
Revisamos su caso, mapeamos los riesgos que aplican y le decimos con franqueza si es una oportunidad para usted —sin presentación comercial, solo una conversación técnica y estratégica.
