Le Groupe M.Video-Eldorado a présenté sa stratégie de Hacking Retail début 2021. Au cours des 5 prochaines années, nous prévoyons de doubler le chiffre d'affaires total à 1 000 milliards de roubles et de tripler l'assortiment, notamment grâce au développement de notre propre marché. Les systèmes informatiques « monolithiques » ne sont pas en mesure d'assurer cette croissance en peu de temps et les développements non standard ralentissent l'ensemble du processus. Les microservices viennent à la rescousse. Nous vous dirons comment nous avons "scié" un morceau de SAP ERP, et ce qu'il en est advenu.
Il y a quelques années, nous avons terminé le processus de fusion des back-offices M.Video et Eldorado. En conséquence, l'infrastructure informatique unifiée du réseau de vente au détail a commencé à représenter une structure à trois niveaux : au premier niveau, un back office unifié, dont le système comptable principal est un ERP SAP « monolithique ».
Au-dessus se trouve une plate-forme de microservices en constante expansion qui fournit des données clés à tous les systèmes frontaux (prix, promotions, produits, soldes, informations client, etc.) et permet l'intégration des systèmes frontaux avec les systèmes arrière. A l'étage, ce dispositif est couronné de deux front-offices distincts pour chacune des enseignes.
En général, ce bundle répond aux besoins actuels de l'entreprise. Mais ils ne cessent de croître, nous recherchons donc constamment des sous-optimalités, dont l'élimination pourrait améliorer les performances des processus métier et les préparer à une charge de travail accrue.
Préparez-vous sérieusement. M.Video-Eldorado a de grands projets pour élargir la gamme de produits et lancer de nouveaux projets. La croissance attendue des volumes d'approvisionnement devrait être de deux à cinq fois supérieure. Et pas un jour, mais d'ici un an ou deux.
De longues heures d'attente
L'un des goulots d'étranglement qu'il fallait éliminer au plus vite était l'algorithme de calcul des calendriers logistiques. Expliquons-nous un peu plus en détail. Il y a un concept d'accessibilité logistique. Il détermine à quel moment les marchandises peuvent être livrées du point A au point B. Le paramètre d'accessibilité logistique est utilisé par tous les front offices, il est accessible par les applications métiers, etc. - c'est l'un des principaux paramètres d'un produit en tant qu'unité logistique.
Le calendrier contient des informations complètes sur la possibilité de déplacer des marchandises entre le fournisseur, les entrepôts centraux et régionaux et les magasins dans les deux réseaux. Si l'expédition est prévue pour aujourd'hui, le calendrier du jour est utilisé. Mais demain il perdra de sa pertinence et il faudra appliquer « demain ».
Pour augmenter la stabilité du travail des processus logistiques, le calcul a été effectué quotidiennement pendant trois jours à l'avance. Cette solution a longtemps été livrée comme une « béquille » dans SAP ERP en raison de la rapidité de mise en œuvre. Le processus a pris 9-11 heures! Des tests sous une charge plus élevée ont montré que le système ne pouvait pas faire face au calcul même en 24 heures. Pour atteindre une productivité qualitativement plus élevée avec une augmentation significative des volumes, il était important de sortir ce service du monolithe ...
Situation actuelle
L'algorithme de calcul des calendriers logistiques, qui fait partie de SAP ERP, était un ensemble de procédures PL/SQL fourni par SAP sous la forme d'une solution box personnalisée. Le calcul de chacun des trois calendriers qu'il contient a été effectué "à partir de zéro", en tenant compte de toutes les conditions de chaque chaîne d'approvisionnement. En conséquence, la plupart des calculs à chaque étape se sont simplement reproduits. C'était la logique de fonctionnement du produit, et nous n'avions pas les moyens d'éliminer totalement la dette technique.
De plus, l'algorithme a laissé des chaînes d'approvisionnement « poubelles » en double dans les calendriers finis. Cela a conduit à une augmentation de la taille de la base de données. Au lieu des 10 millions d'enregistrements requis, la base de données pourrait en contenir 20 à 30 millions et nécessiter un nettoyage manuel.
L'outil d'origine n'a pas atteint un état aussi optimal en un jour. Il a été introduit il y a très longtemps, et tout au long de sa période d'exploitation, de nombreuses améliorations lui ont été apportées, initiées par des clients professionnels. Un flux de changements graduels au fil des ans a conduit à l'émergence de diverses inexactitudes, dont certaines n'ont pas été pleinement reflétées dans les spécifications.
En même temps, il s'agissait d'un outil commercial critique, dont dépendaient les activités de centaines de magasins du réseau de distribution. Par conséquent, l'approche du développement de produits devait être très prudente mais rapide.
Ronger un morceau du "monolithe"
Réalisant que le potentiel de croissance de la productivité SAP ERP dans ce domaine (d'ailleurs, pas typique pour un service ERP) était épuisé, nous nous sommes tournés vers les microservices. M.Video-Eldorado développe cette direction depuis plusieurs années.
Nous avons notre propre plate-forme de microservices exécutant plus d'une centaine de microservices. Il a fallu créer un certain nombre de services basés sur le même algorithme que le module d'origine du système ERP. Nous voulions garder la logique générale des calculs, mais éviter de répéter les mêmes processus.
Les travaux ont été menés dans trois directions principales. Premièrement, il était nécessaire d'optimiser l'algorithme SAP en éliminant les calculs inutiles de celui-ci. Deuxièmement, il était nécessaire d'éliminer l'apparition de chaînes d'approvisionnement en double, entraînant l'accumulation d'enregistrements inutiles dans la base de données. Troisièmement, il était nécessaire d'éliminer les inexactitudes dans les résultats de l'algorithme d'origine, qui compliquent l'optimisation des processus métier.
Rappelons que SAP ERP est l'un des principaux back-systems de l'entreprise, qui reçoit les données de tous les front-systems. Malgré le fait que le calcul des calendriers ait dû être transféré aux microservices, les étapes d'approvisionnement individuelles elles-mêmes, le mouvement des marchandises était toujours créé dans le système comptable central.
Pour générer des calendriers logistiques, SAP ERP fournit plus de 20 tables avec les paramètres reçus des utilisateurs métier. C'est sur la base de ces données que la plateforme de micro-services effectue des calculs. ERP lui-même les utilise également pour les calculs internes lors de la création des deuxième et troisième bras de livraison. Par conséquent, il était impossible de simplement extraire l'ensemble du processus du monolithe et de le transférer.
Diagramme de processus :
1 et 3 - Le processus via SAP PI reçoit des données avec les paramètres de calcul des calendriers de SAP ERP ;
2 et 4 - Enregistrement des données reçues de l'ERP dans la base de données ;
5 - Le processus prend une des versions des données stockées dans sa base de données (par défaut - la dernière version). Il calcule ensuite les calendriers en fonction de ces données et les stocke dans une table intermédiaire. Pendant le fonctionnement, le processus demande des informations sur les objets.
6 - Les données sont transférées de la table intermédiaire à la table productive dans le même format dans lequel le processus les reçoit de SAP ERP.
7 - Suppression des anciennes données avec les paramètres du calendrier de la base de données.
Outils, temps, ressources
Puisque nous créons des microservices depuis plusieurs années, nous n'avions aucun doute particulier sur le choix des outils de développement. Une combinaison bien maîtrisée de Java 11 et Spring Boot
2 est entré en action magique Pas dans le code, seules choses standard pour Java -. Collections, interfaces, etc.
Nous avons construit d' abord le nouvel algorithme de sorte que toutes les opérations avec des tables ont été complètement réalisées en RAM et ne pas utiliser de requêtes SQL dans la base de données.
Du côté de l'équipe d'exploitation SAP ERP, des préparatifs ont été faits pour transférer les données de base vers la plateforme de microservices pour le calcul des calendriers. Cela a pris environ 40 heures.
À l'avenir, ils n'avaient plus qu'à soutenir le projet. Le travail principal, bien sûr, est tombé sur les épaules des ingénieurs de la plate-forme elle-même. La logique de l'algorithme a été essentiellement recréée. De l'ERP, seules les données de base et les principes commerciaux de base pour le calcul des calendriers ont été extraits. Cela a pris encore 150 heures.
En général, la mise en œuvre du projet a duré environ six mois. Nous avons passé deux mois seuls sur de nombreux autotests basés sur différentes approches. Le pilotage du nouvel instrument s'est poursuivi pendant environ un mois. Pendant cette période, nous avons calculé simultanément deux types de calendriers - ancien et nouveau, étudié et comparé les résultats, il était extrêmement important de s'assurer que le service ne se détériorait pas et que le calcul était correct. Ce n'est qu'après cela qu'il a été décidé de transférer le nouvel outil dans l'environnement de production.
résultats
Qu'avons-nous obtenu au final ? Le calendrier n'est désormais calculé qu'une seule fois. Ensuite, ses instances pour chacun des trois jours sont obtenues à la suite de quelques calculs supplémentaires associés aux changements de dates. Le volume de la base de données est automatiquement maintenu dans un état optimal en raison de l'absence d'un add-on "béquille", la charge sur le système ERP a diminué.
Mais le principal résultat que nous avons pu obtenir est la réduction du temps de génération du calendrier de 9-11 heures à ... 10 minutes ! Il y a beaucoup de travail devant nous, la future augmentation multiple de la charge sur l'infrastructure informatique nécessitera encore des améliorations, mais nous avons gagné cette dette technique.