Por qué las integraciones fallan (y casi nunca es por la herramienta)

Cuando una integración se cae a los tres meses, la autopsia muestra casi siempre lo mismo. No falló el conector ni el iPaaS: falló lo que nadie decidió antes de conectarlo.

• Se integró sin mapa. Nadie inventarió los sistemas ni los flujos manuales. La integración automatizó una parte del caos y dejó el resto vivo, ahora más difícil de ver.
• Nadie es dueño del dato. Dos sistemas escriben el mismo campo, cada área cree que su versión es la buena, y el CRM termina siendo el campo de batalla.
• No hubo plan de errores. El día que la API del ERP se cayó veinte minutos, se perdieron pedidos en silencio. Se descubrió tres semanas después, conciliando facturas a mano.

Los tres problemas se previenen en papel, antes de escribir una línea de código o pagar una licencia. Por eso esta guía dedica los primeros tres pasos a decisiones, no a herramientas.

Las tres decisiones de arquitectura que definen el proyecto

Primera: la fuente de verdad se define por campo, no por sistema. "El ERP manda" es una frase que suena bien y rompe integraciones. El ERP manda en crédito y facturación; el CRM en etapa comercial y actividad; el ecommerce en pedidos y carrito. El detalle campo a campo se trabaja en el paso 3, modelado y mapeo.

Segunda: el patrón se elige por flujo, no para todo el stack. Es normal —y sano— que la misma empresa use un conector nativo para HubSpot–ecommerce, un iPaaS para orquestar notificaciones y un middleware a medida para el ERP local que no tiene conector. Cómo decidir cada caso está en el paso 2.

Tercera: la frecuencia la define quien consume el dato. Un vendedor que atiende por WhatsApp necesita el pedido en tiempo real; el reporte contable vive perfecto con un lote nocturno. Sincronizar todo en tiempo real es caro y frágil; sincronizar todo por lotes deja ciega a la operación comercial. La mezcla correcta se diseña en el paso 4.

Cuánto tarda y qué esperar del proceso

Los números honestos, con QA y manejo de errores incluidos: un conector nativo se configura en días; un flujo de iPaaS con lógica de negocio toma de 2 a 4 semanas; un middleware a medida, de 6 a 12 semanas. Si te cotizan la integración de un ERP en una semana, pregunta qué pasa cuando la API devuelve un error 500. El silencio es la respuesta.

Un proyecto serio pasa por fases reconocibles: levantamiento y objetivos, diseño y mapeo, construcción en sandbox, pruebas con datos reales, salida a producción controlada y monitoreo continuo. Es exactamente el flujo de seis fases que usamos en Smarteam para cada integración, y no es casualidad: es el orden que evita que tu producción sea el ambiente de pruebas.

Una expectativa realista más: la primera semana en producción siempre revela datos que nadie sabía que existían. Contactos con emails inventados, pedidos de prueba de 2019, catálogos con SKUs duplicados. No es una falla del proyecto: es el proyecto funcionando. Lo importante es que esos casos caigan en una cola revisable y no en el limbo.

Sobre el presupuesto, la trampa habitual es comparar solo el costo de construcción. Un iPaaS barato de armar puede costar el triple a 12 meses cuando el volumen crece y pagas por tarea; un middleware caro de construir se amortiza si el flujo es de alto volumen y larga vida. Pide siempre el número a un año, con el crecimiento esperado incluido, y compara recién ahí. Y reserva entre un 15 y un 20% del presupuesto para el mes posterior al go-live: ajustes, catálogos que no coincidían y casos que solo aparecen con datos reales.

Cómo elegir un partner de integración: las preguntas incómodas

Cualquier agencia puede mostrar un diagrama con flechas. Estas preguntas separan a quien integra en serio de quien conecta y desaparece:

• ¿Qué pasa si la API destino está caída una hora? La respuesta debe incluir reintentos automáticos y una cola. "Se reprocesa a mano" no es una respuesta.
• ¿Dónde veo los registros que fallaron? Si no hay una cola de errores visible con el motivo de cada falla, vas a enterarte por tus clientes.
• ¿Construyen en sandbox o directo en producción? La única respuesta aceptable es la primera.
• ¿Quién monitorea después del go-live y por cuánto tiempo? Una integración sin monitoreo es una integración que ya está fallando y nadie lo sabe.
• ¿De quién quedan las credenciales y la documentación? Tuyas. Siempre tuyas.

Checklist maestro de la integración de datos

Si puedes marcar todo esto, tu stack está conectado en serio:

• Inventario de sistemas con dueño, API y volúmenes documentados.
• Mapa de flujos que incluye los manuales (exportar/importar cuenta como flujo).
• Fuente de verdad definida por campo y firmada por las áreas.
• Patrón de integración elegido por flujo, con costo proyectado a 12 meses.
• Matriz de mapeo campo a campo aprobada antes de construir.
• Llave de identidad única y base deduplicada antes de sincronizar.
• Reintentos con backoff, escrituras idempotentes y cola de errores con dueño.
• Dashboard de salud: volumen, errores, frescura del dato y conciliación periódica.
• Runbook por flujo crítico: qué revisar y cómo reprocesar.
• Credenciales y documentación en manos de tu empresa, no del proveedor.

La integración técnica es la mitad del cuento: la otra mitad es que el proceso comercial use ese dato con definiciones únicas de funnel y etapas. Para eso está la guía de RevOps. Y si el centro de tu stack es el CRM, la guía de implementación de HubSpot es el complemento natural de esta.