Es lunes por la mañana. Tu equipo de ventas envió 15 cotizaciones a través de Salesforce durante el fin de semana. Para el jueves por la tarde, solo 3 llegaron a tu ERP para su cumplimiento. ¿Las otras 12? Atascadas en algún lugar del proceso de integración. Tu equipo está revisando cada una manualmente. Tus clientes están esperando. Y te preguntas por qué la "integración completa Salesforce-ERP" por la que pagaste 65.000€ en realidad no está integrando nada.
Este escenario no es inusual. En los últimos seis meses, he revisado 14 integraciones Salesforce-ERP para empresas B2B suizas. Once tenían los mismos problemas fundamentales. Ninguno estaba relacionado con la tecnología en sí.
El problema que todos enfrentan
La mayoría de las integraciones Salesforce-ERP funcionan perfectamente durante 2-4 semanas. Luego sucede una de tres cosas:
- Fallos silenciosos: Los datos dejan de sincronizarse, pero nadie lo nota hasta que un cliente llama por un pedido faltante
- Errores en cascada: Una transacción fallida bloquea todo lo que está detrás, creando un retraso de más de 100 sincronizaciones fallidas
- La actualización del proveedor: Tu proveedor de ERP lanza una actualización que cambia el nombre de un campo, y de repente nada funciona
¿La respuesta típica? Llamar al proveedor de integración. Esperar 48 horas. Pagar por soporte de emergencia. Obtener un parche temporal. Repetir el ciclo tres meses después.
Tu equipo de operaciones se adapta construyendo "procesos de respaldo" — hojas de cálculo, verificaciones manuales, reuniones de conciliación semanales. La integración se convierte en el problema que se suponía debía resolver.
Por qué sucede esto (No son las herramientas)
El problema no es Salesforce. No es tu ERP. La plataforma de middleware que elegiste probablemente está bien.
El problema es la arquitectura — específicamente, tres suposiciones que parecen razonables durante el proceso de venta pero fallan bajo condiciones del mundo real:
Suposición 1: "La sincronización en tiempo real siempre es mejor"
La sincronización en tiempo real suena ideal. ¿Cotización creada en Salesforce? Aparece instantáneamente en el ERP. Perfecto, ¿verdad?
Hasta que tu ERP está caído durante 15 minutos durante una ventana de mantenimiento planificada. O un problema de red causa un timeout. O alguien guarda un registro incompleto. Sincronización en tiempo real significa fallos en tiempo real.
Un fabricante suizo con el que trabajé tenía configurada la sincronización en tiempo real. Cuando su ERP estuvo brevemente no disponible, 47 órdenes de venta fallaron en sincronizarse. Como no había cola, ni mecanismo de reintento, esas órdenes simplemente... desaparecieron del proceso de sincronización. Descubrieron el problema cuatro días después cuando los clientes empezaron a llamar.
Suposición 2: "La integración maneja todo automáticamente"
La mayoría de las integraciones están construidas para el camino feliz. ¿Cliente existe en ambos sistemas? Genial. ¿Producto estándar? Sin problema. ¿Lista de precios coincide? Perfecto.
Pero ¿qué pasa cuando:
- ¿Un nuevo cliente existe en Salesforce pero aún no en el ERP?
- ¿Un acuerdo de precios especiales aplica a esta cotización?
- ¿El producto está disponible pero necesita una configuración personalizada?
Sin manejo explícito de errores para casos límite, la integración falla silenciosamente o, peor, crea datos incorrectos. Descubres el problema cuando contabilidad concilia el mes y encuentra discrepancias.
Suposición 3: "Una vez que funciona, sigue funcionando"
Los proyectos de integración tienen una fase de pruebas. Todo pasa. Sales a producción. Éxito.
Luego tu proveedor de ERP actualiza a la versión 12.3. Un nombre de campo cambia. Un tipo de dato cambia de string a integer. Un endpoint de API queda obsoleto.
La integración se rompe. Y como nadie documentó qué campos, endpoints o transformaciones usa realmente la integración, arreglarlo toma días de investigación.
La arquitectura que realmente funciona
Después de ver este patrón repetidamente, esto es lo que previene estos fallos:
Principio 1: Diseña para el fallo
Asume que los fallos sucederán. Construye explícitamente para ellos:
- Usa colas, no sincronización directa: Cuando un registro necesita sincronizarse, ponlo en una cola. Procesa la cola con lógica de reintentos. Si algo falla, no bloquea todo lo demás.
- Implementa backoff exponencial: Primer reintento después de 1 minuto. Luego 5 minutos. Luego 15. Esto maneja problemas temporales sin intervención manual.
- Alerta sobre patrones, no fallos individuales: ¿Una sincronización fallida? Normal. ¿Diez fallos en una hora? Alertar a alguien.
Una empresa mayorista suiza implementó este enfoque. Todavía tienen fallos de sincronización ocasionales (cliente no encontrado, inventario temporalmente bloqueado, etc.), pero estos se resuelven automáticamente a través de reintentos. La intervención manual bajó de diaria a una vez por mes.
Principio 2: Haz visibles los fallos
Los peores fallos son los silenciosos. Diseña para la visibilidad:
- Dashboards de errores: Muestra qué falló, por qué, y qué necesita atención
- Informes resumen semanales: "95% de las sincronizaciones tuvieron éxito, 5% necesitaron reintento, 0.2% necesitan revisión manual"
- Propiedad clara: Alguien necesita ser dueño de la salud de la integración (usualmente operaciones, no TI)
No puedes arreglar problemas que no sabes que existen. La visibilidad no es opcional.
Principio 3: Documenta las dependencias
Cuando tu integración se rompa (y lo hará), necesitas saber:
- Qué endpoints de API usa
- Qué campos son obligatorios vs opcionales
- Qué transformaciones de datos ocurren
- Qué sistema es la fuente de verdad para cada tipo de dato
Esta documentación no es para tu yo actual. Es para tu equipo en seis meses cuando algo se rompa a las 4 PM del viernes y necesites entender qué cambió.
Verificación de realidad: Una buena arquitectura no prevendrá todos los fallos. Hace que los fallos sean manejables, visibles y corregibles sin llamadas de soporte de emergencia al proveedor.
Cómo se ve esto en la práctica
Una empresa B2B suiza con 120 empleados vino a mí después de su tercer "fallo completo de integración" en 18 meses. Cada vez, pagaron 5.000-8.000€ por reparaciones de emergencia.
Reconstruimos su integración Salesforce-ERP con estos principios:
- Procesamiento basado en colas (no en tiempo real)
- Registro de errores comprensivo
- Informes de salud automatizados diarios
- Documentación clara de cada punto de integración
Primer mes: 6 alertas que requirieron atención (antes 15-20 intervenciones manuales). Segundo mes: 2 alertas. Para el tercer mes: la integración simplemente... funcionaba.
Su proveedor de ERP lanzó una actualización. La integración capturó los registros afectados, registró errores claros, y el equipo lo arregló en 2 horas en lugar de 2 días. Sin llamadas de soporte de emergencia. Sin pedidos perdidos.
Preguntas para hacerle a tu proveedor de integración
Antes de tu próximo proyecto de integración (o al evaluar el actual), pregunta:
- ¿Qué pasa cuando el ERP está temporalmente no disponible? Si la respuesta es "la sincronización fallará", pregunta sobre mecanismos de reintento.
- ¿Cómo sabemos cuando algo se rompe? Si la respuesta es "verás errores", pregunta por detalles de monitoreo y alertas.
- ¿Quién es dueño de la documentación? Si la respuesta es confusa o "proporcionamos documentación", asegúrate de que realmente obtengas documentación usable, no solo especificaciones de API.
- ¿Cuál es el proceso de recuperación ante desastres? Si algo se rompe a las 6 PM del viernes, ¿qué pasa? ¿Hay una cola que podamos reproducir? ¿O perdemos datos?
- ¿Puede nuestro equipo modificar esto nosotros mismos? El vendor lock-in no se trata del software. Se trata del lock-in de conocimiento.