Integrar el ERP con el marketing sin romper el ERP

Solo lectura primero, la capa del medio que evita la maraña, los cuatro problemas que vas a encontrar y las cinco cosas que no hay que hacer nunca.

En algún momento todo proyecto de marketing serio llega al mismo lugar: los datos que importan —qué se vendió, a quién, por cuánto— viven en el sistema de gestión, y el sistema de gestión no habla con nada.

Conectarlo es de las cosas que más rinden, porque cierra el circuito entre la inversión y la facturación. También es de las que más fácil salen mal, porque del otro lado hay un sistema del que depende que la empresa facture.

Por que el ERP no es una integracion mas

Conectar una herramienta de email con un CRM es reversible: si algo sale mal, se desconecta y se vuelve a empezar. El sistema de gestión no tiene esa propiedad.

• Es el sistema de registro. Lo que dice ahí es lo que la empresa considera cierto. Un dato mal escrito no es un bug de marketing: es un problema contable.
• Suele ser viejo y estar vivo. Muchos llevan años funcionando, con personalizaciones que nadie documentó y de las que dependen procesos diarios.
• No fue diseñado para tráfico constante. Fue diseñado para que un puñado de personas cargue operaciones. Una integración entusiasta puede degradarlo para todos.
• Nadie quiere ser quien lo rompió. Y esa aversión, bien entendida, es la que debería gobernar el diseño de la integración.

Solo lectura primero, siempre

La primera versión no escribe nada. Lee, y con eso ya se resuelve la mayor parte del valor: saber cuáles de tus leads compraron y por cuánto es exactamente lo que hace falta para cerrar el círculo de las conversiones y para calcular un CAC real.

Esa primera etapa además compra algo que no se puede comprar de otra forma: confianza.

1. Se lee durante unas semanas y se compara contra lo que la gente ve en pantalla.
2. Aparecen las inconsistencias reales, que siempre son distintas a las que uno esperaba.
3. Recién con eso resuelto se discute escribir.

Saltarse esto es el error más caro del proyecto. Escribir sobre un modelo de datos que todavía no se entiende produce registros duplicados que después alguien tiene que limpiar a mano.

Los cuatro problemas que vas a encontrar

La API sin webhooks es la más común. Obliga a preguntar periódicamente, y ahí hay una trampa: pedir todo cada vez es insostenible apenas crece la tabla. La forma correcta es una marca de agua —«traeme lo que cambió desde la última vez»— que se guarda y se avanza sólo cuando el procesamiento terminó bien. Si se avanza antes, un error deja un hueco que nadie va a notar.

Los campos inconsistentes son los que producen las sorpresas más largas. Sistemas de gestión con años encima acumulan fechas vacías o en cero, campos de texto donde alguien escribió un comentario, y registros que se cargaron de tres formas distintas según la época. La regla que salva: validar en la capa del medio y descartar lo que no cumple dejando registro. Descartar en silencio es como se pierden datos sin que nadie se entere.

Las escrituras concurrentes aparecen cuando hay más de un camino hacia el mismo registro: la integración, una persona cargando a mano, y quizás una automatización vieja que nadie recuerda. La disciplina es aburrida y funciona: una sola vía de escritura, y siempre buscar antes de crear.

La capa del medio

La tentación es conectar el ERP directo con cada herramienta que lo necesite. Con dos herramientas parece razonable; con cinco es una maraña donde nadie puede decir qué toca qué.

Una capa intermedia —un servicio pequeño, una base propia, un flujo de automatización— resuelve cuatro cosas a la vez:

• El ERP tiene un solo consumidor, no cinco.
• La validación y la normalización viven en un solo lugar.
• Se puede reprocesar sin volver a molestar al sistema de gestión.
• Cambiar una herramienta de marketing no toca el ERP.

Ese último punto es el que más se agradece dos años después, cuando se cambia el CRM y resulta que la integración no hay que rehacerla entera.

Lo que no hay que hacer nunca

• Escribir directo en la base de datos. Salteás toda la lógica del sistema: validaciones, cálculos, historial. Funciona hasta que deja de funcionar, y ahí ya hay datos inconsistentes.
• Automatizar clics sobre la interfaz. Se rompe con la próxima actualización, y se rompe en silencio.
• Usar el usuario personal de alguien. Nada queda trazable y todo se cae cuando esa persona cambia su contraseña o se va.
• Probar en producción. Obvio, y sin embargo es lo que pasa cuando no hay un ambiente de prueba y el proyecto tiene fecha.
• Dejarla sin monitoreo. Una integración caída no avisa: simplemente deja de traer datos, y los informes muestran menos ventas sin decir por qué.

Preguntas frecuentes

• Mi ERP no tiene API. No hay caso? Si hay, pero las opciones empeoran en un orden previsible: una exportacion programada, una vista de solo lectura sobre la base, o el intercambio por archivos. Las tres funcionan. Lo que no funciona es automatizar clics sobre la interfaz, que se rompe con la siguiente actualizacion.
• Podemos escribir directo en el ERP? Eventualmente si, y nunca como primer paso. El sistema de registro es donde el negocio guarda su verdad; ganarse el permiso de escritura pasa por demostrar antes que lo leiste bien durante un tiempo.
• La integracion tiene que ser en tiempo real? Rara vez. Las decisiones de marketing se toman a lo sumo diariamente. Una sincronizacion programada cada algunas horas es mas robusta, mas facil de reprocesar y mucho mas barata que exigirle trafico constante a un sistema que no fue disenado para eso.
• De quien es la integracion una vez que funciona? Tiene que ser de alguien, con nombre. Las integraciones se rompen cuando se renombra un campo o cambia una version, y una integracion sin dueno falla en silencio hasta que alguien nota que los numeros dejaron de moverse.