M. Video-Eldorado Group presentó su estrategia de Hacking Retail a principios de 2021. Durante los próximos 5 años, planeamos duplicar la facturación total a 1 billón de rublos y triplicar el surtido, incluso mediante el desarrollo de nuestro propio mercado. Los sistemas de TI “monolíticos” no pueden proporcionar este crecimiento en poco tiempo y los desarrollos no estándar ralentizan todo el proceso. Los microservicios vienen al rescate. Le diremos cómo "cortamos" una parte de SAP ERP y qué salió de ella.
Hace un par de años completamos el proceso de fusión de las oficinas internas de M.Video y Eldorado. Como resultado, la infraestructura de TI unida de la red minorista comenzó a representar una estructura de tres capas: en el primer nivel, un back office unido, cuyo principal sistema de contabilidad es un ERP SAP “monolítico”.
Arriba hay una plataforma de microservicio en constante expansión que proporciona datos clave para todos los sistemas frontales (precios, promociones, productos, saldos, información del cliente, etc.) y proporciona integración de los sistemas frontales con los sistemas posteriores. Arriba, este esquema se corona con dos oficinas centrales separadas para cada una de las marcas.
En general, este paquete satisface las necesidades actuales de la empresa. Pero están en constante crecimiento, por lo que buscamos constantemente subóptimas condiciones, cuya eliminación podría mejorar el rendimiento de los procesos comerciales y prepararlos para una mayor carga de trabajo.
Prepárate en serio. M.Video-Eldorado tiene grandes planes para ampliar la gama de productos y lanzar nuevos proyectos. El crecimiento esperado en los volúmenes de suministro debería ser de dos a cinco veces. Y no algún día, sino dentro de uno o dos años.
Largas horas de espera
Uno de los cuellos de botella que debían eliminarse lo antes posible era el algoritmo para calcular calendarios logísticos. Expliquemos con un poco más de detalle. Existe un concepto de accesibilidad logística. Determina en qué momento se puede entregar la mercancía desde el punto A al punto B. El parámetro de accesibilidad logística es utilizado por todos los front office, se accede a él por aplicaciones comerciales, etc. - este es uno de los principales parámetros de un producto como unidad logística.
El calendario contiene información completa sobre la posibilidad de mover mercancías entre el proveedor, almacenes centrales y regionales y tiendas en ambas redes. Si el envío está programado para hoy, se utiliza el calendario de hoy. Pero mañana perderá su relevancia y habrá que aplicar "mañana".
Para aumentar la estabilidad del trabajo de los procesos logísticos, el cálculo se realizó diariamente con tres días de anticipación. Esta solución se ha entregado durante mucho tiempo como una "muleta" en SAP ERP debido a la velocidad de implementación. ¡El proceso tomó de 9 a 11 horas! Las pruebas con una carga más alta mostraron que el sistema no podía hacer frente al cálculo ni siquiera en 24 horas. Para lograr una productividad cualitativamente más alta con un aumento significativo de volúmenes, era importante sacar este servicio del monolito ...
Situación actual
El algoritmo para calcular calendarios logísticos, que forma parte de SAP ERP, era un paquete de procedimientos PL / SQL proporcionado por SAP en forma de una solución de caja personalizada. El cálculo de cada uno de los tres calendarios en él se realizó "desde cero", teniendo en cuenta todas las condiciones para cada cadena de suministro. En consecuencia, la mayoría de los cálculos en cada etapa simplemente se duplicaron entre sí. Esta era la lógica del funcionamiento del producto y no teníamos los recursos para eliminar por completo la deuda técnica.
Además, el algoritmo dejó cadenas de suministro "basura" duplicadas en los calendarios terminados. Esto llevó a un aumento en el tamaño de la base de datos. En lugar de los 10 millones de registros requeridos, la base de datos podría contener entre 20 y 30 millones y requerir una limpieza manual.
La herramienta original no llegó a un estado tan óptimo en un día. Se introdujo hace mucho tiempo y, durante todo el período de funcionamiento, se le realizaron numerosas mejoras, iniciadas por clientes comerciales. Una serie de cambios graduales a lo largo de los años dio lugar a la aparición de diversas inexactitudes, algunas de las cuales no se reflejaron plenamente en las especificaciones.
Al mismo tiempo, se trataba de una herramienta empresarial fundamental, de cuyo desempeño dependían las actividades de cientos de tiendas de la red minorista. Por lo tanto, el enfoque para el desarrollo de productos tenía que ser muy cuidadoso pero rápido.
Roer un trozo del "monolito"
Al darnos cuenta de que el potencial de crecimiento de la productividad de SAP ERP en esta área (por cierto, no es típico de un servicio ERP) se ha agotado, recurrimos a los microservicios. M.Video-Eldorado ha estado desarrollando esta dirección durante varios años.
Tenemos nuestra propia plataforma de microservicios que ejecuta más de cien microservicios. Fue necesario crear una serie de servicios basados en el mismo algoritmo que el módulo original del sistema ERP. Queríamos mantener la lógica general de los cálculos, pero evitar repetir los mismos procesos.
El trabajo se llevó a cabo en tres direcciones principales. Primero, era necesario optimizar el algoritmo SAP eliminando cálculos innecesarios. En segundo lugar, era necesario eliminar la aparición de cadenas de suministro duplicadas, lo que provocaba la acumulación de registros innecesarios en la base de datos. En tercer lugar, era necesario eliminar inexactitudes en los resultados del algoritmo original, que complican la optimización de los procesos comerciales.
Recuerde que SAP ERP es uno de los principales back-systems de la empresa, que recibe datos de todos los front-systems. A pesar de que el cálculo de los calendarios tuvo que transferirse a los microservicios, los pasos de adquisición individuales en sí mismos, el movimiento de mercancías todavía se creaba en el sistema de contabilidad central.
Para generar calendarios logísticos, SAP ERP proporciona más de 20 tablas con configuraciones recibidas de usuarios comerciales. A partir de estos datos, la plataforma de microservicio realiza los cálculos. El propio ERP también los utiliza para cálculos internos al crear un segundo y tercer brazo de entrega. Por lo tanto, era imposible simplemente arrancar todo el proceso del monolito y transferirlo.
Diagrama de proceso:
1 y 3 - El proceso a través de SAP PI recibe datos con configuraciones para calcular calendarios desde SAP ERP;
2 y 4 - Registro de los datos recibidos del ERP en la base de datos;
5 - El proceso toma una de las versiones de los datos almacenados en su base de datos (por defecto, la última versión). Luego calcula los calendarios basándose en estos datos y los almacena en una tabla de etapas. Durante la operación, el proceso solicita información sobre los objetos.
6 - Los datos se transfieren de la tabla de etapas a la tabla productiva en el mismo formato en que el proceso los recibe de SAP ERP.
7 - Eliminación de datos antiguos con configuración de calendario de la base de datos.
Herramientas, tiempo, recursos
Dado que hemos estado creando microservicios durante varios años, no teníamos dudas particulares sobre la elección de las herramientas de desarrollo. Una combinación bien dominada de Java 11 y Spring Boot
2 entró en acción . No hay magia en el código, solo cosas estándar para Java: colecciones, interfaces, etc.
Inicialmente construimos el nuevo algoritmo para que todas las operaciones con tablas se realizaran completamente en RAM y no utilizar consultas SQL dentro de la base de datos.
Por parte del equipo de operaciones de SAP ERP, se realizaron los preparativos para la transferencia de datos maestros a la plataforma de microservicios para el cálculo de calendarios. Tardaron unas 40 horas.
En el futuro, solo necesitaban apoyar el proyecto. El trabajo principal, por supuesto, recayó sobre los hombros de los ingenieros de la propia plataforma. La lógica del algoritmo fue esencialmente recreada. Del ERP, solo se tomaron datos maestros y principios comerciales básicos para el cálculo de calendarios. Esto tomó otras 150 horas.
En general, la implementación del proyecto tomó alrededor de seis meses. Pasamos dos meses solos en numerosos autotests basados en diferentes enfoques. La prueba piloto del nuevo instrumento continuó durante aproximadamente un mes. Durante este período, calculamos simultáneamente dos tipos de calendarios: antiguos y nuevos, estudiamos y comparamos los resultados, era de vital importancia asegurarse de que el servicio no se deteriorara y que el cálculo fuera correcto. Solo después de eso se decidió transferir la nueva herramienta al entorno de producción.
resultados
¿Qué obtuvimos al final? El calendario ahora se calcula solo una vez. Luego, sus instancias para cada uno de los tres días se obtienen como resultado de unos pequeños cálculos adicionales asociados con el cambio de fechas. El volumen de la base de datos se mantiene automáticamente en un estado óptimo debido a la ausencia de un complemento "muleta", la carga en el sistema ERP ha disminuido.
Pero el principal resultado que hemos podido lograr es la reducción del tiempo de generación del calendario de 9-11 horas a ... ¡10 minutos! Hay mucho trabajo por delante, el futuro aumento múltiple de la carga en la infraestructura de TI aún requerirá mejoras, pero ganamos esta parte de la deuda técnica.