Integraciones en retail: qué hace falta para que los sistemas conectados funcionen

Los comercios suelen tener buenas razones para elegir software especializado: un ERP para diseño, producción, B2B, compras y finanzas, una solución de almacén, una plataforma de comercio electrónico, una aplicación para gestionar la relación con los clientes o incluso sistemas PIM u OMS externos.

Avelon Next puede actuar como un núcleo operativo unificado para el comercio o formar parte de un ecosistema más amplio de aplicaciones especializadas. Ambos enfoques pueden funcionar. La decisión importante es dónde se sitúan las responsabilidades y cómo gestionará la empresa los traspasos de información y operaciones entre sistemas.

Muchos de estos productos ofrecen API y conectores estándar. Son recursos valiosos: pueden proporcionar una forma probada de intercambiar información y reducir el desarrollo a medida.

Pero disponer de una conexión no determina cómo debe utilizarla tu empresa.

Pensemos en un producto que pasa de una aplicación de compras a un PIM y, después, a Avelon Next y a la tienda online. Antes de que ese flujo pueda funcionar de forma fiable, las partes deben acordar:

• ¿Qué aplicación crea el producto y le asigna su identificador?
• ¿Quién es responsable de sus variantes, tallas, colores, códigos de barras y precios?
• ¿Qué sistema puede actualizar cada campo?
• ¿Qué información debe existir antes de permitir la compra, la recepción o la venta?
• ¿Qué ocurre cuando dos aplicaciones proporcionan valores distintos?

Dos comercios que utilizan el mismo software pueden necesitar respuestas completamente diferentes. Uno crea productos durante las visitas de compra; otro los importa a partir de las confirmaciones de los proveedores. Uno recibe la mercancía de forma centralizada; otro también admite entregas directamente en las tiendas, entre otras diferencias.

Los estándares de software reducen las diferencias técnicas, pero no eliminan las diferencias entre los procesos de negocio. Por tanto, la pregunta práctica es: ¿qué parte de este conector encaja con nuestro proceso y qué queda por acordar, configurar, desarrollar y gestionar?

¿Conexiones directas o una capa de integración?

Una conexión punto a punto enlaza directamente dos aplicaciones. Una capa de integración proporciona un intermediario a través del cual las aplicaciones intercambian información. Ese intermediario puede utilizar una plataforma de integración como servicio, conocida habitualmente como iPaaS.

Ninguno de los dos enfoques es, por sí mismo, el adecuado para todos los comercios.

Una capa de integración puede reducir duplicidades y mejorar la visibilidad cuando está bien diseñada y gestionada. También se convierte en una dependencia importante: su disponibilidad y sus mecanismos de recuperación necesitan atención.

Sobre todo, no puede decidir por sí sola las reglas de negocio. Por ejemplo, no sabe de forma automática si un pedido cancelado debe liberar existencias, si todavía se puede redirigir un paquete o quién puede aprobar una diferencia en una entrega.

Una plataforma de integración proporciona herramientas. Un responsable de integración se asegura de que el proceso completo funcione.

Cambiar dónde reside una responsabilidad cambia la integración

El alcance de un proyecto de integración depende en gran medida de dónde se sitúan las responsabilidades de negocio. El enriquecimiento de productos, su creación y las operaciones de almacén implican traspasos muy distintos entre sistemas.

Cuando un PIM externo enriquece los productos

Supongamos que Avelon Next crea el producto para la operativa y un PIM externo añade descripciones, imágenes, composición y traducciones.

Los principales acuerdos se refieren a la identificación del producto, la responsabilidad sobre cada campo, la información necesaria y la publicación. Por ejemplo, el PIM podría gestionar la descripción comercial mientras Avelon gestiona el precio de venta. Ambos sistemas deben respetar esa separación.

Supongamos ahora que los papeles se invierten: un ERP crea el producto y Avelon Next lo enriquece. Surgen otras preguntas. ¿Qué campos siguen gestionándose en el ERP y cuáles pueden mantenerse en Avelon? ¿La información enriquecida vuelve al ERP, se envía directamente a la tienda online o ambas cosas? ¿Qué ocurre cuando el ERP actualiza un producto que ya se ha enriquecido en Avelon? Esas actualizaciones deben respetar la responsabilidad acordada sobre cada campo para no sobrescribir contenido mantenido en otro sistema. Cambiar dónde reside una responsabilidad cambia lo que debe hacer la integración.

Esto puede seguir suponiendo un trabajo considerable, especialmente cuando hay variantes, varios canales y reglas de aprobación complejas. Sin embargo, el retraso de una descripción suele tener un impacto operativo distinto al retraso de una reserva de existencias.

Cuando otra aplicación crea los productos

Supongamos ahora que una aplicación de compras, un ERP o un PIM crea primero el producto.

La integración también debe establecer cuándo se puede utilizar ese producto en Avelon. Una fotografía y una referencia de proveedor pueden bastar para registrar una intención de compra, pero no para recibir mercancía o venderla en caja.

Las partes deben acordar cómo se gestionan los productos incompletos, cómo se asignan los identificadores a las variantes, cómo se relacionan los códigos de barras y cómo se evita la creación de duplicados. También deben decidir qué ocurre cuando un producto llega por más de una vía, como una aplicación de compras y un mensaje EDI del proveedor.

Cuando las compras y la logística de almacén se gestionan fuera de Avelon

Esto modifica el alcance de forma mucho más significativa.

Si un ERP o un sistema de almacén externo gestiona las compras y las existencias centrales mientras Avelon gestiona la operativa de las tiendas, los procesos compartidos pueden incluir recepciones, asignaciones, reservas, preparación de pedidos, traspasos, expediciones, devoluciones y correcciones.

Imaginemos que el almacén envía cinco unidades a una tienda. La tienda recibe cuatro.

¿Dónde queda registrada la quinta unidad? ¿Quién investiga la diferencia? ¿Se pueden vender inmediatamente las cuatro unidades recibidas? ¿Qué sistema actualiza la disponibilidad para la tienda online? ¿Qué ocurre si la unidad que falta llega mañana?

Las aplicaciones deben coordinar el ciclo de vida de una operación de negocio. Intercambiar periódicamente un total de existencias no basta, por sí solo, para responder a esas preguntas.

«Existencias» y «estado» necesitan definiciones precisas

Incluso las palabras habituales pueden tener significados distintos en cada aplicación.

Las existencias pueden referirse a unidades físicamente presentes, disponibles para la venta, reservadas, en tránsito, dañadas o pendientes de revisión. Una tienda online suele necesitar una disponibilidad que refleje las reglas de venta, en lugar de un recuento de todo lo que está físicamente presente.

Del mismo modo, «recibido» puede significar que ha llegado un paquete, que se ha escaneado su contenido o que ese contenido ha superado la revisión y está disponible para la venta.

Un pedido de cliente, un traspaso, un paquete y una reserva también son entidades distintas. No tienen por qué compartir un mismo estado. Un pedido de cliente puede cancelarse mientras el paquete ya está de camino a la tienda de recogida.

El objetivo es disponer de una visión acordada y coherente de lo que está ocurriendo. Esto no exige que todas las aplicaciones muestren exactamente la misma cantidad o el mismo estado en cada instante. Sí exige significados claros, plazos de actualización aceptables y una forma de detectar y resolver diferencias.

Acordar el contrato de integración antes de desarrollar

Un contrato de integración describe qué intercambian las partes, qué significa esa información y cómo debe responder cada una. Incluye acuerdos funcionales y técnicos, no solo las condiciones comerciales entre proveedores.

Un mensaje puede ser técnicamente válido y, aun así, solicitar una acción de negocio inadecuada. Por tanto, una conexión eficaz necesita validaciones de negocio además de un transporte seguro de los datos.

Estos acuerdos también deben definir los permisos de acceso: qué aplicación puede consultar o modificar cada información y quién puede autorizar una acción correctiva.

El desarrollo es solo una parte del trabajo

Una vez aclaradas las responsabilidades, el proyecto sigue incluyendo la correspondencia entre datos, el desarrollo, la configuración y las pruebas entre las aplicaciones participantes.

El primer pedido completado correctamente es un hito importante. No constituye una prueba de aceptación completa.

Las pruebas conjuntas también deben abarcar entregas parciales, escaneos incorrectos, cancelaciones, reembolsos, tiendas sin conexión y picos de actividad comercial. ¿Qué ocurre cuando dos canales intentan reservar la última unidad? ¿Y si un sistema completa una acción, pero la confirmación nunca llega al otro? ¿Puede reanudarse el procesamiento sin duplicar un movimiento de existencias o un reembolso?

Algunos fallos pueden resolverse automáticamente. Otros requieren una nueva acción de negocio. La mercancía que ya ha salido físicamente de un almacén no puede volver simplemente restableciendo un estado en el software.

La puesta en marcha también necesita planificación. Los productos existentes, los pedidos abiertos, las reservas y la mercancía que ya está en tránsito deben incorporarse a la nueva configuración sin perder su significado ni procesarse dos veces.

Las excepciones del día a día necesitan respuestas visibles

Un buen diseño reduce las incidencias y limita su impacto. No elimina los cambios de circunstancias, los errores humanos ni las interrupciones de los servicios conectados.

Las siguientes situaciones ilustran por qué es importante tener visibilidad de la operativa.

«¿Por qué no aparece este producto en la tienda online?»

El producto puede estar incompleto, pendiente de aprobación, excluido del canal, rechazado por el sistema de destino o importado correctamente, pero todavía sin publicar.

Alguien debe poder seguir su recorrido y distinguir entre estos casos. Un panel que indica que todas las conexiones están disponibles no demuestra que el producto haya llegado al destino previsto.

«El traspaso se canceló. ¿Por qué el otro sistema registra una recepción?»

Quizá la mercancía ya se había expedido cuando se solicitó la cancelación. Quizá la cancelación nunca se aceptó. Quizá el mensaje de recepción llegó con retraso.

El historial debe mostrar qué se solicitó, qué se aceptó y qué ocurrió físicamente. Sobrescribir automáticamente un estado con el otro podría ocultar el problema real.

«La tienda ha recibido un paquete, pero el pedido del cliente está cancelado.»

La llegada del paquete sigue siendo un hecho físico. La tienda necesita instrucciones: retenerlo, devolverlo o incorporar su contenido a las existencias disponibles tras las comprobaciones oportunas.

Rechazar el mensaje de recepción sin ofrecer una solución operativa deja sin resolver tanto la gestión del paquete como su situación en las existencias.

«Todo está en verde, pero un pedido ha dejado de avanzar.»

Puede que no haya ningún mensaje fallido. Quizá nunca se generó un mensaje que debería haberse enviado o no se produjo el siguiente paso previsto.

Por tanto, la supervisión debe detectar los pasos de negocio que se retrasan y conciliar los resultados, además de informar de los errores técnicos.

La supervisión necesita personas que puedan actuar

Una supervisión útil responde a cuatro preguntas: ¿qué ha ocurrido?, ¿qué debería ocurrir a continuación?, ¿qué se ve afectado? y ¿quién debe actuar?

Esto requiere referencias trazables entre aplicaciones, mensajes comprensibles, alertas de fallos y retrasos y procedimientos seguros de recuperación. Las comparaciones periódicas de pedidos, existencias y totales financieros ayudan a detectar diferencias que pueden pasar desapercibidas al comprobar los mensajes de forma individual.

Las responsabilidades deben acordarse en tres niveles:

• El responsable del proceso de negocio en el comercio decide las reglas del proceso y resuelve las excepciones de negocio.
• El responsable de operar la integración supervisa los flujos, investiga los traspasos entre sistemas, coordina las incidencias y ejecuta las acciones de recuperación autorizadas.
• Los proveedores de las aplicaciones investigan y resuelven los problemas de sus aplicaciones y de las interfaces acordadas.

Un socio externo puede encargarse de operar las integraciones. El comercio también puede desarrollar esa capacidad internamente. En cualquier caso, externalizar la parte técnica no elimina la necesidad de contar con un responsable de negocio que pueda tomar decisiones operativas.

Para los procesos críticos, deben acordarse la cobertura de supervisión, los tiempos de respuesta, las vías de escalado y los objetivos de recuperación. La supervisión continua y el soporte con personal disponible las 24 horas son servicios distintos; la combinación necesaria depende de la actividad comercial.

Cuando un pedido pagado se queda bloqueado un sábado por la mañana, el comercio debería saber de antemano quién se hará cargo de la incidencia y cómo colaborarán las partes implicadas.

Las integraciones tienen un ciclo de vida y un coste operativo

Las aplicaciones evolucionan. Las API cambian, se añaden canales, los proveedores adoptan formatos diferentes y el comercio modifica sus procesos.

Por tanto, el presupuesto debe cubrir algo más que la conexión inicial. Debe distinguir el diseño, la implantación, las pruebas conjuntas y la puesta en marcha de los costes recurrentes de plataforma, supervisión, soporte y mantenimiento.

También debe contemplar la dedicación del propio comercio y el coste de coordinar cambios entre proveedores. La documentación, los accesos y la titularidad de los componentes de integración importan cuando cambia el proveedor de soporte.

Al comparar propuestas, conviene preguntar qué incluye realmente el alcance presupuestado: una interfaz disponible, una conexión configurada, un proceso de negocio probado y aceptado o un servicio operativo continuado. Son compromisos distintos.

Elegir el equilibrio adecuado con Avelon Next

Avelon Next puede reunir actividades comerciales conectadas en un núcleo operativo unificado, con integraciones a sistemas especializados allí donde aporten valor. También puede funcionar dentro de una arquitectura más amplia en la que las responsabilidades se compartan con aplicaciones externas.

Mantener actividades relacionadas dentro del núcleo operativo reduce el número de traspasos operativos externos que hay que definir, probar y supervisar. Sigue requiriendo implantación, supervisión y soporte. Distribuir esas actividades puede aportar funciones especializadas y una mayor libertad de elección, junto con una responsabilidad más amplia sobre las integraciones.

Un PIM externo, por ejemplo, no exige automáticamente trasladar las compras y las operaciones de almacén a otro ERP. Cada separación entre sistemas puede evaluarse por sus propias ventajas e inconvenientes.

Lo mismo ocurre con la decisión inicial de incorporar un ERP. Un nuevo responsable financiero o de TI puede aportar una experiencia valiosa con sistemas utilizados en una organización anterior. Esa experiencia puede impulsar una revisión útil, pero la conclusión de que «necesitamos un ERP» debe partir de una evaluación de las necesidades del comercio. Estar familiarizado con una aplicación o una categoría de software no constituye, por sí solo, una necesidad de negocio.

El primer paso es identificar las capacidades que realmente faltan. ¿Qué requisitos puede cubrir ya Avelon Next? ¿Cuáles necesitan una aplicación especializada y cuáles podrían resolverse mejorando la configuración o los procesos? Un comercio cuyas necesidades operativas estén cubiertas por Avelon Next puede encontrar una solución adecuada en un núcleo operativo unificado conectado a finanzas y a determinados servicios especializados. Otro puede tener necesidades de diseño, producción o B2B que justifiquen un ERP más amplio. La justificación para añadir un sistema debe explicar el valor adicional que aporta, junto con las responsabilidades de integración y operación que introduce.

La arquitectura adecuada depende de las capacidades que necesita el negocio, del valor de las aplicaciones especializadas y de la organización que vaya a encargarse de operar el conjunto.

Antes de decidir dónde situar esas responsabilidades, conviene plantear una pregunta para cada proceso importante:

¿Quién es responsable de asegurarse de que esta operación de negocio se complete correctamente, de principio a fin?

Esa respuesta es una parte esencial de una integración fiable.