Por HEYVO · Perspectivas
Integrar una web app con un CRM y un ERP exige acordar quién controla cada dato, qué operación se intercambia y cómo se recupera un fallo. La integración más útil comienza con un flujo específico, como llevar al portal el estado de pedidos confirmados. Dibujá el recorrido completo y definí cómo saber que los tres sistemas quedaron de acuerdo.
Qué rol cumple cada sistema
Elegí la fuente de verdad por dato
Un CRM suele registrar oportunidades, contactos y actividad comercial. El ERP puede administrar pedidos, existencias y facturas. Una web app puede ofrecer una vista al cliente o facilitar una tarea de un equipo interno. Las responsabilidades exactas dependen de cómo trabaja la empresa. Definí por escrito quién crea, modifica y valida cada dato. Un contacto comercial y un domicilio de entrega pueden pertenecer al mismo cliente y necesitar responsables diferentes. Si las dos herramientas permiten editar el mismo campo, acordá cuál prevalece y qué debe suceder cuando detectan información incompatible.
Modelá el paso entre una oportunidad y un pedido
En un flujo posible, el CRM registra que una oportunidad fue aprobada y envía la información necesaria al ERP. El ERP valida condiciones, crea el pedido y devuelve un identificador. El portal muestra el estado que el ERP confirmó. Cada transición necesita una definición operativa. «Pedido solicitado» y «pedido confirmado» son estados distintos y deben verse como tales. Si el cliente consulta cuando la solicitud todavía se está procesando, la pantalla debe mostrar ese estado y permitir que la persona sepa cómo continuar.
Cómo diseñar el contrato de datos
| Dato | Fuente del ejemplo | Control de integración |
|---|---|---|
| Oportunidad aprobada | CRM. | Guardar el identificador de origen y verificar el estado antes de crear el pedido. |
| Cuenta de cliente | ERP para el código de facturación. | Vincular el código con la cuenta comercial mediante una correspondencia explícita. |
| Estado de pedido | ERP. | Descartar actualizaciones anteriores al estado que ya se recibió. |
| Acceso al portal | Servicio de identidad o web app. | Validar pertenencia a la cuenta antes de mostrar información. |
| Solicitud de ayuda | Portal al momento de la carga. | Confirmar que el sistema de atención recibió una referencia única. |
Elegí identificadores estables
Usá identificadores que sigan siendo válidos aunque una persona cambie el correo o la empresa cambie su nombre comercial. Guardá la correspondencia entre identificadores externos y el registro local. Detectá qué hacer cuando la referencia todavía no existe o se vincula con dos registros posibles. Una coincidencia aproximada por nombre puede ser útil para revisión, pero merece una verificación antes de afectar un pedido. Prepará muestras con datos incompletos y duplicados. Acordá con operaciones qué información puede corregir directamente y cuándo necesita intervención técnica.
Acordá formatos, estados y reglas de validación
Documentá campos obligatorios, unidades, moneda, zona horaria y opciones de estado. Especificá qué diferencia existe entre un campo vacío y uno ausente. Dos sistemas pueden usar un mismo nombre con significados distintos. Por ejemplo, una fecha de despacho puede ser estimada en el CRM y confirmada por logística en el ERP. Representá ambas como conceptos separados si ambas aportan información. Si se agrega un estado nuevo, definí cómo lo tratará el sistema receptor. Una validación clara evita que datos inesperados se conviertan silenciosamente en información incorrecta para el usuario.
Cuándo usar API, eventos o lotes
Consulta directa cuando la respuesta importa en ese momento
Una consulta directa puede servir para comprobar un dato inmediatamente antes de una decisión. Tiene sentido si el sistema responde con un tiempo y una disponibilidad compatibles con la tarea. Prepará un comportamiento para cuando la respuesta no llega. Puede ser un aviso de indisponibilidad o una opción para retomar el proceso. Definí límites de espera y evitá que una dependencia lenta deje congelada toda la pantalla. Si se conserva un dato previo, indicá su antigüedad cuando una decisión dependa de saber cuán actualizado está.
Eventos para reaccionar a cambios de estado
Un webhook puede avisar que se confirmó un pedido, pero la entrega puede repetirse o llegar fuera de orden según el sistema. Tratá la recepción como un aviso que debe validarse y registrarse. Guardá el identificador del evento o una referencia estable de la operación. Si la plataforma informa versión o secuencia, usala para detectar mensajes viejos. En los flujos que escriben datos, distinguí haber recibido una solicitud de haber completado su efecto. Así se puede reintentar sin repetir accidentalmente una acción de negocio.
Lotes para cargas y conciliaciones
Un intercambio por lotes puede ser suficiente para catálogos o reportes que toleran demoras. Acordá hora de corte, formato y tamaño, y registrá qué archivo se recibió. Si una fila es inválida, decidí si se rechaza todo el lote o si el proceso acepta las filas válidas y genera un informe. Una conciliación periódica también puede detectar registros que quedaron fuera de una sincronización por eventos. La elección se hace según el impacto de un dato demorado y el esfuerzo de recuperar una falla, además de las capacidades de cada plataforma.
Cómo recuperar fallos sin duplicar operaciones
Separá errores temporales de errores que necesitan revisión
Una interrupción de red puede resolverse con un reintento espaciado. Un código de cliente inexistente o una credencial revocada necesita atención. Clasificá errores y asigná un destino: reintento, revisión o aviso al responsable del proceso. En cada caso, dejá un identificador que permita seguir el recorrido sin incluir datos innecesarios en los registros. Una cola de casos pendientes debe mostrar qué falló, cuándo ocurrió y qué acción puede tomar una persona. Si se corrige un dato, definí cómo se vuelve a procesar el caso.
Conciliá con la fuente antes de repetir una escritura
Si la web app pidió crear un pedido y perdió la respuesta, no puede asumir que la creación falló. Buscá por la referencia enviada o usá una clave de idempotencia si la API la admite. Si el pedido existe, recuperá su identificador. Si no es posible saber qué pasó, enviá el caso a revisión con la información necesaria. Diseñá este escenario antes del lanzamiento. Una prueba de timeout después de que el ERP recibió la solicitud es más representativa que probar únicamente con el sistema totalmente apagado.
Ejemplo: de una venta aprobada al seguimiento en el portal
Definí el flujo y sus límites en una prueba de punta a punta
Un distribuidor confirma una oportunidad en el CRM. La integración valida que el cliente tenga código en el ERP, crea el pedido y registra la referencia devuelta. El portal muestra el pedido cuando la confirmación está disponible. La primera prueba incluye un cliente sin código, un mensaje repetido y una actualización atrasada. Para el cliente sin código, la operación queda pendiente con un responsable. Para el evento duplicado, solo aparece un pedido. Para el evento atrasado, el estado visible conserva la actualización más reciente. Cada escenario tiene un resultado comprobable que el equipo puede revisar.
Preparate para operar después del lanzamiento
Medí demora de sincronización, operaciones pendientes y tiempo de recuperación. Establecé a partir de qué nivel se genera una alerta y quién la recibe. Si una dependencia cambia de formato o de permisos, el equipo debe poder detectarlo y probar una corrección antes de aplicarla. Conservá un inventario de integraciones y sus responsables. En cada despliegue verificá que una operación de prueba atraviese los sistemas con las credenciales y datos del ambiente correcto. Ese control facilita descubrir problemas antes de que lleguen a los usuarios.
Qué llevar al relevamiento técnico
Prepará un mapa del recorrido, documentación de las interfaces disponibles y ejemplos anonimizados de datos. Identificá quién administra cada sistema y quién autoriza cambios de permisos. Acordá qué espera ver la persona al final del flujo y en cuánto tiempo. Llevá un ejemplo de error que el negocio considere crítico y pedí una demostración de recuperación. Con esa evidencia es posible decidir qué intercambio implementar primero y qué controles necesita para operar de forma sostenida.
Cómo preparar cambios de versión y permisos
Limitá el acceso de cada integración
Una credencial para consultar estados de pedido solo necesita los permisos correspondientes a esa lectura. Cuando la plataforma lo permita, usá cuentas de servicio separadas por ambiente y por responsabilidad. Definí quién puede rotar una credencial y cómo se actualiza sin interrumpir el trabajo. Revisá los datos que se guardan al diagnosticar errores. Para seguir una operación suelen alcanzar el identificador, el estado y el momento del intento. Si hay que conservar información adicional, documentá el motivo, el acceso y el tiempo de retención. Validá también que los registros de prueba no se mezclen con pedidos reales.
Planificá cambios sin obligar a actualizar todo a la vez
Si un sistema necesita agregar un campo, revisá cómo lo interpreta la versión que ya está en producción. Los cambios compatibles pueden convivir durante una transición. Para cambios incompatibles, acordá una versión explícita o una ventana en la que se prueban los dos flujos. Registrá qué herramientas dependen de cada contrato y verificá un caso con datos previos al cambio. Prepará un modo de volver al contrato anterior cuando sea posible. Si ya se escribieron registros con la nueva estructura, definí cómo se reconcilian antes de revertir. Esa preparación reduce el riesgo de que una modificación menor en apariencia bloquee toda la operación comercial.
Trabajá con HEYVO
Evaluá y cotizá tu primera integración
Compartinos qué CRM y ERP usás, qué dato tiene que viajar y dónde se traba el proceso. Podemos separar la revisión de viabilidad y la implementación para que sepas qué estás cotizando en cada etapa.
Preguntas frecuentes sobre integrar CRM, ERP y web apps
¿Es obligatorio tener APIs en todos los sistemas?
No. Puede existir un mecanismo de intercambio por archivos, exportaciones programadas o un conector oficial. La decisión depende de la frecuencia, el volumen y el nivel de seguridad requerido. Validá que la alternativa permita recuperar errores y que se pueda mantener cuando cambie la plataforma.
¿Cuándo conviene sincronizar en ambos sentidos?
Cuando existe una necesidad concreta de editar datos desde dos sistemas y el negocio puede definir cómo resolver conflictos. Si cada dato tiene una fuente clara, una sincronización unidireccional suele simplificar controles. Antes de agregar el segundo sentido, identificá qué acciones deben conservarse y quién aprueba cambios incompatibles.
¿Cómo evito pedidos o contactos duplicados?
Definí una clave estable para cada operación y comprobá si el destino ya la procesó. Conservá el vínculo entre referencias de origen y destino. Probá que reenviar una notificación no agregue registros. Si dos registros ya existen y son similares, tratá la conciliación como una decisión distinta de prevenir duplicados nuevos.
¿Qué debería incluir la documentación de una integración?
Fuentes de datos, mapeos, credenciales administradas, ambientes, ejemplos de eventos, manejo de errores y procedimientos de recuperación. Agregá contactos responsables y una lista de pruebas de aceptación. La documentación debe permitir que el equipo identifique qué hacer ante un error sin depender de quien implementó el primer flujo.
¿Qué conviene probar antes de estimar todo el proyecto?
Verificá autenticación, acceso a un registro representativo y una operación de prueba en el ambiente autorizado. Comprobá qué información devuelve la API cuando hay un error y qué límites tiene. Un ensayo de este tipo convierte una suposición sobre el sistema en un dato para planificar.