Ventas registra al cliente en el CRM, alguien copia el pedido a una hoja de cálculo, finanzas pregunta el importe en un chat y el inventario mantiene otro saldo. Cuando llama el cliente, el equipo tiene que reconstruir la historia antes de responder.
Ese es el síntoma de unos sistemas que no se conectan entre sí. La solución empieza por mapear una operación real, decidir dónde nace cada dato y asignar a alguien la responsabilidad del flujo. Si el negocio necesita un responsable para organizar y mantener ese software, el diagnóstico debe venir antes de comprar otra herramienta.
Respuesta corta
- Los sistemas pueden coexistir. El problema aparece cuando nadie define el significado, el dueño y el recorrido de cada dato.
- Empieza por el flujo que exige más copias, comprobaciones o explicaciones al cliente.
- Corrige el proceso y la responsabilidad antes de decidir si debes conectar, reemplazar o crear software.
¿Por qué los sistemas de una empresa dejan de conectarse?
En abril de 2026, el artículo de IBM "What is enterprise application integration?" explicó que CRM, ERP, bases de datos y otros sistemas pueden usar formatos, entornos y reglas diferentes (IBM). En una empresa pequeña eso se ve de forma sencilla: cada equipo crea su propia versión del cliente, el pedido o el estado.
El problema suele crecer por etapas. La empresa compra una herramienta para ventas, otra para cobros y una hoja para resolver una excepción. Después, una persona empieza a copiar datos entre ellas. Esa persona se convierte en la integración que nadie documentó.
Separa estas cuatro causas:
- Definiciones diferentes: "cliente" puede significar un contacto, la empresa que paga o la persona que hizo el pedido.
- Propiedad poco clara: nadie sabe qué sistema puede cambiar el precio, la dirección o el estado.
- Flujo incompleto: la venta llega a finanzas, pero no al inventario o a atención al cliente.
- Conexión sin seguimiento: la automatización funciona hasta que cambia un campo, caduca una credencial o falla un paso.
Conectar aplicaciones no decide una regla que el negocio nunca definió. Describe primero el trabajo. Después elige la conexión más pequeña que elimine una tarea repetida, un retraso o una diferencia que el equipo ya reconoce.
¿Cómo saber si el problema es la integración o el proceso?
Sigue un caso real desde el pedido hasta la entrega, el cobro o la atención antes de buscar una plataforma. Anota cada lugar donde alguien vuelve a escribir, comprueba, envía un mensaje, descarga un archivo o pregunta: "¿Cuál es el importe correcto?". Ese mapa sirve más que una lista de herramientas porque muestra dónde se detiene realmente el trabajo.
Haz estas preguntas:
- ¿Qué evento inicia el flujo: una venta aprobada, un pedido recibido, un pago confirmado u otra cosa?
- ¿Qué información se crea en ese momento y quién puede corregirla?
- ¿Qué sistemas necesitan leer el dato y con qué rapidez?
- ¿Qué ocurre cuando la transferencia falla o llega dos veces?
- ¿Quién recibe el aviso y decide el siguiente paso?
Si nadie puede responder la segunda pregunta, todavía falta una decisión de proceso. Si la respuesta existe pero el equipo sigue copiando el mismo dato, hay un candidato claro para integrar. Si un fallo no tiene aviso ni responsable, el riesgo no está solo en la conexión. Está en la operación que debería mantenerla.
¿Qué significa elegir una fuente confiable?
Una fuente confiable no significa ponerlo todo en un solo programa. En "System of Record vs. Source of Truth: What's the Difference?", IBM explica que un sistema de registro mantiene los datos de un dominio, mientras que una fuente de verdad combina información de varios sistemas en una vista coherente (IBM).
En la práctica, elige la autoridad según el tipo de información. El CRM puede ser el lugar donde nacen el cliente y el responsable comercial. El sistema financiero puede controlar las facturas y los pagos. El inventario puede controlar las existencias y sus movimientos. Un panel puede reunir esos datos sin permitir que alguien edite allí el saldo de inventario.
Escribe una tabla pequeña antes de cualquier proyecto:
| Información | Dónde nace | Quién puede cambiarla | Quién solo la consulta |
|---|---|---|---|
| Cliente | sistema de ventas | equipo comercial | atención y finanzas |
| Pedido | flujo de ventas | ventas u operaciones | finanzas y preparación |
| Inventario | rutina de operaciones | equipo de inventario | ventas y compras |
| Pago | sistema financiero | equipo financiero | ventas y dirección |
Los nombres cambian según el negocio. La decisión importante es evitar que dos sistemas editen el mismo hecho sin una regla para resolver conflictos. Una copia puede ser útil. Dos autoridades para el mismo campo se convierten en una disputa.
¿Qué flujo debes corregir primero?
Empieza por el paso que combina repetición, impacto en el cliente y un resultado que alguien pueda observar. No conectes todo el negocio en un solo proyecto. La documentación de Microsoft sobre patrones de integración recomienda flujos modulares para desencadenantes y procesos concretos, y advierte que un flujo monolítico aumenta el mantenimiento (Microsoft Learn).
Un buen primer flujo suele tener estas características:
- empieza con un evento que el equipo reconoce;
- mueve pocos datos;
- alguien puede comprobar el resultado;
- puede repetirse sin crear un segundo cobro, venta o entrega;
- deja un registro cuando algo falla.
El objetivo no tiene que ser "integrar CRM, ERP y WhatsApp". Puede ser: cuando se aprueba una venta, crear el pedido en el sistema de operaciones, avisar a finanzas y mostrar un estado que alguien pueda comprobar. El alcance sigue siendo pequeño, pero el equipo puede notar el resultado.
Si el primer flujo que más repite datos es la preparación de propuestas, usa el diagnóstico de por qué las cotizaciones tardan tanto para medir las esperas antes de conectar más herramientas.
Define también el retraso aceptable. Algunas actualizaciones deben aparecer al instante, como comprobar el inventario antes de prometer una entrega. Otras pueden llegar por lotes, como reunir datos para una reunión. Microsoft documenta patrones programados y orientados a eventos para necesidades distintas. No conviertas toda rutina en tiempo real por costumbre.
¿Conviene integrar, cambiar la herramienta o crear software?
Hay tres caminos razonables. La decisión depende del problema que mediste, no del número de funciones de una demostración.
| Camino | Tiene sentido cuando | Riesgo que debes controlar |
|---|---|---|
| Mejorar el proceso | el equipo aún no acordó etapas, datos o responsables | automatizar una rutina que sigue siendo confusa |
| Integrar lo que ya tienes | las herramientas sirven a cada área, pero repiten datos | crear conexiones sin monitoreo ni responsable |
| Cambiar o crear una solución | el flujo principal no cabe en las herramientas actuales y cambia a menudo | empezar un proyecto grande sin validar la operación |
El artículo sobre cuándo dejar Excel para controlar el inventario usa una decisión parecida: separa el problema de rutina del problema de herramienta. La guía sobre quién mantiene el software después del lanzamiento añade la pregunta que suele olvidarse: ¿quién mantendrá la solución cuando cambie la empresa?
Antes de abrir otra integración, usa también el checklist para decidir cuándo dejar de comprar software y confirma que la próxima herramienta tenga un flujo y un responsable claros.
Una integración preparada puede ser suficiente. El trabajo a medida puede hacer falta para reglas específicas, datos antiguos o un flujo que el producto no representa. En ambos casos, pregunta cómo se revisan los fallos, se corrigen los datos y se asume la operación. El conector no puede ser una caja negra que solo el vendedor sepa explicar.
¿Qué debes preguntar antes de contratar una integración?
Una propuesta no necesita empezar con un diagrama técnico. Pide una explicación que un operador pueda seguir:
- ¿Qué proceso cambia y qué parte sigue siendo manual?
- ¿Dónde nace cada dato y qué sistema continúa siendo responsable de él?
- ¿Cómo verá el equipo un fallo, un duplicado o un retraso?
- ¿Quién corrige los datos después de un fallo?
- ¿Cómo probarán un caso nuevo, uno inválido y una repetición?
- ¿Quién mantiene la conexión cuando un proveedor cambia un campo o una regla?
- ¿La empresa controla las cuentas, los datos, la documentación y el acceso de recuperación?
La guía de la FTC sobre ciberseguridad para pequeñas empresas recomienda acordar con los proveedores las expectativas de seguridad y tratamiento de datos. Para una integración, añade las condiciones de acceso, registro, exportación y salida. Así proteges la continuidad sin exigir que el dueño elija la tecnología por su cuenta.
La prueba más sencilla es pedirle a alguien que describa el flujo sin abrir ninguna herramienta. Si la explicación depende de "después lo compruebo en la hoja" o "esa persona lo sabe", la empresa todavía no tiene una integración. Tiene una cadena de dependencias invisibles que debe hacer explícita.
Preguntas frecuentes
¿Necesito reemplazar todos los sistemas para resolverlo?
No. Muchas empresas pueden empezar definiendo la fuente de cada dato y corrigiendo un flujo. Reemplazarlo todo puede borrar contexto y crear una migración mayor. Confirma primero dónde hay copias, retrasos, conflictos y falta de responsable. Después elige el cambio más pequeño que mejore el trabajo sin esconder el siguiente riesgo.
¿Una hoja de cálculo impide la integración?
No necesariamente. Una hoja puede formar parte de un flujo si tiene una finalidad clara, un responsable y una forma de validar cambios. El problema aparece cuando se convierte en la autoridad informal de varios procesos y nadie sabe qué versión vale. Entonces la discusión trata de propiedad y operación, no solo de formato.
¿Quién debe ser responsable de la integración?
Alguien dentro de la empresa debe responder por el proceso, aunque otra persona implemente la conexión. Ese responsable aprueba definiciones, vigila fallos, decide prioridades y organiza la transición. Un responsable continuo del software puede ocupar ese papel cuando el negocio todavía no tiene capacidad interna.
Conclusión
Los sistemas de una empresa que no se conectan no suelen necesitar una promesa de automatización total. Necesitan un flujo visible, definiciones compartidas y un responsable para cada dato importante.
Empieza por el caso en que el equipo más copia, comprueba o explica. Define dónde nace el dato, quién puede cambiarlo, qué sistemas lo necesitan y qué ocurre cuando la transferencia falla. Solo después decide si debes mejorar el proceso, conectar las herramientas actuales o elegir otra solución.
Fuentes consultadas
- IBM, "What is enterprise application integration?", actualizado el 2026-04-06, consultado el 2026-08-19, https://www.ibm.com/think/topics/enterprise-application-integration
- IBM, "System of Record vs. Source of Truth: What's the Difference?", consultado el 2026-08-19, https://www.ibm.com/think/topics/system-of-record-vs-source-of-truth
- Microsoft Learn, "Explore integration patterns", consultado el 2026-08-19, https://learn.microsoft.com/en-us/power-platform/architecture/key-concepts/integration-patterns/patterns
- Federal Trade Commission, "Cybersecurity for Small Business", consultado el 2026-08-19, https://www.ftc.gov/business-guidance/small-businesses/cybersecurity
- Reddit, "I'm starting to realise that SMEs don’t necessarily need another ERP", consultado el 2026-08-19, https://www.reddit.com/r/smallbusiness/comments/1vn0txg/im_starting_to_realise_that_smes_dont_necessarily/
- Reddit, "Small business back end help", consultado el 2026-08-19, https://www.reddit.com/r/SmallBusinessOwners/comments/1v88xvx/small_business_back_end_help/
