Integration Deep Dive Aug 27

Sí, porque son productos diferentes que atienden a negocios diferentes. Kinetic es un ERP de fabricación construido en torno a trabajos, listas de materiales y la programación de la producción. Prophet 21 es un ERP de distribución construido en torno al inventario, los precios y la velocidad de los pedidos. La parte de CRM se ve similar, pero lo que el equipo de ventas necesita ver difiere: un representante de un fabricante pregunta sobre el estado del trabajo y el plazo de entrega, un representante de un distribuidor pregunta sobre la posición de stock y el precio para este cliente. Delimite el mapeo de campos al modelo de negocio, no a la marca del ERP.

Las conexiones directas son posibles y son más simples de razonar cuando solo hay dos sistemas y el flujo de datos está bien definido. El middlewarejustifica su costo cuando hay un tercer o cuarto sistema en la imagen, cuando las transformaciones son complejas, o cuando necesitas lógica de encolado y reintento porque un sistema queda fuera de servicio por mantenimiento. La compensación es operativa: una conexión directa tiene menos partes móviles, pero el middleware te ofrece un lugar para ver y volver a reproducir un mensaje fallido en lugar de descubrir la brecha semanas después.

Decide temprano si el CRM muestra una vista consolidada de una cuenta o refleja la estructura de entidades legales del ERP. Los fabricantes con varias empresas operativas a menudo tienen el mismo conjunto de clientes configurado por separado en cada una, y el liderazgo de ventas quiere ver la relación total, mientras que finanzas necesita mantener las entidades separadas. El patrón práctico es una cuenta principal en el CRM que agrupa varios registros de clientes del ERP debajo de ella, con la moneda de la transacción en lugar de la cuenta.

El servicio al cliente suele ser el mayor beneficiario, porque la mayoría de las llamadas entrantes son preguntas sobre el estado de los pedidos que, de lo contrario, requieren que alguien abra el ERP o pregunte a un colega. Las finanzas se benefician cuando las conversaciones de cobranza pueden ver la relación de ventas en lugar de solo el informe de envejecimiento. El liderazgo se beneficia de un pipeline de ventas que se reconcilia con los ingresos reales por envíos, en lugar de dos números que nunca coinciden. Delimitar el alcance del proyecto como una herramienta de ventas por sí solo tiende a subvalorarlo internamente y hace que el presupuesto sea más difícil de justificar.

El acceso directo a la base de datos suele desaparecer, y ese es el punto en el que muchas integraciones desarrolladas internamente dejan de funcionar. Las implementaciones en la nube exponen datos a través de APIs con límites de tasa y autenticación que las integraciones en las instalaciones nunca fueron diseñadas para manejar, y el programa de actualizaciones deja de ser algo que controlas. Todo lo que lea directamente la base de datos ERP debe ser inventariado antes de programar una migración a la nube, no después, porque reconstruir esas conexiones suele ser la tarea más larga del proyecto.

No, y esa es precisamente la disyuntiva. Un CRM nativo de ERP elimina el problema de integración porque comparte el modelo de datos del ERP. Lo que pierdes es la funcionalidad de ventas en la que invierte un CRM dedicado: gestión del pipeline de ventas, pronósticos, automatización de marketing, uso móvil por parte de los representantes de campo y la capacidad de cambiar el proceso de ventas sin una solicitud de cambio de ERP. La decisión es si el trabajo de integración cuesta menos que la capacidad de ventas que podrías tener sin esa integración.

Las integraciones punto a punto personalizadas se rompen cuando las tablas subyacentes del ERP, las APIs o los nombres de campo cambian durante una actualización, porque la integración fue diseñada para la estructura antigua. Los conectores preconstruidos evitan esto al apoyarse en la interfaz soportada por el proveedor, en lugar de la base de datos directamente, de modo que el proveedor absorbe el cambio. La prueba práctica que debes aplicar a cualquier integración que ya poseas: pregunta si lee el ERP a través de una API documentada y versionada, o mediante acceso directo a tablas. El segundo tipo es el que falla durante el fin de semana de la actualización.

Depende de lo que respaldan los datos. El estado de los pedidos y el inventario que un representante le cotiza a un cliente durante una llamada en vivo deben estar actualizados, por lo que se leen en tiempo real o casi en tiempo real. Totales históricos de facturas, ingresos agregados y el historial de la cuenta cambian lentamente y funcionan bien en una sincronización programada. El tiempo real en todas partes es costoso y genera carga en el ERP sin beneficio. Establece la frecuencia por tipo de datos, no por sistema.

Necesita un sistema de registro declarado por campo antes de que la integración entre en funcionamiento; de lo contrario, los dos sistemas se sobrescriben mutuamente en un bucle. La división habitual es que el ERP se encargue de la entidad de facturación, de los términos de crédito y de las direcciones de envío, mientras que el CRM se encarga de los contactos, las relaciones y la actividad de ventas. La pregunta más difícil es la identidad: qué hace que dos registros sean del mismo cliente. La mayoría de fabricantes y distribuidores utilizan el número de cliente del ERP como clave, y la integración lo lleva al CRM como un campo de solo lectura.

Trae lo que una persona de atención al cliente necesita para responder a una pregunta del cliente: estado del pedido, fechas de envío, historial de facturas y pagos, cotizaciones abiertas, disponibilidad de artículos. Excluye cualquier cosa que sea un detalle contable interno, datos de costo o un registro en el que nadie del CRM vaya a actuar. El fallo común es sincronizar todo porque es técnicamente posible, lo que ralentiza la integración, multiplica los puntos de conflicto y entierra los campos útiles. Si nadie puede nombrar a la persona que revisará un campo, no necesita sincronizarse.