Cómo plantear la integración Salesforce ERP

Cuando un pedido cerrado en Salesforce llega tarde al ERP, o un comercial consulta existencias en una hoja de cálculo antes de confirmar una propuesta, el problema no es solo técnico. La integración Salesforce ERP condiciona la calidad de la decisión comercial, la carga de los equipos administrativos y la confianza en los datos que utilizan operaciones y dirección.

En empresas B2B con ciclos de venta complejos, tarifas negociadas, catálogo técnico o servicios recurrentes, CRM y ERP cumplen funciones distintas. Salesforce suele concentrar la relación comercial, las oportunidades, las previsiones y el servicio. El ERP suele ser el sistema de referencia para pedidos, facturación, stock, compras o contabilidad. Conectarlos no significa copiar toda la información de uno a otro. Significa acordar qué proceso debe avanzar, qué sistema toma cada decisión y cómo se controlan las excepciones.

El primer paso no es elegir una herramienta

Muchas integraciones se complican porque comienzan por la tecnología: una API, un conector estándar o una plataforma de integración. Son componentes necesarios, pero no resuelven una ambigüedad de proceso. Antes conviene concretar qué situación se quiere corregir y quién la sufre.

Un escenario hipotético habitual ayuda a verlo. Una empresa distribuidora registra oportunidades y presupuestos en Salesforce, pero crea los pedidos en el ERP cuando el cliente acepta. Si el equipo comercial puede modificar condiciones, direcciones de entrega o líneas de producto mientras administración vuelve a teclear la información, aparecerán discrepancias. Automatizar el envío de todos los campos puede acelerar el error si no se define antes cuándo un presupuesto pasa a ser pedido y qué validaciones debe superar.

La conversación inicial debería responder, como mínimo, a cuatro preguntas: qué evento dispara el intercambio, qué datos son necesarios, cuál es el sistema maestro de cada dato y qué debe ocurrir si el destino rechaza la operación. Estas decisiones reducen más riesgo que añadir campos a una interfaz.

También conviene separar integración de implantación o migración. Si Salesforce todavía no representa de forma consistente el proceso comercial, quizá sea necesario ajustar su modelo de datos, automatizaciones o permisos antes de conectarlo al ERP. Si se va a sustituir un CRM o un ERP, la migración histórica es otro alcance, con criterios propios de limpieza, carga y conciliación. Mezclar ambos trabajos en una única estimación suele ocultar esfuerzo y dependencias.

Qué datos deben moverse en una integración Salesforce ERP

La respuesta depende del modelo operativo. No todas las entidades necesitan sincronización bidireccional ni en tiempo real. De hecho, ese planteamiento aumenta la complejidad de forma considerable cuando no existe una necesidad clara.

Es frecuente que las cuentas, los contactos, los productos, las listas de precios y la disponibilidad tengan reglas diferentes. El ERP puede ser la fuente de referencia para catálogo, tarifas, impuestos y stock; Salesforce puede serlo para actividad comercial, previsiones, interlocutores y segmentación. Los pedidos pueden nacer en Salesforce y quedar confirmados en el ERP, mientras que el estado de preparación, entrega y factura vuelve al CRM para que ventas y atención al cliente tengan contexto.

La propiedad del dato debe expresarse con precisión. Decir que «los clientes están en ambos sistemas» no basta. Hay que determinar si Salesforce crea una cuenta provisional, si el ERP asigna el código definitivo, cómo se evitan duplicados y qué atributos puede actualizar cada aplicación. Si dos sistemas pueden cambiar el mismo campo sin una regla de prioridad, tarde o temprano habrá conflictos difíciles de explicar.

La calidad de los identificadores merece una atención especial. Los nombres comerciales, correos o razón social no siempre son claves fiables. Una integración suele necesitar identificadores externos estables, reglas de correspondencia y trazabilidad entre registros. Sin ello, una incidencia aparentemente menor puede generar pedidos asociados a una cuenta incorrecta o impedir que un cambio relevante llegue a destino.

Elegir el patrón técnico según el proceso

No existe una arquitectura válida para todos los casos. La elección depende del volumen, la criticidad del proceso, la capacidad del ERP y las herramientas ya disponibles. Una integración directa mediante API puede ser razonable para un alcance concreto y bien delimitado. Reduce capas, pero también puede aumentar el acoplamiento entre ambos sistemas si crecen las reglas de transformación y los flujos.

Una plataforma de integración puede aportar orquestación, transformación de datos, monitorización y reutilización de conectores. A cambio, incorpora licencias, operación y conocimientos específicos. En organizaciones con varios sistemas -por ejemplo, Salesforce, ERP, plataforma documental y herramienta de soporte- puede facilitar un gobierno más ordenado. Para un único intercambio de bajo volumen, puede ser una carga innecesaria.

El procesamiento en tiempo real tiene sentido cuando el usuario necesita una respuesta inmediata, como validar disponibilidad o crear un pedido al confirmar una venta. Para actualizaciones de catálogo, estados de factura o grandes volúmenes históricos, una ejecución programada puede ser más predecible y menos costosa de operar. Entre ambos extremos, los eventos permiten reaccionar a cambios concretos sin consultar continuamente el sistema origen, siempre que la plataforma soporte ese modelo con garantías suficientes.

La recomendación no es perseguir la menor latencia posible, sino acordar la latencia admisible para cada dato. Que una factura aparezca en Salesforce unos minutos después puede ser aceptable. Que un comercial confirme un producto sin una validación fiable de disponibilidad quizá no lo sea. El criterio debe ser operativo, no estético.

La documentación oficial de patrones de integración de Salesforce distingue distintos enfoques según el proceso, los datos y el tiempo de respuesta necesario. Sirve como referencia para contrastar la decisión técnica con los requisitos del proyecto.

Diseñar para errores previsibles, no para demostraciones perfectas

Las demostraciones suelen mostrar un registro que viaja correctamente de A a B. En producción, habrá campos obligatorios incompletos, límites temporales de los servicios, cambios de formato, registros duplicados y usuarios que modifican datos en el momento menos conveniente. La integración debe tratar estas situaciones como parte del diseño.

Conviene definir qué errores se reintentan automáticamente, cuáles quedan en una cola para revisión y qué información necesita una persona para resolverlos. Un mensaje que solo dice «fallo de integración» no es operativo. Debería permitir identificar el registro, el paso afectado, la causa devuelta y si hubo reintentos.

Antes de activar reintentos, hay que evitar que una misma solicitud cree dos pedidos. Una clave de operación estable y un control de duplicados en el destino permiten reconocer solicitudes ya procesadas. Si se pierde la respuesta después de crear el pedido, el procedimiento debe comprobar su estado antes de repetir la operación. También conviene conciliar periódicamente pedidos y estados entre ambos sistemas, porque la ausencia de errores técnicos no demuestra que todos los registros coincidan.

La observabilidad no es un extra reservado a arquitecturas grandes. Para un alcance proporcionado, suele incluir registros técnicos consultables, alertas sobre fallos relevantes, métricas básicas de ejecuciones y un procedimiento de recuperación. El nivel de detalle depende de la criticidad. Un flujo que crea pedidos exige controles distintos de uno que actualiza una etiqueta comercial una vez al día.

También deben revisarse permisos, credenciales y acceso a datos desde el inicio. No se trata de bloquear el proyecto con una revisión desproporcionada, sino de acordar qué identidad técnica realiza cada operación, qué privilegios necesita y cómo se mantiene esa configuración. La integración es un componente vivo, no una entrega que pueda quedar sin propietario.

Un alcance útil se puede contratar y validar

Una propuesta de integración debería distinguir trabajo de análisis, construcción, pruebas, despliegue y evolución posterior. Cuando la situación actual no está documentada o hay incidencias recurrentes, puede ser razonable acordar primero una revisión técnica acotada y de pago. Su propósito es reducir incertidumbre concreta, no convertir toda mejora en una auditoría extensa.

Para valorar el alcance, resulta útil pedir una respuesta clara sobre estos aspectos:

• Procesos incluidos y procesos expresamente fuera de alcance.
• Sistemas, entornos y responsables que intervienen en cada flujo.
• Datos que se crean, actualizan o solo consultan, junto con su sistema maestro.
• Criterios de aceptación, casos de prueba y tratamiento de excepciones.
• Entregables de configuración, código, documentación operativa y transferencia de conocimiento.
• Dependencias de licencias, accesos, terceros o cambios necesarios en Salesforce y en el ERP.

Estos puntos también ayudan a separar costes que suelen confundirse: licencias de plataforma o conectores, desarrollo de la integración, ajustes de procesos en Salesforce, posibles trabajos sobre el ERP, migración de datos históricos y mantenimiento posterior. No tienen por qué contratarse a la vez, pero sí deben hacerse visibles para tomar decisiones con criterio.

Entender, mejorar y mantener la integración

Una ejecución controlada suele avanzar en tres etapas. Primero se entiende el flujo actual y se valida el alcance mínimo que aporta valor. Después se construye y prueba una mejora con datos y escenarios representativos, incluyendo errores previsibles. Por último, se deja preparado el mantenimiento: responsables, documentación, monitorización y un mecanismo para priorizar cambios futuros.

El orden puede variar. Si existe una incidencia crítica, puede ser necesario corregir un punto concreto antes de abordar un rediseño mayor. Si el objetivo es habilitar nuevas automatizaciones o capacidades de IA aplicada, primero habrá que comprobar si los datos están disponibles, son consistentes y llegan con la frecuencia necesaria. La IA no corrige por sí sola una propiedad de datos mal definida ni una integración sin control de errores.

La mejor integración Salesforce ERP no es la que intercambia más campos ni la que parece más sofisticada en un diagrama. Es la que deja claras las responsabilidades entre sistemas, reduce trabajo manual donde aporta valor y permite investigar una discrepancia sin depender de una sola persona.

Si está valorando conectar Salesforce con su ERP o corregir una integración que ya genera fricción, puede comentar su caso con SENVORA. La conversación inicial permite valorar el encaje y ordenar prioridades. Cualquier análisis técnico o implementación se acuerda después, con alcance, entregables y presupuesto definidos.