Caso de éxito
Diez registros para un hospital, y la tabla intermedia que lo resolvió
Los registros de cliente de AliMed se multiplicaban. Un hospital podía existir diez veces en Microsoft Dynamics AX, mientras que todo su grupo contaba como un único cliente, así que nadie sabía qué centro estaba pidiendo de verdad. Rapidi conectó AX con Salesforce mediante una tabla de correspondencia que deshizo los duplicados sin tocar el ERP.
AliMed diseña y distribuye material sanitario, conocido sobre todo por sus cuñas de posicionamiento a medida, que sujetan desde una extremidad hasta el paciente entero. Tras el fracaso de un primer intento de integración, la función de mirroring de Rapidi llevó a Salesforce un listado comercial de todos los centros sanitarios de Estados Unidos aunque el origen no tenía marcas de tiempo, y una tabla SQL a medida ató varias cuentas de AX a un único registro de Salesforce. Agrupar por código postal de entrega convirtió un bloque corporativo en cuentas por centro.
Hablar con un experto en integración
La empresa
AliMed diseña y suministra productos sanitarios desde 1970, cuando Julian y Barbara Cherubini empezaron a venderlos desde su casa en Boston, no lejos de la sede actual en Dedham, Massachusetts. Los primeros productos propios, plantillas y férulas, llegaron en 1974.
A partir de ahí tiró un modelo de venta por catálogo. Los catálogos se hicieron lo bastante gruesos como para formar parte del paisaje en hospitales, centros de larga estancia, centros quirúrgicos, quirófanos y atención domiciliaria. Hoy el catálogo está en línea y sigue creciendo, igual que la base de clientes.
La empresa es conocida sobre todo por sus cuñas de posicionamiento fabricadas a medida, que controlan la posición de cualquier cosa entre una parte del cuerpo y el paciente entero, y muchas de ellas pueden pedirse en tamaños especiales. Más sobre la empresa en alimed.com.
Registros que se multiplicaban
Para dar mejor soporte al equipo comercial del que podía dar Microsoft Dynamics AX por sí solo, AliMed había comprado Microsoft CRM 2013 y contratado a un tercero para construir una integración casera con AX. A Jimmy Mathew lo contrataron para actualizar el CRM y resolver los problemas de integridad de datos que venían con él.
El mayor de esos problemas era la duplicación. Un cliente existente entraba en la web y creaba una cuenta nueva, que iba a parar a AX en vez de enlazarse con la cuenta que ya tenía. O llamaba por teléfono, atención al cliente no encontraba su ficha y se creaba otra sobre la marcha.
Teníamos un problema de calidad de datos en el sistema, y no teníamos las herramientas para resolverlo.
La integración original lo empeoraba en lugar de mejorarlo. «El CRM de Microsoft simplemente tiraba registros de AX, así que acabábamos con todos los duplicados también allí», dice Mathew. «Mi objetivo al incorporarme era conseguir un CRM y una integración que sostuvieran mejor nuestras necesidades. Todo estaba sobre la mesa.» Encontró en Salesforce la mejor respuesta para gestionar los datos de cliente, y AliMed cambió. El problema de integración se quedó exactamente donde estaba.
El intento que fracasó
Esta parte merece contarse con honestidad, porque explica por qué los requisitos finales fueron tan concretos.
El equipo de Mathew evaluó primero Jitterbit. La herramienta no contemplaba las peculiaridades de AX y no ayudaba en nada con la integridad de los datos; quería sincronizar registro a registro, que es justo lo que produce duplicados al otro lado. «En cuanto empezamos a implantar, descubrimos todas esas restricciones, y sencillamente resultó inviable —dice Mathew—. Peor aún: cuando hicimos la primera prueba, tras siete u ocho meses de diseño y desarrollo, falló estrepitosamente.»
Para entonces el equipo sabía que no quería todos los registros de cliente de AX en Salesforce, porque demasiados eran duplicados. El plan era importar «Definitive Data», un listado comercial de todos los centros sanitarios de Estados Unidos, y hacer corresponder los registros duplicados de AX con un único registro por lugar real. Eso quedaba por encima de lo que la herramienta podía hacer.
La solución
Rapidi apareció en la búsqueda de Mathew, y su función de mirroring hizo justo aquello con lo que todo lo demás había chocado: llevó los registros de Definitive Data a Salesforce aunque el origen no tenía ninguna marca de tiempo con la que sincronizar.
Alrededor de eso, el equipo definió una tabla SQL intermedia. «Podemos tener 10 cuentas en AX, y podíamos atarlas a un solo registro de la tabla intermedia», explica Mathew. Rapidi aceptó la configuración a medida sin problemas, y la operativa siguió siendo sencilla: «Basta con actualizar un registro en la tabla intermedia y dejar que Rapidi ejecute su trabajo, y el cambio llega a Salesforce sin ningún problema.»
La tabla intermedia resolvió además una herencia del ERP. AX trataba un grupo sanitario entero como un solo cliente, incluso una gran cadena de hospitales. Agrupar los registros de la tabla intermedia por código postal de entrega produjo cuentas de Salesforce con sentido al nivel de cada centro, con el histórico de pedidos colgando del centro y no de la matriz.
Esa distinción importa comercialmente. La mayoría de las decisiones de compra se toman en el propio centro, y saber qué hospital pide qué separa un esfuerzo comercial dirigido de una conjetura. Antes, un informe solo podía nombrar a la corporación dueña del sistema sanitario, tuviera los centros que tuviera.
Por el camino cayó otro cuello de botella. Traer el histórico de ventas a Salesforce mediante una vista de lista de AX funcionaba, pero «tardaba una eternidad». Los consultores de Rapidi trabajaron con el equipo en la indexación de las tablas y encontraron una ruta mejor para empujar los datos; a partir de ahí la carga histórica fue rápida.
Mirando atrás
Mathew es directo sobre lo que le diría a alguien que empieza.
Al principio estábamos centrados en la solución de integración más barata, cualquier cosa que conectara AX con Salesforce. Pero a veces lo más barato no es lo mejor. Se necesita un socio de integración que entienda las peculiaridades del ERP, como las marcas de tiempo de AX. Con Rapidi por fin intercambiamos datos exactos.
Valora también la parte poco vistosa: poder reportar un problema y verlo resuelto. «Podíamos enviar un problema por la tarde y a menudo, al llegar a la mañana siguiente, ya teníamos solución.»
Cuando se le pregunta qué haría sin ello, se ríe. «No me lo puedo imaginar. Antes de Rapidi no veíamos los errores y por tanto no podíamos arreglar los problemas nosotros mismos. Ahora tenemos muchísima visibilidad. Vemos los trabajos ejecutándose, podemos controlarlos, y tenemos todo el detalle de la actividad, errores incluidos, en los registros. No podemos volver atrás, solo hacia delante.»
¿Registros de cliente duplicados que no consigue limpiar?
Díganos qué contiene su ERP y de dónde salieron los duplicados, y le diremos si una plantilla estándar de Rapidi le cubre.