¿Por qué esto importa más de lo que parece?

Porque el punto de partida en la región es más precario de lo que suele asumirse. Según datos de la Cámara Colombiana de Comercio Electrónico y Confecámaras citados en la discusión pública del sector, solo el 35% de las empresas en Colombia opera con un ERP integral: el 65% restante todavía trabaja con hojas de cálculo o sistemas aislados.

Eso significa que, en la mayoría de los casos, «integrar el CRM con el ERP» es en realidad el momento en que la empresa formaliza por primera vez dónde vive cada dato. La integración es la excusa; el trabajo real es de gobierno de la información.

¿Qué decisiones hay que tomar antes de elegir método?

Tres, y ninguna es técnica. Saltárselas es la causa más común de integraciones que hay que rehacer:

  • ¿Cuál es la fuente de verdad de cada dato? El precio de un producto probablemente vive en el ERP; el estado de una oportunidad, en el CRM. Cada campo necesita un dueño único.
  • ¿En qué dirección fluye? Una integración bidireccional cuesta bastante más que una unidireccional y multiplica los casos de conflicto. Muchas necesidades reales se resuelven en un solo sentido.
  • ¿Qué pasa ante un conflicto? El mismo cliente con dirección distinta en cada sistema. Sin una regla escrita, la integración inventa una, y normalmente es la equivocada.

¿Qué métodos existen y cuándo usar cada uno?

MétodoCuándo sirveDónde se rompe
Conector prearmadoAmbos sistemas son estándar, sin personalizaciones, campos que coincidenEn cuanto hay un objeto o campo a medida
Plataforma de automatización sin códigoFlujos sencillos, volumen moderado, poca transformación de datosCon alto volumen, lógica condicional compleja o necesidad de reintentos
Middleware a medida sobre APIsLógica de negocio propia, transformación de datos, control de erroresRequiere mantenimiento: es software, no configuración
Sincronización por archivo programadoSistemas antiguos sin API, tolerancia a retrasoNo sirve si se necesita tiempo real

La elección honesta suele ser una mezcla: conector estándar para lo que encaja y desarrollo a medida para el 20% que no. Forzar todo a un solo método es lo que encarece los proyectos.

¿Qué se sincroniza en tiempo real y qué no?

La sincronización en tiempo real es cara y frágil; la programada es barata y robusta. Conviene decidir campo por campo en lugar de aplicar una política única.

En tiempo real tiene sentido lo que bloquea a alguien: el estado de crédito de un cliente cuando el comercial está cotizando, el inventario cuando se promete una fecha de entrega. Programado —cada hora, cada noche— basta para casi todo lo demás: maestros de clientes, catálogos, históricos de facturación.

Preguntarse «¿qué pasa si este dato llega con dos horas de retraso?» descarta la mitad de los requisitos de tiempo real que aparecen en las reuniones iniciales.

¿Cuáles son los errores que obligan a rehacer el proyecto?

  • Integrar sin limpiar primero. Si el CRM tiene tres versiones del mismo cliente, la integración las propaga al ERP. Ahora tienes el problema en dos sistemas.
  • No registrar los errores. Una integración sin bitácora falla en silencio, y te enteras semanas después por una diferencia contable.
  • Sin ambiente de pruebas. Probar contra producción es como aprender a conducir en la autopista.
  • Sincronizarlo todo «por si acaso». Cada campo sincronizado es un punto de fallo permanente. Sincroniza lo que alguien va a usar.
  • No definir qué pasa si un sistema está caído. ¿Se encola y se reintenta, o se pierde? Esa decisión debe ser explícita.

¿Cómo se aborda un proyecto de integración por fases?

Empezando por el flujo de mayor dolor y una sola dirección. Normalmente es el maestro de clientes o el paso de una oportunidad ganada a pedido: es el punto donde hoy alguien copia datos a mano y donde el error se nota.

Con ese flujo estable durante unas semanas, se añade el siguiente. La ventaja no es de gestión de proyecto: es que cada fase revela problemas de calidad de datos que no eran visibles antes, y descubrirlos de a uno es mucho más barato que descubrirlos todos el día del lanzamiento. En Articod Digital Lab desarrollamos middlewares a medida precisamente cuando esa lógica de fases y de conflictos no cabe en un conector estándar.