Integraciones en ecommerce – todo lo que debes saber

En un proyecto de ecommerce mínimamente complejo siempre hay alguna integración que desarrollar: ERP, CRM, almacén, contabilidad… Es algo que forma parte del trabajo habitual. Por eso siempre me sorprende oír tonterías afirmaciones como estas:

• Nuestro ERP está integrado con la plataforma ABC, por tanto, si quieres desarrollar una tienda online, tienes que hacerlo en esta plataforma. Y (normalmente) con la empresa que te diremos nosotros.
• Hemos desarrollado un conector superguays entre la plataforma de ecommerce ABC y el ERP XYZ. Habrá que adaptarlo a tu empresa (tu caso es especial – siempre lo es), y el conector más la adaptación cuestan una fortuna.
• Hacer una integración es fácil, sólo hay que enviar un archivo CSV.

A ver, ni tanto, ni tan calvo: las integraciones con otros sistemas (ERP, almacén, contabilidad…) son necesarias, pero ni son tan complejas, ni tan fáciles como algunos pretenden.

Detrás de esta confusión siempre hay es un empresario que no tiene conocimientos de programación, que necesita una integración para que su negocio funcione,  y a quien se le quiere colar la propuesta que sea que convenga al vendedor. Y muchas veces cuela, con resultados desagradables (no todos a la vez, por suerte):

• Se ve forzado a utilizar una plataforma que no es la más adecuada para su proyecto, que no es la que habría escogido, y, además, tiene que hacer el proyecto con una empresa que probablemente no es especialista en ecommerce.
• Le toca pagar una factura astronómica por algo que realmente no necesita.
• Se queda con una integración deficiente, que funciona sobre el papel pero que no cumple con los requisitos más básicos.

Vamos a revisar lo que hay en una integración ecommerce, para clarificar un poco los términos, las posibilidades y el trabajo que implica. Si tienes, o planeas desarrollar, un ecommerce y vas a necesitar una integración, después de leer este artículo sabrás todo lo que necesitas para decidir lo que quieres hacer, cómo, y quien lo va a implementar.

¿Qué se puede integrar?

Primero, una integración es un modo de pasar información, de manera automática, de un programa a otro, de modo que el receptor la pueda utilizar. Puede ser un sistema de gestión comercial, un ERP, un programa de contabilidad, de gestión de stocks, de logística… Y la tienda (el sistema ecommerce) puede ser la fuente o el destino de la información.

Distinguimos dos tipos de integración:

• De servicios, en las que se accede a un servidor externo para que nos dé un servicio, como autorizar una tarjeta de crédito o registrar un email.
• De proceso de datos, en las que un sistema envía información a otro, que la procesa a partir de entonces, pero sin devolverla necesariamente al sistema original. P.e. una tienda online a un ERP o un programa de facturación, o un sistema de control de almacén a la tienda (por el stock).

Las integraciones de servicios suelen tener conectores (módulos) disponibles para las plataformas principales, ya que integrarse es su negocio.

En cambio, los sistemas empresariales (ERP, CRM…) no suelen estar tan integrados con las plataformas de ecommerce. Es decir, como se pueden integrar con casi cualquier sistema, y además suelen ser integraciones muy personalizadas, lo dejan abierto a implementar en cada caso particular. Lo que suele ser una mala noticia, porque hay que hacer un desarrollo o adaptación a medida, con el coste que comporta.

Qué información se puede integrar

En las tiendas que desarrollamos habitualmente en Imension, estos son, de largo, los movimientos de datos que se automatizan más:

• Stocks. Un sistema de control de stocks informa a la tienda del stock de cada producto, o del stock que hay disponible para la venta. Si ese stock es exclusivo para la venta online, la tienda puede llevar la cuenta de lo que vende, y sólo hace falta una actualización para evitar discrepancias. Pero si el stock también se vende por otros canales, hace falta una actualización más frecuente, para evitar vender productos que ya no están disponibles.

Para complicarlo más, en el caso de tiendas multiproveedor, puede haber varias fuentes de stock que haya que combinar.

• Precios. Un ERP puede enviar a la tienda una lista de precios completa. También puede enviar varias tarifas para varios tipos de cliente, en sistemas B2B. O se puede enviar a la tienda el coste de los productos, y que ésta calcule el precio de venta en base a unas reglas predefinidas.

Si se calculan en la tienda los precios de venta, las reglas pueden incluir detalles como el margen según el fabricante o el tipo de producto, el número de decimales a presentar, o si se redondean los precios para mostrar precios “comerciales” (14,99 € en lugar de 15 €)

• Catálogo. Los productos y las categorías se pueden crear manualmente, o automáticamente a partir de datos que vengan de un sistema donde existan. Ese sistema puede ser un ERP propio, o pueden ser archivos de proveedores. Existen todas las posibilidades, entre la creación automática (p.e. en tiendas que sólo venden con drop ship) y la creación manual masiva, mediante la carga de montones de productos usando hojas Excel.
• Pedidos. Dependiendo del número de pedidos que se reciba, se puede automatizar la exportación de los pedidos al sistema que los deba procesar – puede ser un ERP, o un operador logístico.

Si hay varios operadores posibles para entregar un pedido (porque hay varios proveedores), se puede implementar las reglas que permitan decidir qué hacer, o se puede dejar que un administrador decida qué hacer con cada pedido (o con cada uno que necesite atención).

• Clientes. Cuando se envía información de pedidos, es muy posible que un ERP necesite también la información de los clientes.

Por otra parte, en sistemas donde se dan de alta clientes por varias vías, es posible registrar los clientes nuevos automáticamente en la tienda, de modo que tengan desde el principio un acceso privilegiado, con una cuenta de cliente, sin necesidad de registrarse. O al crear o migrar la tienda a otro sistema, se puede crear todos los clientes y enviarles automáticamente sus nuevas credenciales de acceso. Y es una ocasión excelente para reforzar la relación entre la empresa y el cliente.

• Confirmación de envíos. Un ERP puede enviar a la tienda la confirmación de los envíos, para que ésta pueda a su vez enviar la confirmación al cliente, junto con el código de seguimiento de su pedido. Un operador logístico debe enviar esta confirmación, obligatoriamente (o el sistema queda cojo).

Qué hay que tener en cuenta

Puestos a preparar una integración, y una vez decidida la información que hay que intercambiar, hay una serie de aspectos a considerar para cada tipo de información.

Vía de intercambio (transporte de los datos)

Como ambos sistemas suelen estar en servidores diferentes, debe haber una manera de enviar los datos de uno a otro. Hay dos sistemas principales:

• FTP: envío de archivos mediante el venerable, antiguo y muy pasado protocolo FTP, pero que aguanta el paso del tiempo porque es súper útil.

El inconveniente del FTP es que no da confirmación de que se haya procesado el mensaje, ni siquiera de que se haya recibido. Es adecuado para mensajes grandes, o que no requieren tiempo real. Los datos suelen ir en formato de texto (CSV) o XML.

• Web Service: es un mensaje que se lanza en tiempo real (cuando pasa la cosa), y los dos servidores hablan directamente. Se hace usando el protocolo HTTP o HTTPS, y suele llevar datos en formato XML o JSON. Es más complejo (léase “caro”) que usar FTP, pero mucho más “cool”, por eso a muchos programadores les gusta tanto. Para mí es un método a evitar, salvo que el tiempo real sea necesario.
• Cintas DAT, memorias USB, emails… Sin comentarios. Si alguien te sugiere usar algo así, busca a otro.
• Texto. Son archivos de texto normal y corriente, normalmente en formato CSV o similar – un registro por línea, con una serie de campos predefinidos (como una hoja Excel). Los valores se separan con un carácter especial, p.e. una coma (de donde viene el nombre CSV – valores separados con coma, o su equivalente en inglés).

Formato de los mensajes

Un CSV con punto y coma como separador se abre directamente en Excel, lo que lo hace un formato especialmente cómodo para trabajar, porque permite revisar los datos fácilmente.

• XML. Es un formato pensado para que lo entienda un ordenador, pero muy redundante (el tamaño de los datos puede aumentar por 2 o 3 perfectamente) e imposible de leer. Tiene la ventaja de que no está limitado a un número de valores fijo, sino que puede tener estructuras más complejas. Pero si no se va a aprovechar esta ventaja, es mejor usar archivos CSV, son mucho más fáciles de generar y procesar.
• DB, SQL, y demás: son malas ideas que se han ocurrido a alguien en un mal momento. Es como hacer una integración con memorias USB, simplemente no lo hagas.

Frecuencia

¿Cuándo necesitas que los datos lleguen a destino? Hay varias posibilidades.

• En tiempo real. Pasa la cosa, y ¡zas! se envían los datos inmediatamente al servidor que los tiene que procesar. Es lo mejor, especialmente si influye en la experiencia de uso del cliente. Pero es bastante más complejo (caro) que hacerlo en batch, así que es mejor hacerlo sólo cuando sea necesario.
• Por tandas (en batch). A horas programadas, se recoge toda la información que se ha generado hasta ese momento y se envía de golpe. P.e. puede ser una actualización de stock completa por la noche, o envío de los pedidos recibidos a las 12:05 de la mañana…
• A horas programadas, con bastante frecuencia. Es el sistema batch, pero aumentando la frecuencia, de modo que el tiempo que pasa entre que se produce el hecho y que se envía el mensaje se reduce mucho. P.e. se puede enviar los pedidos recibidos, o consultar las salidas de stock, cada 5 minutos. Esto lo acerca basrante a las actualizaciones en tiempo real, sin entrar en la complejidad de trabajar con web services.

Tipo de actualización

Dependiendo sobre todo de la frecuencia, hay dos tipos de actualizaciones de datos.

• Parcial: se envía solamente los datos que han cambiado desde el envío anterior. Actualizaciones puntuales de stock, pedidos concretos…
• Completa: se envía todo – el stock de todos los productos, todos los precios, todos los pedidos recibidos durante el día… Puede ser un solo envío masivo, o un envío para recapitular envíos parciales anteriores.

Qué más hay que tener en cuenta

Llegamos a los detalles escabrosos: no son necesarios para que la integración funcione, pero está casi garantizado que, sin esto, va a ser un desastre.

Trazabilidad

En todo momento debe ser posible ver lo que ha pasado:

• Cuál es el estado del sistema
• Qué mensajes se han enviado
• Qué mensajes han fallado
• Qué se ha salido de la norma

Debe ser posible revisar copias de los mensajes y logs de funcionamiento y saber lo que ha pasado: por qué ha salido un cierto dato, o no se ha enviado un pedido, por qué se ha rechazado un envío… Debe haber trazabilidad completa de toda la información que circula por la integración.

La alternativa es que, cuando algo falla (y algo va a fallar, siempre), no hay manera de arreglarlo, de ver que ha pasado, tal vez ni siquiera ver si ha pasado algo.

Por mi experiencia, los problemas vienen más por una trazabilidad deficiente que por un error en la integración. El error suele ser fácil de corregir… si se puede identificar, porque tenemos los datos para hacerlo (la trazabilidad).

Flexibilidad y gestión de incidencias

Cuando pasa algo inesperado, el sistema debe permitir corregirlo. Qué puede fallar depende de cada caso, pero al menos debería ser posible cancelar un envío y volverlo a hacer (habiendo corregido lo que sea que haya fallado).

Conclusión

Sé que es un repaso muy rápido de lo que es una integración y que falta muchísima información. Pero hemos visto los puntos más importantes, lo que queda son detalles de implementación que se puede dejar a los informáticos. Al final, lo que pretendo es que, quien necesite hacer la integración, sepa que puede enviar mensajes completos y actualizaciones parciales, en tiempo real o en batch, que hay vida más allá de los web services, y que hay cosas que simplemente no se hacen.