Procesamiento de datos en tiempo real, un requisito omnicanal

La noción de omnicanalidad ya está establecida. Los clientes deben poder completar el proceso de compra independientemente del canal o medio. Así, la digitalización de toda la información y la comunicación instantánea son elementos esenciales para lograr este objetivo. Esto tiene implicaciones significativas para TI y su organización, así como para los métodos de procesamiento de datos.

Tratamiento de datos

En primer lugar, para no ofender a nuestros contactos informáticos, debemos ser claros sobre lo que entendemos por tiempo real.

El tiempo real no existe

Simplemente porque Datase transporta, se procesa y se integra. El tiempo necesario para estas operaciones puede variar de un milisegundo a un minuto, o incluso una hora para las operaciones de integración.

Por lo tanto, adoptaremos el concepto de flujo de agua " para describir la gestión de Data. Esta noción imaginaria se basa en el procesamiento impulsado por eventos. En otras palabras, el procesamiento se desencadena a partir de un evento identificado.

Por ejemplo:

  • cuando se pide a una aplicación empresarial que genere y cargue un archivo de datos, se trata de un evento.
  • detectamos que un usuario ha lanzado una solicitud, se trata de un evento.

Se trata de la inmediatez del tratamiento de los datos en el momento de su creación, frente al tratamiento "por lotes", que recoge una gran cantidad de datos y los pone en espera antes de organizarlos, transferirlos, tratarlos e integrarlos. Esto implica un retraso que impedirá sistemáticamente la inmediatez con la que soñamos.

Antes y después de la cadena de valor de los datos: los procesos empresariales en el punto de mira

El punto de venta genera tickets de venta sobre la marcha. Estas ventas pueden generarse mediante terminales de pago, herramientas móviles, quioscos o cajas virtuales. Estas ventas deben procesarse y transmitirse al back office, para que informar sobre el volumen de negocio, los impuestos, declarar las existencias vendidas (y, por tanto, las salidas), calcular los márgenes, controlar los pagos bancarios, analizar el comportamiento decompra de los clientes (cotizados o anónimos), garantizar la correcta aplicación de los precios de venta al público y de las campañas promocionales, etc.

Muchos minoristas siguen procesando esta información al final del día (o del periodo) tras el cierre. Sin embargo, esta necesidad ha evolucionado en los GSA y GSS (grandes superficies de alimentación y tiendas especializadas) con el desarrollo de la web y elenfoque omnicanal.
Hoy en día, los datos de ventas se procesan a medida que llegan y se envían a sistemas centrales (ERP, CLOUD, DATAHUB, etc. ). Además, esta información se comparte inmediatamente con todo el ecosistema de aplicaciones comerciales.
Estos cambios han tenido un impacto directo en toda la organización informática. Las aplicaciones, los flujos de trabajo y su procesamiento han tenido que evolucionar. Concretamente, toda la arquitectura del sistema de información ha tenido que adaptarse.

Tomemos el caso de la gestión de las existencias disponibles:

El acontecimiento "venta de una pieza", ya sea en un punto de venta, en un autoservicio o en un sitio de comercio electrónico, debe compartirse inmediatamente con el flujo ascendente, la web y los demás puntos de venta de la cadena. Las operaciones y tareas derivadas de este evento permiten informar inmediatamente a los empleados y clientes de la empresa, en particular sobre los siguientes puntos:

  • actualizar las existencias en el punto de venta para permitir la reposición automática,
  • el sitio de comercio electrónico debe actualizar las existencias para los clientes que utilicen click & collect o e-reserva, de modo que puedan ser dirigidos al punto de venta (o canal de venta) correcto,
  • ¡el Drive que comparte sus acciones con el supermercado!

Está claro que todos los procesos empresariales se ven afectados.

Suministros, logística, marketing, relaciones con los clientes... todos tendrán que adaptar y mejorar sus procesos para trabajar con datos que evolucionan muy rápidamente a lo largo del día.

También podríamos haber mencionado :

  • Inteligencia empresarial: habrá que modificar todos los universos y sus indicadores de rendimiento,
  • comunicación con los clientes: se lanzarán campañas de comunicación específicas de forma más oportuna y pertinente,
  • marketing: los resultados de una campaña de promoción se conocerán inmediatamente,
  • logística: los suministros se activarán inmediatamente, lo que permitirá una mayor agilidad en la planificación de las entregas.

En resumen, procesar la información "en el momento en que se produce" significa que la información relevante para la toma de decisiones está disponible sin demora. Tanto para el cliente como para la empresa.

¿Cómo configurar una arquitectura de aplicaciones informáticas adaptada al tratamiento de datos en "tiempo real"?

Entendemos que los sistemas de bases de datos y las arquitecturas de flujo de trabajo tradicionales ya no pueden satisfacer las exigencias impuestas por Big Data o los datos en flujo. En comparación con el modo batch, el "tiempo real" abarcará todo el procesamiento de datos que requiera un breve tiempo de cálculo o una fuerte necesidad de información.

Por ejemplo: actualización del repositorio, liquidación de promociones, informes de facturación o existencias, etc.

En este caso, se dirá que los resultados del tratamiento de datos son "calientes" para el tratamiento en tiempo real y "fríos" para el tratamiento por lotes. El impacto es estructural y requiere la creación de una arquitectura lambda.

La arquitectura "Lambda" es una superposición de capas: mantenemos una capa "batch", añadimos una capa "tiempo real" y una capa "servicios", es decir, :

  • la capa "batch" procesará flujos de datos más grandes para los que se requieran tiempos de procesamiento más largos (por ejemplo, inicialización de repositorios),
  • la capa "en tiempo real" (Speed Layer) tratará los datos a medida que vayan llegando. Menos voluminosos pero en flujo constante y regular (por ejemplo, recibos de caja),
  • la capa "servicios" almacena, integra, agrega y muestra datos (ETL, ERP, DATAHUB, etc.).

En resumen, la arquitectura "Lambda" consiste esencialmente en implementar dos procesos dentro del mismo sistema de análisis de datos:

  • un proceso de tratamiento de datos por lotes
  • un proceso de análisis de datos en tiempo real (a medida que se producen)

Esta arquitectura es posible gracias a la tecnología KAFKA. Apache Kafka es una aplicación de código abierto para el tratamiento de flujos de datos y la puesta en cola de mensajes, capaz de procesar hasta varios millones de mensajes por segundo procedentes de distintos productores y encaminarlos a varios consumidores. Existen otras soluciones para satisfacer estas necesidades (a través de una API, por ejemplo, pero esa es otra historia).

Como puede ver, es toda la arquitectura, e incluso la organización, de la SI la que se ve afectada.

La necesidad de compartir información nos obliga a actualizar nuestros sistemas a esta solución de procesamiento de flujos de datos. Porque responde a las necesidades de nuestro negocio y a los retos del futuro.

En Univers Retail, nuestra misión es dar un paso atrás para entender y comprender los cambios necesarios con el fin de ponerlos en práctica. Esto significa trabajar con los equipos empresariales para ayudarles a implantar proyectos, soluciones y procesos. También es importante apoyarles en los cambios cotidianos para que todos puedan hacer realidad la promesa del tiempo real.

Por Fetheddine Kezouit

¿Tiene un proyecto relacionado con Data o ¿le gustaría hablar con uno de nuestros expertos?