 El Corte Inglés needs no introduction. It's the most well-known retailer in Spain. It manages around 10 million different items in a vast catalogue. Each product can be promoted in some way. Every promotion needs to be tracked and managed. And with 24 sales channels, this needs to be done in real time. It's a massive challenge, as you can imagine, by one to which they believe they have the solution. To explain us how they do it, we have with us Juan Carlos Mondejar, business solution manager, and Miguel Ángel París, architect or software architect at El Corte Inglés. Welcome. Bienvenidos. Miguel Ángel and Carlos, here they are. How are you guys, ¿cómo estáis? Yeah, I believe, creo que van a hacer su presentación en español. Yo se he presentado en inglés puesto que esto es una conferencia en inglés para todo el mundo. Como veis, el español lo hago muchísimo mejor, así que no tengo ningún problema. Recordad, I'm going to remind the audience you can send your questions both in English or in Spanish. Podéis preguntar en inglés y en español. Yo se las enviaré a ellos en el idioma que venga. Lo traduciré lo que haga falta. Aquí lo tenemos todo pensado. Así que, Miguel Ángel, Carlos, cuando estáis listos estamos deseando escucharos. Gracias. Gracias, Elena, por la introducción. Buenas tardes noches a todos y agradecer también en primer lugar a la organización la oportunidad que nos subrenda de compartir con los asistentes nuestra experiencia en este campo. Bueno, estamos aquí Miguel Ángel Padís que forma parte del Centro de Ingeniería de Software. Es el arquitecto y responsable entre otras muchas cosas del equipo técnico que da cobertura al sistema promocional corporativo. Y yo soy Juan Carlos Mondejar de la Oficina de Proyectos, responsable del Producto Promocional del Sistema Promocional que es como denominamos el enfoque que le hemos dado a todo el ecosistema de sistemas alrededor del sistema promocional. Vamos a empezar con la agenda. En principio esto es un poco la agenda de lo que vamos a ir viendo. Bueno, poneros un poco en contesto y volumetría que para contextualizar el escenario en que se produce nuestro negocio y nuestro aterrizaje en el mundo de las bases de datos grafos y en general y en Neo4j en particular. Vamos a acercarnos un poco a contados porque la necesidad de negocio que nos llevó porque nos obligó a buscar soluciones para diferentes problemas que teníamos en la compañía. Los contaremos un poco en las fases iniciales del proyecto inicial de Neo4j y un pequeño resumen del enfoque organizativo que le dimos al proyecto. A partir de aquí Miguel Ágel nos centrará en el problema que intentábamos resolver. Nos mostrará la arquitectura de la solución tanto que teníamos el legacy que teníamos en la arquitectura previa de la que partíamos y la nueva arquitectura que hemos montado alrededor de este producto. Y os presentaremos los resultados obtenidos así como unas mediciones sobre un cuantificadas datos cuantitativos para que veáis un poco los resultados que hemos tenido con la utilización del Neo4j para solucionar esta problemática. Además os contaremos un poco una vez que ya hemos finalizado las primeras fases de nuestro proyecto o es donde nos encontramos y hacia dónde vamos, es decir, donde hemos empezado a ver que podemos ir ampliando el uso de esta tecnología. Os contaremos un resumen final de otras experiencias y a partir de aquí las dudas y preguntas que puedan surgir. Bueno, como ha hecho Elena, el Cortingless no me voy a extender mucho en la presentación del Cortingless. Los datos que veis aquí pues es un poco la cifra de negocio que se mueve para que veamos un poco la volumetría que estamos, el número de empleados. Y empezamos aquí a contar a partir de las cosas que ya nos empiezan a afectar al problema que luego vamos a ver. Es decir, el Cortingless maneja un catálogo de unas 10 millones de referencias y tiene unos 900 centros, sobre todo en el sector de retail centrados, que son parte de los Varemos que tenemos que utilizar para dar solución al problema que tenemos que ver. Como nos vamos a centrar en promociones y vamos a hablar del tema promocional, pues bueno, el Cortingless, ya es conocido por todos, tiene un volumen de promociones grande, son alrededor de unos 6.700 o de ejercicio que se componen lo que nos lleva a tener unas 4.500 acciones vigentes cada día. Es decir, cada día en el Cortingless de diferentes tamaños, de diferentes volúmenes, tenemos 4.500 acciones promocionales que están dando beneficios a nuestros clientes. Estos acciones se componen de una serie de referencias que en algún momento en promociones muy puntuales llegan a representar cerca de 2 millones de referencias afectadas por una misma promoción. Nos lleva y ya vamos a entrar un poco más bajando el zoom hacia donde vamos a ir al problema. Esto nos lleva a mover diariamente unos 150 millones de referencias alrededor del mundo promocional, es decir, todos los artículos que están en una promoción pues nos obligan a mover volúmenes cercanos a los 150 millones. Esto, si queremos estudificarlo, nos llevaría a que tendríamos más de mil millones de filas en el histórico, aquí he puesto el histórico de 5 meses, y nos obliga a trabajar en algún momento con ficheros de más de 8 millones de filas y de más de 1 giga por cada uno de los ficheros. Estos datos quedados, esto es lo que vamos a ver luego, y están en el origen del problema que teníamos que resolver y por el que empezamos a buscar algún tipo de tecnología que nos permitiera hacerlo. ¿Dónde está el origen del problema? Los sistemas operacionales de promociones definen a unos niveles muy altos de la jerarquía de mercancía. El problema que vamos a atacar es lo que nosotros llamamos explosionado, en otros sitios se conoce como planado, el flattener, y lo que obliga a esto es que cuando estamos definiendo promociones estamos en un nivel muy alto de definición para facilitar la definición, para evitarnos que tengamos problemas y que sea relativamente sencillo trabajar en esas definiciones y sean más ágiles ante cambios, lo que estamos haciendo es trabajar a niveles altos de la jerarquía promocional, no a nivel referencia, sino a niveles de familias, a nivel de departamentos, eso permite unas definiciones rápidas, ágiles, pero que luego es necesario aplanar, extender a nivel referencia. ¿Para qué? Para que los frontales, en este caso he puesto aquí alguno de los frontales que pueden usar o son consumidores o clientes de esta necesidad, bien sean los frontales web, bien sean los frontales de VI o de inteligencia de clientes, pues puedan mover y presentar los datos con fluidez y con bastante facilidad. Toda la agilidad que necesitamos que tenemos que tener en el canal web, pues tenemos que entre comillas por darle un nombre, precocinarlo, para que luego los buscados de las páginas del listado de productos enseñen estos datos de forma rápida, ágil, cuando te estás teniendo millones de peticiones o decenas de miles de peticiones por segundo. ¿Cómo lo teníamos resuelto? Pues como podéis comprender, todo esto nos obligaba a tener un proceso batch, pesado, complejo y que, bueno, era muy difícil de mover todos los ficheros, trabajar con grandes ficheros nos obligaba a mover grandes volúmenes de información que hacían que no fuéramos ágiles ante cambios y que además no fuéramos muy evolucionables de cada poder escalar esta solución, a afrontar el reto de nuevas necesidades de la compañía y además nos tenía en un sistema que lo teníamos aislado que no era muy partícipe del resto del flujo promocional. Entonces, por eso, digamos, el NEO llegó a nuestra compañía un poco buscando solución a estas necesidades en concreto. Teníamos un problema concreto que queríamos resolver, que necesitaba mucho volumen, lo contará ahora Miguel Ángel en más detalle y entonces planteamos un proceso, un proyecto en varias fases. En una primera fase, planteamos lo que llamábamos una carga full, que lo que intentaba era reproducir exactamente el modelo que teníamos hasta ese momento para no afectar a los consumidores y que el cambio y la introducción de la tecnología fuera lo más sencillo posible. En la compañía lo que intentamos desde el primer momento fue, en nuestra primera fase, reproducir y dar la misma solución que teníamos hasta ese momento. Entonces, después ya planteamos una segunda fase dentro de este proyecto en el que lo que íbamos a intentar es empezar a hacer lo que llamamos la carga incremental. La carga incremental es el proceso por el cual ingestamos los datos desde los sistemas corporativos, la codificación y precios de la compañía, sistemas donde está el branding de la compañía. Todos esos procesos, en vez de hacer un primer explosionado completo de todo ese volumen que hemos comentado antes de 10 millones de filas, de más de 10 millones de artículos, pues en la primera fase lo reproducíamos entero y lo hacíamos todos los días. En una segunda fase lo que pasamos a hacerlo fue de manera incremental. Según se producían los cambios. La tercera fase del proyecto fue empezar a dotar al sistema desplocionado y al neo de una PIB de servicios para, de alguna manera, poder explotar sus datos y hacer uso de los datos que empezábamos a tener dentro del Neo4j. Para pasar ya en una cuarta fase al explosionado incremental que es donde era el punto donde realmente queríamos ir. Es decir, en vez de funcionar a base de grandes volúmenes de información, millones de datos y de filas moviéndose continuamente por las redes, pues nos fuimos a un modelo en el que lo que queríamos es que los cambios se trasladaran a los consumidores de forma inmediata. Según se produce para acercarnos lo más posible al real time. Teníamos una nueva fase que era la quinta fase para solucionar el tema del explosionado y la parte de histórico y futuro. Esto es, hay algunos de los consumidores que lo que necesitan es en los datos de las promociones no a día actual, sino a día anterior o a futuro, como puede ser el caso etiquetado, en el que lo que pretendemos es etiquetar lo que va a entrar en promoción en los próximos días. Y finalmente teníamos la última fase que era la de incorporar nuevas tipologías que teníamos ahí en vuelo, pues incorporarlas al sistema que estábamos montando con el Neo4j. Esta era el proyecto inicial y ahora Miguel Ángel comenzará a contaros un poco más en detalle cómo ha sido la arquitectura y cómo ha sido el desarrollo del proyecto. Gracias Juan Carlos. Yo lo que voy a comentaros ahora es desde el punto de vista técnica del proyecto principalmente cuál era el problema resolver y la arquitectura que hemos definido para resolver ese problema. Entonces en la siguiente diapositiva lo que podemos ver es centrarnos en tres puntos, Juan Carlos, en tres puntos importantes que son parte del problema resolver y del punto de vista técnico. El principal es, como ya ha comentado Juan Carlos, la volumetría es un problema que siempre ha estado presente en nuestra empresa debido principalmente a la diversidad y amplitud de nuestro catálogo. Uno de los principios corporativos es ofrecer a nuestros clientes una muy amplia oferta de artículos. La volumetría de nuestro negocio siempre ha supuesto un handicap en la resolución de todos nuestros problemas a nivel técnico y ha provocado que productos que han funcionado en otras empresas de nuestro sector pues no funcionan sin el nuestro. Llevamos también varios años en que la política promocional ha cambiado. Hemos pasado de un modelo donde las promociones aplicaban en fechas fijas durante el año con una importante separación del tiempo entre ellas o un modelo donde se están intercalando nuevas fechas y nuevos escenarios de forma que siente. Estos nuevos modelos, estos escenarios, lo que han provocado es solo a par de periodos, unos con otros. Lo que ha incrementado la cantidad y la volatilidad de las promociones que está ofreciendo el Corte Inglés. Adicionalmente a este problema nos encontramos actualizando constantemente nuestras mecánicas de cálculo. Incluimos nuevas variables, nuevas dimensiones de cálculo, totalmente el cliente. Este incremento de variables obviamente penaliza de manera directa cualquier motor de cálculo que hemos estado analizando y por eso es muy importante para nosotros tener una solución que tenga en cuenta pues este posible incremento en estos attributes. Finalmente también destacar que la reducción del tiempo de transición de las promociones o la reducción del tiempo para tener disponible la información nos está obligando a adaptar a nuestros sistemas a escenarios de servicio de 24x7. Todos sabemos que el reciente aumento de la venta online, ha supuesto, pues tener que adaptarnos a reducir al mínimo los tiempos de proceso batch nocturno y tener muchísima más agilidad para tener disponible la información, para ofrecerse a todos los canales sin tener que esperar a procesar la promocion. En la siguiente día positiva podemos ver que para realizar el expresionado en la solución que tenemos actualmente tenemos más de 30 imágenes como las que se están mostrando durante donde hemos tenido que crear un escenso sistema en COBOL y LV2. Hay más de 50 procesos, varias bases de datos involucradas, multitud de tablas, multitud de fixeros intermedios, crecimiento de la volumetría que os estaba comentando ha provocado que este sistema en otro tiempo quedaba unos tiempos aceptables, ahora estamos en seis horas de media de procesamiento. También estamos sujetos a tener una dependencia de estos procesos batch. Hay unos que generan la información tanto de actualización de cambios de catálogo como actualización de cambios en nuestras promociones y nos obliga actualmente a realizar dos ejecuciones en el día. La primera de ellas es la que tenemos que tener disponible para tener la información a última hora del día, a las 12 de la noche, cuando se produce el cambio y la segunda ejecución ya se recoge los cambios de ese día, pero no estará disponible esta información hasta primera hora de la mañana. Además, en una situación como esta, cualquier error nos provocaba que no fuese posible volver a procesar y tener la información corregida durante ese día. Estaba claro que teníamos que buscar la alternativa, al final esta alternativa nos tenía que permitir resolver estos puntos, fue una solución de futuro y nos permitía incorporar nuevos requerimientos, como comentaba Juan Carlos, que habíamos dejado en Estalmán. Empezamos a revisar soluciones. Una solución de planamiento de la información que nos permitía hacer son más rápidos, pero contrapartida incluía nuevos procesos para realizar el planamiento. Este sistema realmente ya lo tenemos implementado para solucionar cálculos en tiempo real, por lo que las limitaciones que tenemos con este proceso son conocidas por nosotros y queríamos explorarnos las soluciones. Otra opción que estuvimos viendo es la generación de punteros con la información mínima, en realidad hacer a realizar el planamiento pero sin tener que hacer el cálculo completo de la información, sino solo una parte para mejorar los accesos que tendríamos esa información. También sabemos que nos obligaría a tener procesos y mantener esos punteros. Dimos también una prueba de concepto, con bases de datos que trabajaban con la información en memoria. De esta forma nos olvidábamos de todo este tema de la planamiento y podíamos realizar el procedimiento en tiempo real. Teníamos que probar la información para almacenerla en la base de datos y luego volver a explotarla con cruces join o similares parecidas a sentencias SQL. La verdad que este escenario funcionó muy bien, hasta que se aumentó la volumetría y la convergía de las relaciones, momentos en que los tiempos empezaron a crecer por encima de lo que necesitábamos. Otro punto que nos convencía de la solución es que la lógica del cálculo la teníamos que realizar o tener la información, lo que suponía un impedimento para incluir nuevos requisitos de forma sencilla. En la imagen de la arquitectura podemos ver que la solución basada en grafos tiene como motor central lo que es Neo4j. En esta solución lo que nos damos la atención fue que la aproximación era completamente diferente a lo que habíamos hecho hasta ahora a no basarse en base de datos relacionales o tener que hacer al planamiento de la información. Lo primero que hicimos con ello fue una prueba de concepto para ver posibilidades. Nuestro objetivo es metimos información de catálogo muchísima más de la que podríamos manejar, promociones en crudo de la misma manera y intentamos hacer esos cruces y hacer el explosionado. La verdad que los tiempos del proceso de cálculo fueron descaso a minutos, con lo cual la solución fue bastante esperanzadora. También hicimos alguna prueba donde estuvimos probando cestas de periodos de clientes de gran número de artículos para ver qué promociones había que aplicarlas y la verdad que aquí también el resultado también fue sorprendente, obteníamos tiempos inferiores a un segundo. Con estos datos decidimos pues ir por esta solución. Lo primero que hicimos es plantear un punto de partida para aislar la solución en una región de la nube. El objetivo era poder modificar la arquitectura, las máquinas, los procesos, cualquier necesidad que tuviéramos para adaptarnos a tener estos tiempos de procesamiento tan exigentes que estábamos buscando. También uno de los objetivos que teníamos, una de las ventajas que teníamos era permitir realizar mediciones de consumos de forma fácil. La arquitectura del motor de explosionado, la zona central de la imagen donde se pueden ver la base de datos Neo4j, rodeado en una serie de elementos, la hemos creado en dos capas. La primera capa son un grupo de agentes Java con distintos roles que se encargan de la preparación de la información para su ingesta en la Neo4j y la obtención de información calculada del grafo para su envío a los distintos consumidores, en formatos, de ficheros, eventos, mensajes. Para la comunicación de estos agentes y su control, nos hemos basado en una solución de mensajería. Lo que intercambia a los agentes son mensajes de control. La segunda capa son los prune de Java que se ha añadido a la Neo4j para realizar la creación del grafo, suman tenimiento y realizar los cálculos sobre el grafo, lo que sería el explosionado. Esta capa es la que trabaja directamente con las bases de datos y además se comunica con los agentes Java para realizar el procesamiento final. Para poder aplicar esta arquitectura, pues, teníamos varios retos. El primero, pues, la información que teníamos son premis y teníamos que moverla a un sitio cercano a la base de datos. Decidimos replicar la información con una herramienta de captura de datos en origen. Esta generaba una réplica que estaría disponible prácticamente en tiempo real, para que esa información pudiese ser ingestada por esa primera capa en el grafo. Segundo, teníamos que mover la información una vez recalculada, una vez calculada, el explosionado, para que estar disponible en los sistemas que lo necesitaban. Definimos dos maneras de compartir la información. Otra vez de ficheros, con la información completa para aquellos sistemas que actualmente ya lo estaban consumiendo de nuestro sistema legacy, y no podrían adaptarse a la segunda opción, que es enviar esta información en tu pico de carca de una forma incremental en tiempo casi real. También necesitamos disponer un registro de cambios, para poder aplicarlos en tiempo real en el grafo. Esta registro le hemos obtenido de los movimientos que detecta la herramienta de captura de cambios. A partir de este registro, lo que podemos aplicar los cambios al grafo de cada movimiento que se produce en la base de datos origenes prácticamente en tiempo real. Esto quiere decir que la información del grafo la tenemos actualizada en todo momento. Y finalmente, uno de los grandes problemas a los que nos enfrentamos aquí era validar que la información que se estaba generando era correcta, era igual que la que se estaba exponiendo ahora mismo, para intentar impactar lo menos posible en el resto de los sistemas que estaban actualmente consumiendo toda esa información. Para esto, pues se crea una serie de procesos ad hoc dedicados al proyecto para que realizar comparativas, pero fichero que se generaban en cada uno de los entornos, y validar de esta manera todos los casos que se producen. En la siguiente imagen, podemos ver uno de los éxitos que consideramos del proyecto, que es el diseño y la creación del grafo. Con respecto al grafo, estuvimos analizando cuál es la mejor manera para definir la estructura jerárquica y de relación del modelo. Vimos que es importante diseñar el grafo orientado a cómo se va a cargar y cómo se va a obtener la información. Otro de los requisitos que teníamos que cubrir era que fósemos capaces de ampliar la jerarquía y las dimensiones, incluyendo nuevos nodos y poder ampliar las relaciones de los nodos que se habían creado otros que ya existían. También estuvimos viendo que esto es lo que nos provocaba, es que en las nuevas fases del proyecto teníamos que revisar nuestro modelo para ver si era tan efectivo con los nuevos nodos y las nuevas relaciones como lo era anteriormente. Durante todas estas pruebas y escenarios de revisión, la conclusión a la que llegamos es que la definición que teníamos encajada de forma natural en lo que nos permite hacer esta tecnología. Esto que significa, significa que los resultados que estamos obteniendo eran sólidos y nos daban la tranquilidad de que la solución no se iba a permitir evolucionar sin problemas. Una ventaja nativa de esta tecnología es que el cálculo de promoción la hacemos en dos partes diferenciadas en el tema. La primera parte es la creación y el mantenimiento del grafo. Es necesario aplicar parte de la lógica para generar los nodos y sus relaciones. De este modo se realiza de forma natural parte de la operación necesaria para el resultado completo. La segunda parte es la extracción del resultado a partir del modelo. Es un proceso que se realiza de forma muy ágil y nos permite conseguir la mejora en tiempos que hemos estado comentando anteriormente. Esto nos puede llevar a la siguiente imagen donde podemos ver que los resultados obtenidos pues al final es que cuando íbamos avanzando en el proyecto estuvimos esperando tener un motor único de cálculo que nos permitiera unificar el cálculo de las operaciones relacionadas. De esta manera tendríamos todas las ventajas de tener un punto único para todos los sistemas, lo que nos ayudaría en la aplicación de la onnicanalidad y la evolución de nuestro sistema promocional. Otro punto es seguir con el conocimiento explícito. Al disponer el grafo creado la información de la promoción se encuentra definida de manera explícita. Tener esta forma la información nos permita analizarla y entender de una forma más simple y rápida la situación que tenemos en un punto determinado de nuestro sistema promocional. También nos permitirá que el conocimiento se encuentra centralizado en un único punto y no distribuido como está actualmente entre los distintos procesos que componen toda esta ecosistema. Esta información recoge parte de nuestro conocimiento y de la lógica para la aplicación de las promociones con respecto al catálogo, su jerarquía, sus atributos y las variables de definición por lo cierto. Otro punto importante es que nos permitía ir a una tecnología uniforme. Sustituyamos otros procesos actualmente del entorno legacy, de aquel entorno que habíamos creado unificando la tecnología del sistema promocional y simplifica obviamente el mantenimiento y la evolución del propio sistema. Ahora todo nuestro sistema está basado en diferentes procesos de tecnología. Otro punto es la simplificación de los procesos. Como os he comentado, teníamos más de 100 procesos. Estos son decenas de procesos y hemos llegado a bajar esto a menos de una decena. No parece que son siete los procesos que tenemos. También hemos pasado de cerca de un centro de retablas a menos de decenas de ficheros finales y dos tópicos casca. Otro de los puntos que tiene nuestra empresa es la racionalización de la utilización del sistema HOS, del ZOS, especialmente para aquellos procesos que migrar a otra tecnología sea una mejora de la situación actual. Con esta solución que hemos implementado y que hemos conseguido dar alguna pasión en esta pandemia. Y finalmente algo que hemos obtenido básicamente de la arquitectura en cloud. Al haber agrupado los procesos en la nube, pues podemos hacer un seguimiento de los costes, de este proceso de un modo directo. Uno de los siguientes puntos que tendremos a abordar es un estudio de costes para optimizar los consumos de esta forma. La siguiente día positiva. Vale. Pues aquí a partir de todos gracias Miguel. A partir de todo lo que nos ha ido contando y todo el proceso montado y toda la arquitectura. Pues aquí nos estamos presentando un poco con datos ya reales. ¿Cuál es exactamente la diferencia o qué fue el beneficio que nos aportó la utilización de esta nueva tecnología? En el primero, cuando veis el tema de reducir tiempo de proceso, aquí estamos comparando exactamente lo mismo que teníamos con la tecnología antigua, con toda la parte legacy que nos ha contado Miguel Ángel. Entonces, pasamos de un proceso, todas esas diapositivas que hemos puesto al principio, de un proceso que nos dudaba 6 horas, pasamos a explosionar en 45 minutos. Esta fue la primera medición que hicimos para ver si realmente la utilización de DNEO nos aportaba un valor añadido y nos ayudaba a tomar la decisión de seguir adelante en la implementación de DNEO. Lo primero que quisimos hacer es reproducir exactamente lo que teníamos. Y en esa comparativa, pues eso es lo que sale de diferencia. Como comentaba Miguel Ángel, evidentemente además de esa reducción de tiempo que ya era suficiente y que ya nos valía, ya nos daba valor añadido, pues nos llevamos toda una reducción de los procesos. Como ha dicho, pues evidentemente ahí pone más de 50 procesos, pero realmente estábamos en un montón de procesos y lo hemos dejado reducido a los 7 procesos que veis ahí. Se reduce también la volumetría final, es decir, los productos que estábamos entregando a nuestros consumidores, pues eran más de 20 fichidos, hechos de forma particular para cada uno de los consumidores. Y ese producto final que entrega este modelo explosionado, se ha quedado reducido a 2 tópicos de casca. La volumetría intermedia fue otro punto donde realmente ganamos, es decir, para conseguir el resultado que teníamos inicialmente, aparte de todo lo que generábamos como producto final, era necesario, en el punto intermedio y en los procesos intermedios, estar generando más de 100 tablas, ficheros, distintos artefactos para conseguir los resultados. En la parte de Neo hemos puesto en aplicación porque, en principio, el proceso de Neo va de una forma mucho más directa. Hasta aquí era la sustitución del legacy que teníamos, que es lo que hemos ganado adicionalmente con la implementación, pues nos ha permitido implementar algo que no nos lo permitía con la tecnología que teníamos, que era el explosionado en incremental, es decir, el explosionando según se van produciendo y acercarnos lo más posible al real-time. Evidentemente, con el legacy era imposible pensar en ese tipo de proceso. Y luego una cosa que hemos reflejado aquí, por hacerlo, en la primera fase del proyecto, si recordáis, se producía una carga, llamábamos full-full, abriacíamos una carga full de toda la base de datos Neo para luego realizar el explosionado completo y aquí, digamos, hemos mantenido ese explosionado, perdón, esa carga full, que realmente tarda 15 minutos. ¿Qué es lo que significa esto? Somos capaces de coger los sistemas, coger el origen del dato, lo que es nuestra codificación y reproducirlo en el modelo de Neo en 15 minutos, con la volumetría que inicialmente os estábamos contando por de cerca de 10 millones de artículos con toda esa volumetría que contábamos. A partir de aquí, nos surgieron nuevos retos, es decir, una vez que ya habíamos implementado esa primera fase o esa primera parte inicial del proyecto, nos dimos cuenta que éramos capaces de abordar mucho más y que la utilización de Neo en la compañía podía ir más allá. Entonces, empezamos a, bueno, aquí he intentado reproducir, hemos intentado reproducir un poco lo que sería el Run-Math de una empresa de retail avanzando en estas tecnologías, digamos que la fase que hemos, son dos vistas de la misma expresión, por un lado, está día la parte de qué productos o qué elementos tenemos que ir introduciendo en el Neo y poder la parte del cuadradito que veis aquí, este Run-Math, lo que implica son los diferentes resultados que vamos a ir obteniendo, según vayamos implementando nuevas cosas y metiendo nuevos productos en el Neo. Al final, la fase esta que hemos estado haciendo, pues de alguna manera lo que hemos estado incluyendo en Neo todo el tema de la jerarquía de productos, hemos haciendo la carga del catálogo de las promociones y hemos resuelto un poco la parte del brandata de tener también todo el tema de marca y todo eso incluido, pero se nos ha abierto el camino porque realmente cuando empezamos a trabajar en el proyecto, pues enseguida vimos que cuando, casi sin darnos cuenta, pero habíamos casi incorporado toda la codificación y todo el catálogo de la compañía, lo teníamos introducido en el Neo, con lo cual nos empezamos a plantear el atacar temas de pricing y el tema de la documentación promocional, que es otro de los puntos que es en lo que estamos ahora mismo y a las contadas después. Entonces, bueno, si os dais cuenta, estos son las mismas fases que teníamos en el proyecto original, solamente la hemos puesto aquí para representar una cosa, si veis en la parte de desplosionado histórico y futuro, está puesto de una forma en verde, está puesto de diferente color, porque fue curioso y queríamos resaltarlo, esto era como habíamos planteado el proyecto, realmente esa fase se nos cayó del proyecto cuando empezamos a hacerlo porque la conseguimos de forma natural, según íbamos implantando Neo, nosotros habíamos planteado estas fases atendiendo al esquema tradicional o tal, como lo veíamos desde nuestra óptica, pero al implantar Neo, lo que ocurrió es que por la configuración de Neo, al tener los atributos en la relación y todo esto, por lo que ocurrió es que según íbamos implantando las distintas fases, pues conseguimos hacer esa fase del desplosionado histórico y del desplosionado futuro, lo hicimos de Saki, lo único que no llegamos en ese momento a explotarlo como tal, lo que hemos hecho es nuestra primera fase para terminar de alguna manera el ciclo inicial del proyecto y en qué estamos ahora mismo, cuáles son las iniciativas para seguir engordando, digamos, la funcionalidad que tenemos sobre la base de datos grafos, pues estamos trabajando en toda la parte de documentación promocional, es una de las necesidades prioritarias, cómo le contamos a nuestras promociones a nuestros clientes y esto va muy ligado a la presentación en los frontales, estamos trabajando en ampliar esos servicios que habíamos construido en la fase 3 del proyecto inicial, una serie de un API de servicios con servicios de bajo nivel y sencillos, pues seguir incrementándolo para qué, pues sobre todo para poder ir integrando con la plataforma de comercio y para que el motor, digamos, el motor promocional de la compañía, empecemos a desviarlo y lo podamos usar basándose en Neo4j, como el motor de datos de nuestro propio motor promocional. Y luego la última línea en la que estamos un poco empezando a investigar es el incorporado, hasta ahora Neo lo hemos tenido como una cosa aparte del sistema que va en paralelo, que se nutre de lo que bebe del resto de sistemas y el se encarga de una parte y lo que estamos empezando a probar es un poco incorporado a Neo a la parte operacional de todo el movimiento promocional, que sea Neo4j la base de datos que directamente reciba los datos, no ya de mediante procesos intermedios, sino que lo reciba directamente de los propios frontales que se encargan de la definición de promociones y alimentamos el Neo de forma directa. Y ya para terminar, porque ya también todos tendremos ganar de ir terminando, de aguantar este rollo que los estamos soltando, pues un poco cuáles son nuestras recomendaciones o nuestras experiencias, tenemos claro que el mundo del grafo ha cubierto ampliamente nuestras expectativas, perdón, que sé que hay algo, si hay algo lo que yo creo Miguel que podemos destacar sobre todo la agilidad que presenta cuando nos encontramos en anti cargas y es una agilidad y una rapidez bastante significativa. Y luego dos lecciones que hemos aprendido, como todo en esta vida, a veces te vas aprendiendo y vas rodando y es cuando te das cuenta de cosas. Es muy importante, el cambio es de mentalidad, de filosofía respecto a todo, sobre todo gente que veníamos mucho del mundo relacional, pues hay que entender la filosofía grafos y es muy importante entenderla, porque si no corremos al riesgo de presentar temas o de plantear las cosas de forma muy a la tradicional, entonces es necesario entender la filosofía, esto parece de pero gruyo, pero son las dos cosas que deberíamos tener en cuenta siempre en todo proyecto. Y luego comenzar por problemas muy concretos y limitados en el alcance, no meternos en grandes proyectos a la hora de implementar el neo de saque, salvo que tengamos alguien que te dirija y si que cumpla el primer requisito porque se va aprendiendo sobre la marcha y los planteamientos iniciales pues a veces se van cambiando según vas aprendiendo y profundizando en el conocimiento de la herramienta. Miguel no sé si tienes algo más que añadir. No, yo únicamente hacer hincapié en el tema de que la filosofía grafos lo que nos ha permitido es descomponer digamos un problema que teníamos en dos situaciones que es pues esa generación del grafo o ese diseño del grafo y el poder hacer luego en una segunda parte el expresionado con la tecnología que estamos utilizando los tiempos son rapidísimos y nos ha permitido sustituir pues legacy que bueno el cobol y el llave 2 pues ya sabes que técnicamente pues también son procesos de alto rendimiento y bueno abrimos ya aquí aquí estamos aquí estamos Miguel Ángel Juan Carlos bueno vosotros diréis que nos había solta un rollo pero hay un montón de preguntas o sea que interesa te lo digo porque bueno preparados en primer lugar daros las gracias por por este rollo estupendo que nos habéis que nos habéis dado como explicarnos un poco primero el volumen nos habéis dado una visión del volumen con el que se encontraba el corte ingles el problema la solución o un poco de descripción del neo 4g o neo 4j y luego un poco como lo habéis hecho beneficios y todavía los retos que os quedan yo estoy agotada de escucharos no habéis parado y he hecho yo tenía una pregunta que preguntan también aquí y la voy a hacer la primera porque viene parte de luis y a veces había un luis al que le he dejado sin preguntar y por si acaso eres tú luis que sepas que vas el primero te cuelo porque antes no pudo hacer tu pregunta y luis os pregunta lo que nos estamos preguntando todos y dice cuánto tiempo y con cuánta gente aproximadamente os costó desarrollar este proyecto estamos agotados de escucharos esto ha sido un currazo quién es ángel juan carlos a ver el principio el equipo que hemos trabajando es un equipo muy numeroso de personas al final el tiempo de desarrollo y el tiempo que nos habían planificado para llevar a cabo la solución pues fueron en torno a cuatro seis meses realmente cumplimos las expectativas y la solución si la tuvimos en ese tiempo donde nos atoramos o donde tuvimos los mayores problemas pues en esto que os he contado al final había una serie de de puntos que teníamos que resolver y aquel que mayor nos enfrenta pues como siempre es al sustituir un sistema que ya está funcionando el poder integrarnos con nuestros clientes actuales eso pues sabéis que en empresas grandes al final es un tema costoso y es un tema que pues te genera muchos muchos stoppers y que te pide mover de una forma ágil vale para continuar digamos con o conseguir aquellas fechas que si queríamos que muchísimas preguntas aquí tenemos mucha plancha así que de todos modos de cuatro a seis meses está muy bien parece increíble con los volúmenes con los que se maneja el corte inglés no estoy segura que luis que la pregunta está también sorprendido no cuanta muy bien no era buena seguimos porque os pregunta pedro incluísis en vuestro caso de estudio otras soluciones de bases de datos orientadas a grafos como arango database o orient database sí pues contestó no no si bien bueno ya sabes pedro lourdes te os pregunta aparte de los ahorros en tecnología habéis obtenido algún beneficio de negocio claro mejora de las promociones aumento de ventas predicción de la demanda etcétera gracias si hemos beneficios claros aparte de la parte tecnológica que la que intentamos reflejar aquí hemos conseguido vender mejor contar el punto de vista de marketing o de marketing hemos conseguido presentar mejor las promociones y desarrollarlas mejor a la hora de contarlas nuestros clientes estupendo más preguntas os pregunta ginesz han explorado usarlo en otros procesos de negocio de la compañía de momento con esto tenemos bastantes en qué momento del día pero bueno ginesi no se apunta a con vosotros en el equipo y se ha probado utilizar algún servicio propio de la plataforma cloud muchas gracias la parte java eso sí que hemos tenido que hacer pues toda la parte de máquinas pero la otra parte hemos bueno muchas gracias nos queda la última pregunta que estamos y ahí apurando el último minuto Ignacio os pregunta que esto es lo que queremos saber todos para este próximo fin de semana qué recursos recomendaríais para aprender la filosofía de grafos y una pregunta así una lectura sencilla y rápida así para leer en el autobús hay mucho interés en grafos juan carlos así que darnos alguna algún recurso venga para este tema pues fuimos haciendo una aproximación y estuvimos revisando cuando nuestros proveedores el el acerto a la parte del diseño de grafos no hemos no hemos trabajado con ninguna literatura o sea esto ha sido ahí a capón básicamente ya ya me digo esto es vuestra propia de vuestra propia cosecha bueno eh hay Ignacio tendrás que seguir lo que hacen cerca miguel ángel parís y juan carlos mondeja desde el corte ingles excelente trabajo ha sido muy enriquecedor agotador ver cómo habéis trabajado en tan pocos meses y habiendo conseguido sustituir el legacy por todo lo nuevo y que funciona también y con tanto éxito así que vuelvo a decir como antes he dicho con lo introponente ahora cada vez que yo vaya al corte ingles y muchos de nuestros de nuestra audiencia ya cada vez que vamos una promoción del corte ingles veremos a juan carlos y a miguel ángel detrás de todo este montaje y todo lo que hay de trabajo detrás de todas estas 10 millones de referencias del catálogo del corte ingles felicidades por ese trabajo a seguir ánimo mucho mucho ánimo miguel ángel parís juan carlos mondeja del corte ingles muchas gracias por cerrar nuestro primer día en este big conference 2020 thank you so much i'm sorry i'm gonna eh well all english i'm gonna go back to english to say goodbye well to wrap up this first day at a big big things conference we had four fantastic keynotes uh just to summarize what they said i had a few one sentence per per keynote we had brian o'neal from designing for analytics he he mentioned the importance of design and i summarized it in put a designer in your life he didn't say that but i said as a summary put a designer in your company put a designer in your life then we had uh mario bergantiños from electronic arts who gave us the reasons for getting excited about data and their culture of data evangelization thank you so much that was very interesting then we had a ross vetted from snowflake who told us the three different types of cloud the application cloud the infrastructure cloud and the data cloud the third layer the third cloud very interesting and last but not least we had uh juan carlos monday jar as you saw miguel angel paris from el corte ingles and they could tell us well larga vida el grafo long live the grafo so it was a fantastic uh case study of neo 4j fantastic why do i summarize all this you may be wondering if i saw all the keynotes what maybe you did maybe you didn't but if you're playing if you're in your our in our platform going through the gamification there's a quiz we're gonna ask you questions and maybe one of the questions is who was the speaker of snow the snow and the snowflake speaker you know the answer is ross vetted or what was the instrument the uh the case study that they did at el corte ingles now you know the answer is neo 4j so you already got some big points for our final prize that will announce on the third day on wednesday afternoon at big things conference we got to the end this is all we have for you today at the attic but i hope you enjoyed it as much as i did first of all before i go i want to say thank you so much to our sponsors to the exhibitors in our platform our sponsors who made it possible there are many of them you know who you are you should know who they are as well because they are in our website and their platform a big thanks to all of you and uh big things has not finished yet we still have the lounge going on so if you can and you have time i i encourage you to hear to listen to nudi oliver the co-founder and vice president of ellis she's going to be talking about data science to fight covid 19 so don't don't hesitate don't what are you waiting for grab a coffee a tea and join the lounge for this last keynote the session for today after that we have some music yes this is a party cool killers so there's music especially for you you will see with special dedication from the cool killers band and some networking which is the essence as you know big things conference so network through the platform with our exhibitors the sponsors and the guests what else nothing else we just uh almost done remember i have to see you here at the attic tomorrow at 4 30 16 45 for a second day at big things conference until then remember we're talking about technology for good because any decision that we take has an impact see you tomorrow thank you