Cómo plantear correctamente una integración entre dos sistemas (antes de hablar con nadie)
La mayoría de las integraciones que salen mal se torcieron en el planteamiento, no en el código. Las preguntas que debes responder antes de pedir presupuesto, y cómo reconocer una propuesta de integración seria.
Respuesta corta: una integración se plantea respondiendo cuatro preguntas de negocio — qué datos viajan, en qué sentido, con qué frescura y quién manda cuando los sistemas discrepen — más una técnica: qué expone cada sistema. Con esas cinco respuestas, cualquier proveedor serio puede darte una propuesta con fases y precio; sin ellas, te darán una estimación al aire que se desviará. Esta guía te deja el planteamiento hecho.
Por qué las integraciones se tuercen en el planteamiento
Cuando una integración fracasa, casi nunca es porque “el código estaba mal”: es porque nadie definió qué sistema tenía razón sobre un dato, o porque apareció a mitad de proyecto que el ERP no exponía las tarifas, o porque “tiempo real” significaba cosas distintas para cada uno. Todo eso se resuelve gratis en el planteamiento — y carísimo en producción.
Las cuatro preguntas de negocio
1. ¿Qué datos, exactamente?
No «conectar el ERP con la web»: qué datos. Productos, precios, tarifas especiales, stock, clientes, pedidos, facturas, estados… Haz la lista concreta. Cada dato que añades tiene coste; cada dato que olvidas, más.
2. ¿En qué sentido viaja cada uno?
Para cada dato de la lista: ¿va del sistema A al B, del B al A, o en ambos sentidos? Sospecha de los “ambos”: los flujos bidireccionales de verdad son raros — casi siempre son dos flujos de ida bien definidos (aquí el detalle para el caso ERP⇄ecommerce).
3. ¿Cómo de frescos?
¿El dato puede tener una hora de retraso? ¿Un día? ¿Ni un segundo? Cada nivel de frescura tiene un coste distinto, y no todo necesita tiempo real — decidirlo dato a dato es una de las mayores palancas de ahorro del proyecto.
4. ¿Quién manda cuando discrepen?
Discreparán. Para cada dato, un único sistema es la fuente de verdad y el otro obedece. Escribirlo negro sobre blanco evita el bucle en el que cada sistema machaca al otro — el error más caro de detectar tarde.
La pregunta técnica: ¿qué expone cada sistema?
Inventaría los mecanismos reales de cada sistema: ¿API? ¿qué cubre de verdad, campo a campo? ¿acceso a base de datos? ¿ficheros de importación/exportación validados? No te fíes de “tiene API” en la ficha comercial: muchas APIs cubren la mitad de lo que necesitas, y descubrirlo a mitad de proyecto cambia el presupuesto. Si no sabes responder esto, pídeselo por escrito a los proveedores de tus sistemas — es una pregunta que están obligados a saber contestar.
Lo que una propuesta de integración seria debe incluir
Con tu planteamiento hecho, evalúa lo que te propongan con esta lista:
- Los flujos, uno a uno — con su sentido, su frescura y su fuente de verdad. Si la propuesta habla de “conectar los sistemas” en genérico, está estimando a ciegas.
- Qué pasa cuando algo falle — validación antes de aplicar, registros problemáticos apartados sin tumbar el resto, log de cada ejecución y avisos concretos. Una integración sin plan de fallo es un script con suerte.
- Fases — el flujo que más duele primero, en producción pronto; el resto sobre esa base. Desconfía del “todo conectado en una entrega”.
- Comportamiento ante repeticiones — si una sincronización se relanza, no puede duplicar pedidos ni clientes. Pregúntalo con esas palabras; la respuesta te dirá mucho.
- Respeto a la operación diaria — las cargas pesadas fuera de horario; tu ERP tiene usuarios reales.
- Propiedad y salida — ¿de quién es la integración? ¿está documentada? ¿podría mantenerla otro? (Nuestra respuesta: tuya, documentada, sin peajes.)
Errores de planteamiento que vemos repetirse
- Empezar por la herramienta («¿integramos con Zapier o a medida?») antes que por los flujos. La herramienta es la última decisión, no la primera.
- Plantearlo como proyecto técnico sin sentar a la persona que sufre el proceso — que es quien sabe qué discrepancias existen de verdad.
- No presupuestar los datos sucios. Los datos reales son imperfectos; la integración debe apartarlos y avisar, y eso es trabajo que hay que contar desde el día uno.
- El silencio como estado normal. Si nadie mira la integración, que la integración avise sola. Lo que falla en silencio envejece los datos de toda la empresa — así lo montamos en este proyecto.
Tu checklist antes de pedir presupuesto
- Lista de datos concretos que deben viajar.
- Sentido de cada flujo (desconfía de los bidireccionales).
- Frescura necesaria, dato a dato.
- Fuente de verdad de cada dato, por escrito.
- Inventario de lo que expone cada sistema (pedido a sus proveedores si hace falta).
- El flujo que más duele, señalado — por ahí se empieza.
Con esto respondido, la conversación con cualquier proveedor se vuelve corta y comparable. Y si prefieres que el planteamiento lo hagamos contigo, es exactamente lo que resuelve nuestro análisis con alcance y entregable cerrados.
¿Tienes dos sistemas que deberían hablarse y no lo hacen? Tráenos tu lista — o tráenos el problema y la hacemos juntos. Cuéntanos qué necesitas conectar →
Servicio relacionado: Integraciones y automatización
Sobre el autor
Oscar Blanco
Fundador y responsable técnico de MUROSOFT
Desarrollador fullstack con más de una década construyendo software para empresas. En MUROSOFT analiza el proceso antes que la tecnología: qué se hace hoy, qué cuesta y qué merece la pena automatizar. Trabaja de forma directa con quien va a usar el sistema, sin capas intermedias entre el problema y quien lo resuelve.