Tus sensores ven mucho. Un caudalímetro mide el consumo cada minuto. Un contacto de puerta sabe cuándo se abrió un congelador. Un motor reporta vibraciones que se salen de rango antes de fallar. Todo eso es real, y la mayor parte nunca llega a los sistemas con los que de verdad opera tu negocio. La facturación ocurre en un ERP. El historial del cliente vive en un CRM. El ticket de servicio lo abre una persona que se entera del problema horas después de que el dispositivo ya lo sabía.
El trabajo consiste en cerrar ese ciclo. Cuando un sensor detecta algo, el negocio debería actuar: una lectura de consumo se convierte en una línea de factura, una falla se convierte en un ticket, la lectura de un activo actualiza el registro que revisa tu equipo de cuentas. Este artículo cubre los patrones para conectar los datos de los dispositivos con sistemas ERP y CRM, las partes que te dan problemas si las saltas, y cómo hacerlo en TagoIO con la REST API, los scripts de Analysis y las acciones de webhook.
Por qué conectar los datos de los dispositivos con los sistemas de negocio
Los datos de un dispositivo, por sí solos, son monitoreo. Conectados a un sistema de negocio, se convierten en acción.
Algunos ejemplos dejan claro el valor:
- Un medidor de servicios reporta el consumo acumulado. Enviado al ERP en un ciclo de facturación, se convierte en una factura precisa sin lecturas manuales.
- Una máquina arroja un código de falla. Enviado al CRM o a un módulo de servicio en campo, abre un ticket y asigna un técnico antes de que el cliente llame.
- Las horas de operación de un activo cruzan un umbral. El registro del activo se actualiza, y un contrato de mantenimiento se dispara en el momento previsto.
- Una instalación de alto valor se queda en silencio. El responsable comercial de esa cuenta recibe una notificación, en lugar de enterarse en la siguiente revisión trimestral.
En cada caso, el dispositivo ya lo sabía. El problema era llevar esa señal al sistema donde alguien pudiera hacer algo al respecto.
Los patrones de integración
Hay un puñado de patrones a los que recurrirás, y la mayoría de las integraciones reales combinan dos o tres de ellos.
Webhooks. La plataforma de dispositivos envía datos a una URL cuando ocurre algo. Es la opción por defecto para los eventos: una falla, el cruce de un umbral, un cambio de estado. El sistema receptor recibe la carga útil en el momento en que importa, y no estás haciendo polling.
REST APIs. La cara opuesta de la misma moneda: el lado de extracción. Tu ERP o CRM, o un script intermedio, llama a un endpoint para leer los datos del dispositivo bajo demanda o de forma programada. Es útil para la sincronización por lotes, como extraer un día de lecturas de medidores a medianoche, y para cualquier sistema que prefiera preguntar en lugar de que le avisen.
Middleware e iPaaS. Herramientas como n8n, Make o un motor de flujos de trabajo se ubican entre la plataforma y el sistema de negocio. Se encargan de los reintentos, la transformación y ese mapeo incómodo en el que los nombres de campo de un sistema no coinciden con los del otro. Cuando tienes más de un sistema destino o la lógica empieza a ramificarse, el middleware la mantiene fuera de ambos extremos.
Disparadores basados en eventos. Lógica que se ejecuta cuando se cumple una condición, no según un reloj. Llega una lectura, una regla la evalúa, y una acción se dispara solo si la condición se cumple. Esto evita que satures el CRM con cada lectura cuando solo te interesan las que cruzan un límite.
Consideraciones sobre el mapeo y la sincronización de datos
Aquí es donde las integraciones se rompen sin hacer ruido. El transporte es la parte fácil. Mantener dos sistemas de acuerdo sobre los mismos hechos es la parte difícil.
Identificadores. Cada dispositivo necesita un mapeo estable con su contraparte en el sistema de negocio: un dispositivo con un registro de activo, un medidor con una cuenta de cliente, una máquina con un contrato de servicio. Decide dónde vive ese mapeo y manténlo como fuente de autoridad. Etiqueta el dispositivo con el ID del activo en el ERP, o mantén una tabla de búsqueda que lea la integración. Lo que no quieres es hacer coincidencias por nombres que alguien renombrará el próximo trimestre.
Frecuencia. Ajusta la tasa de sincronización al caso de uso. Las lecturas de facturación pueden correr a diario. Los tickets de falla deben dispararse en segundos. Las actualizaciones de horas de operación de un activo podrían ser cada hora. Enviarlo todo en tiempo real es un desperdicio y hará que el sistema destino te aplique límites de tasa. Enviarlo demasiado despacio deja los registros desactualizados.
Idempotencia. Las redes reintentan. Si la entrega de un webhook supera el tiempo de espera y se dispara de nuevo, no quieres dos facturas ni dos tickets duplicados. Asigna a cada evento una clave única con la que el sistema receptor pueda deduplicar, y diseña la operación destino de modo que ejecutarla dos veces con la misma clave no cambie nada la segunda vez.
Autenticación y seguridad
Estás conectando una plataforma operativa con sistemas que contienen dinero y datos de clientes, así que las credenciales importan.
Usa tokens con alcance limitado, no claves de toda la cuenta. El token que una integración usa para enviar una lectura de medidor al ERP debería poder hacer eso y nada más. Si se filtra, el radio de impacto es una sola operación, no toda tu cuenta.
Aplica el mínimo privilegio en ambos extremos. El lado de TagoIO lee solo los dispositivos que la integración necesita. El lado del ERP o CRM acepta escrituras solo en los objetos dentro de su alcance. Rota las claves de forma programada y guárdalas donde no queden en texto plano dentro de un script. TagoIO cuenta con la certificación ISO 27001 y está alineado con el GDPR, pero esa postura solo se sostiene si las credenciales que emites siguen la misma disciplina.
Cómo TagoIO se conecta con sistemas ERP y CRM
TagoIO no incluye un botón de un clic para SAP o Salesforce, y deberías desconfiar de cualquier plataforma que afirme tener un conector prediseñado para cada sistema empresarial. Lo que TagoIO te da son los bloques de construcción para armar la integración tú mismo, con la lógica viviendo donde puedes verla y cambiarla.
La REST API. Cada dispositivo, variable y dato almacenado es accesible a través de la API. Un sistema externo, o un iPaaS como n8n, puede extraer lecturas de forma programada y enviarlas al destino. Tu integración con NetSuite puede llamar a la API de TagoIO cada noche, leer el consumo del día por medidor y registrar las líneas de factura.
Scripts de Analysis. Son scripts serverless que se ejecutan dentro de TagoIO, en Node.js o Python. Aquí es donde suele ocurrir el trabajo de verdad. Un Analysis puede dispararse con los datos entrantes, evaluar una condición, transformar la carga útil al formato que el sistema destino espera y llamar directamente a la API del ERP o CRM. Conectarse a HubSpot o Salesforce se reduce a una llamada HTTP desde tu script a su API con un token de alcance limitado, más la lógica de mapeo intermedia. Como se ejecuta dentro de la plataforma, no tienes que levantar un servidor para alojarlo.
Acciones de webhook. Las Actions de TagoIO pueden disparar un webhook cuando se cumple una condición. Una variable de falla cruza un umbral, la Action hace un POST a tu endpoint de mesa de servicio, y se abre un ticket. Para el trabajo basado en eventos, donde quieres un envío en el instante en que algo ocurre, este es el camino más corto. Combínalo con un Analysis cuando la carga útil necesite reformatearse antes de llegar a SAP o a tu CRM.
Una forma habitual de una integración real: una Action detecta el evento, un script de Analysis reformatea y enriquece los datos y gestiona la idempotencia, y el script llama a la REST API del sistema empresarial con un token de alcance limitado. Eso cubre el caso de falla a ticket, el de consumo a factura y el de actualización de activos con las mismas tres piezas en distintas disposiciones.
Por dónde empezar
Elige un ciclo que hoy sea manual y ciérralo. Consumo a factura y falla a ticket son los dos que se amortizan más rápido, porque quitan a una persona de una tarea repetitiva. Mapea primero los identificadores, decide la frecuencia de sincronización, construye el Analysis que hace la transformación y prueba la idempotencia disparando el mismo evento dos veces a propósito. Una vez que un ciclo funcione de punta a punta, el resto sigue el mismo patrón.
