Cómo conectar cámaras, ERP y sensores en un solo flujo operativo
Guía práctica de integración: por qué una alerta aislada no sirve, cómo correlacionar eventos de sistemas que no se hablan y qué construir primero.
La mayoría de las plantas y almacenes ya tienen todo lo que necesitan para detectar sus problemas. Tienen cámaras, tienen un ERP, tienen sensores, tienen control de accesos. Lo que no tienen es algo que relacione lo que cada uno ve.
El resultado es una operación llena de datos y vacía de contexto: la cámara detecta movimiento pero no sabe si hay una recepción programada; el ERP sabe que hay una recepción programada pero no sabe si llegó; el sensor de la puerta sabe que se abrió pero no sabe quién.
Por qué una alerta aislada casi nunca sirve
Una alerta sin contexto le transfiere el trabajo a una persona. “Movimiento detectado en muelle 3” obliga a alguien a abrir otras tres pantallas para decidir si eso importa. Después de la vigésima alerta irrelevante, esa persona deja de mirarlas — y ahí el sistema de detección se volvió decorativo.
El valor no está en detectar. Está en descartar. Un sistema útil es el que recibe cien señales y te muestra las tres que requieren atención, con el contexto ya adjunto.
Las tres capas de una integración operativa
Capa 1: entrada — hablar el idioma de cada sistema
Cada fuente expone su información de una manera distinta y hay que aceptarlo:
| Fuente | Cómo se conecta normalmente |
|---|---|
| Cámaras IP | RTSP / ONVIF, o el SDK del fabricante |
| ERP / WMS | API REST, base de datos, o exportación programada |
| Sensores / PLC | MQTT, Modbus, OPC-UA |
| Control de accesos | Webhook o consulta a su base |
| Correo | IMAP o webhook del proveedor |
La trampa acá es intentar unificar todo en un formato perfecto antes de construir nada. No hace falta. Lo que hace falta es que cada evento, venga de donde venga, llegue con tres cosas: qué pasó, cuándo, y dónde. Con esos tres campos ya se puede correlacionar.
Capa 2: correlación — donde aparece el valor
Correlacionar es preguntarle a los otros sistemas qué sabían ellos en ese mismo momento y lugar.
Volviendo al muelle 3:
- La cámara reporta movimiento, 02:13, muelle 3.
- Se le pregunta al ERP: ¿hay recepción programada para muelle 3 a esta hora? → No.
- Se le pregunta al control de accesos: ¿alguien pasó por esa puerta en los últimos 10 minutos? → No.
- Se consulta el histórico: ¿es normal que haya movimiento ahí a esta hora? → No, es la primera vez este mes.
Recién ahora el evento significa algo. Ninguno de los cuatro sistemas por separado podía llegar a esa conclusión, y ninguno necesitó ser reemplazado.
La clave técnica es tener una ventana temporal y un identificador de ubicación comunes. Si la cámara dice “cam-03” y el ERP dice “muelle 3”, alguien tiene que mantener esa equivalencia. Es trabajo aburrido y es exactamente lo que hace que el sistema funcione.
Capa 3: acción — cerrar el ciclo
Una correlación que termina en un dashboard sigue dependiendo de que alguien mire el dashboard. El flujo tiene que terminar en algo que ocurra solo: abrir un ticket, notificar al turno correcto, escribir en el ERP, encender una señal en piso.
Y si esa acción es irreversible, ponerle aprobación humana antes. Ese es un tema en sí mismo: lo desarrollamos en Human in the loop.
Qué construir primero
El error clásico es arrancar por el mapa completo de integraciones. Toma meses y no produce nada utilizable hasta el final.
Un orden que sí funciona:
- Elige un evento, uno solo. El que más tiempo le quita a alguien hoy.
- Conecta las dos fuentes mínimas para darle contexto. Dos, no ocho.
- Define la acción final y quién la aprueba.
- Ponlo a correr en modo observación, sin ejecutar la acción, durante unas semanas. Vas a descubrir que la mitad de tus supuestos sobre la operación estaban mal, y es mucho más barato descubrirlo así.
- Activa la ejecución cuando los falsos positivos estén en un nivel que el equipo tolere.
Ese ciclo completo, sobre un solo caso, enseña más sobre la operación que cualquier levantamiento de requerimientos. Y deja infraestructura reutilizable: la segunda integración cuesta una fracción de la primera.
Lo que no hay que hacer
- Reemplazar sistemas que funcionan. Si el ERP anda, no se toca. Se le conecta algo encima.
- Centralizar todos los datos primero. No necesitas un data lake para correlacionar dos eventos.
- Automatizar la acción antes de confiar en la detección. Modo observación primero, siempre.
- Ignorar la latencia. Un evento de seguridad que llega ocho minutos tarde no es un evento de seguridad, es un reporte.
Si tienes un evento operativo que hoy obliga a alguien a revisar tres pantallas, cuéntanoslo y vemos qué se necesita para cerrarlo.