En planta, la decisión API / RPA / IoT se toma mal por dos atajos. El primero: vender RPA para todo porque “en dos semanas ya mueve la pantalla del ERP”. El segundo: comprar sensores y un dashboard 4.0 sin nadie que reciba la alerta, calibre el dispositivo o pague el mantenimiento a los 18 meses.
Ninguna de las tres capas es “la automatización”. Son herramientas. Elegir la equivocada no se nota en el piloto: se nota cuando cambia una transacción de SAP, cuando el robot de UI se cae cada release, o cuando el sensor sigue midiendo y nadie abre la orden de trabajo.
Este texto es la tabla de decisión que el post de automatización industrial deja en un párrafo: cuándo cada capa, cómo se combinan y qué se rompe si las usas al revés.
Definición por capa (con un uso de planta)
API. Un contrato de datos entre sistemas. El piso no “escribe en SAP a mano”: una app o un servicio manda existencias, cierre de OT o no-conformidad por interfaz documentada. Ejemplo: el operador confirma un conteo cíclico en tablet; el ERP recibe el movimiento con lote, almacén y usuario — sin teclear la transacción MM.
RPA. Un robot que opera la interfaz que un humano ya usa (clics, copiar/pegar, capturas). Sirve cuando el sistema no expone API confiable y el flujo es repetitivo y estable. Ejemplo: cada noche, un bot entra al módulo legacy de calidad, baja el lote rechazado y lo deja en una cola que sí habla con el ERP. No es integración: es un humano de software con horario.
IoT. Una señal de máquina (parada, temperatura, vibración, consumo) que no nace en un formulario. Ejemplo: un sensor en un motor crítico dispara “fuera de umbral”; eso no reemplaza al ERP — debería crear o enriquecer una OT para que mantenimiento actúe. Sin ese puente, es un semáforo bonito.
Tabla de decisión
| Pregunta | API | RPA | IoT |
|---|---|---|---|
| ¿Los datos ya están estructurados? | Sí: maestros, movimientos, estados de OT. | Aceptable si la pantalla es predecible, aunque el dato viva en el form. | No: es una señal física. Hay que modelarla (tag, umbral, unidad). |
| ¿Hay dueño de OT designado? | No es requisito para el primer módulo de captura. | Tampoco: es software sobre UI. | Sí, o no arranques. Sensor sin dueño es deuda en el rack. |
| ¿Proceso humano repetitivo o señal de máquina? | Humano o sistema → sistema (pedido, inventario, calidad). | Humano → pantalla. | Máquina → evento. |
| ¿Qué tan seguido cambia el proceso? | Aguanta cambios de negocio si el contrato de datos se versiona. | Se rompe cuando mueve un botón, un label o un timeout. | Se rompe cuando cambia el activo, el umbral o el protocolo — no la UI. |
No es elegir una: es combinarlas
Casi ningún flujo real de planta es “puro”. La captura vive en API, el hoyo del legacy se tapa con RPA, y la condición de máquina entra por IoT. Tratarlas como proyectos rivales (el de TI vs el de “industria 4.0”) es cómo terminas con tres islas y el Excel sigue mandando.
Conviven así: el evento (IoT o el operador) dispara un hecho; la capa de negocio lo valida y lo escribe donde es sistema de registro (API al ERP); si un eslabón no tiene interfaz, un robot cubre ese hueco — no todo el proceso.
Riesgos por capa
- RPA donde debería ir API. Cada cambio de UI (upgrade de SAP GUI, un campo nuevo, un pop-up de autorización) tumba el bot. El ahorro del primer mes se paga en babysitting. Úsalo como puente con fecha de caducidad, no como arquitectura.
- IoT sin dueño de OT. Sensores que miden, dashboards que se ven en la visita del proveedor, y a los seis meses nadie calibra ni atiende la alarma. La planta aprende a ignorar el semáforo. IoT sin OT es teatro.
- API mal diseñada como excusa para no tocar el ERP. Un endpoint que “ya inserta” sin validar lote, centro o bloqueo de crédito solo acelera basura. La API no sustituye dueño de datos maestros ni ambientes de prueba. Si el ERP es el registro, el contrato tiene que doler un poco en discovery — si no, estás pintando encima.
Cómo conviven las tres capas en un flujo
Planta mediana, ERP vivo, calidad todavía en un sistema de los 2000 sin API decente, y un activo crítico que se cae sin aviso.
- Piso (API): el operador cierra la OT de mantenimiento en app; SAP recibe estado, tiempo y refacciones.
- Hueco legacy (RPA): el dictamen de calidad de ese mismo lote no sale por interfaz; un bot, en ventana controlada, copia el resultado al repositorio que sí alimenta al ERP. Alcance: esa transacción, con log y alarma si la pantalla cambia.
- Máquina (IoT): vibración fuera de umbral en el motor abre (o prioriza) la OT que el operador cerrará después. Mantenimiento es dueño del tag y del umbral.
Una sola historia de “orden + calidad + condición”. Tres capas. Si empiezas por los sensores y dejas calidad en papel, el IoT no tiene a quién avisarle. Si automatizas toda la calidad con RPA “porque ya está”, el siguiente upgrade del módulo te apaga el cierre de lote.
La capa correcta es la más aburrida que deje traza en el ERP. Lo vistoso se agrega cuando esa traza ya existe.
Bridge Studio
Preguntas frecuentes
Respuestas directas para cotizar, decidir stack o validar si conviene construir.
La API intercambia datos con un contrato (campos, errores, autenticación). El RPA imita clics en una pantalla. La primera sobrevive cambios de UI; la segunda depende de que la pantalla no se mueva. En planta, API es el destino; RPA es el puente cuando el destino aún no existe.
Cuando el dato no nace en un humano (parada, consumo, condición) y hay un dueño de OT que va a actuar la señal. Si el dolor es papel, WhatsApp o Excel, digitaliza el flujo e intégralo al ERP primero. Un sensor no arregla un inventario que nadie cuenta.
En integraciones de planta, casi siempre temporal o acotada: un sistema sin API, un reporte nocturno, un volumen que no justifica el conector todavía. Definitiva solo si el vendor nunca va a abrir interfaz y el proceso está congelado. Trátalo como deuda visible, con dueño y criterio de retiro.
No es un no. Se evalúa IDoc, BAPI, middleware, archivo controlado o, si no hay otra, RPA sobre un recorte mínimo del flujo. Lo que no hacemos es fingir que un bot es “la integración SAP”. El primer release define el contrato de datos aunque la tubería sea fea.
Operaciones / mantenimiento de planta, no el vendor del sensor ni un dashboard de TI huérfano. TI puede operar la plataforma; el umbral, el activo y la respuesta a la alarma son de OT. Sin ese nombre en el organigrama, el proyecto de IoT no debería pasar de piloto.
RPA suele ser lo más rápido de parar en un flujo chico… y lo más lento de mantener. API tarda más en el arranque (dueños de ERP, ambientes, contrato de datos) y es la que menos se reescribe. IoT no es “poner el sensor”: es cableado, umbrales, OT y hypercare; casi siempre la cola más larga si no hay madurez de planta. El orden de llegada no es el orden de valor: a veces el módulo de inventario por API mueve más que tres meses de tags.
