Un système de surveillance robuste et évolutif pour lutter contre les événements non enregistrés (NOS)
Avant de comprendre le système proposé, comprenons d’abord quelles peuvent être les raisons possibles des occurrences de Non-On-Shelf sous condition de disponibilité des stocks. Voici quelques raisons:
1. Le personnel du magasin n’est pas en mesure de réapprovisionner les étagères de manière proactive (beaucoup d’efforts manuels sont consacrés à la surveillance continue des étagères, en particulier dans le cas des grands magasins).
2. L’article se vend plus rapidement que d’habitude.
3. Problèmes de positionnement: les clients ont tendance à mettre certains articles sur des étagères aléatoires lors de leurs achats, ce qui provoque le blocage de l’affichage d’autres articles, ce qui fait chuter les ventes de ces articles.
Les transactions en temps réel illustrent le mouvement de la demande d’un article à un moment donné. En surveillant cette demande, on peut estimer si cet article se vend à son rythme habituel, ou s’il se vend anormalement haut, ce qui peut conduire à des étagères vides dans les heures à venir, ou s’il se vend à peine.
Le système proposé est basé sur une idée similaire de surveillance et de comparaison des transactions en temps réel par rapport aux références historiques. En utilisant cette approche simple, mais très efficace, comme technique de base, ce système permet au personnel du magasin d’agir à temps et de réduire les occurrences NOS ainsi que de les alerter en cas de faibles ventes, afin qu’ils puissent vérifier les problèmes avec ces articles .
Couche d’entrée
Le nombre de transactions qui ont lieu dans un magasin toutes les 10 à 15 minutes dépend principalement du nombre de comptoirs de caisse, de l’efficacité du caissier et du trafic dans le magasin. Chaque transaction contient des enregistrements d’achat de plusieurs articles. Dans les supermarchés / hypermarchés, le nombre d’articles achetés en une seule transaction est principalement compris entre 10 et 20.
Kafka est intégré au système de traitement des transactions (un système centralisé qui capture les transactions au fur et à mesure qu’elles se produisent dans l’un des magasins). Comme l’une des transactions a lieu dans l’un des magasins, les données de transaction sont publiées dans le sujet Kafka de ce magasin spécifique.
Les enregistrements de transaction unique incluent des informations telles que le nom de l’article, le nom du magasin, la quantité, la date et l’heure, le montant, la TVA, la taxe, les détails de la carte client, le type de transaction, etc.
Pour cette application, ce détail n’est pas nécessaire. Seules la date et l’heure, le nom de l’article, le nom du magasin et la quantité achetée sont suffisants. Les travaux Spark pour chacun des magasins lisent les données de transaction et les traitent pour une utilisation ultérieure.
Moteur de base
Le travail Spark pour chaque magasin s’exécute en parallèle pour détecter les NOS potentiels en temps réel et capturer l’état de chaque article pour chaque magasin de la base de données pour une utilisation ultérieure.
Le concept de Bandes de Bollinger qui est une technique populaire dans l’analyse des stocks est mise en œuvre pour détecter d’éventuels Not-On-Shelf. Il s’agit d’un outil d’analyse technique défini par un ensemble de 3 bandes:
- Bande médiane: Moyenne mobile simple sur une période de temps spécifique
- Bande supérieure: Bande médiane plus deux écarts-types
- Bande inférieure: La bande médiane moins deux écarts-types
Les données de transaction des dernières semaines pour chaque magasin sont utilisées pour dériver la bande supérieure et la bande inférieure des ventes, puis les ventes en temps réel sont comparées avec la bande supérieure et la bande inférieure.
Si les ventes en temps réel sont supérieures à la bande supérieure, alors l’article devient le candidat pour un potentiel de non-vente, alors que si les ventes en temps réel sont inférieures à la bande inférieure, cela indique que les ventes sont très faibles ou qu’aucune vente n’a eu lieu pour cet article, et les raisons possibles pourraient être que l’étagère est déjà vide, l’article n’est pas vendu rapidement, des problèmes de placement ou le produit est en rupture de stock dans l’inventaire lui-même.
Voici les fonctionnalités du Core Engine:
- Lire et traiter les données de transaction historiques
- Lire et traiter les données de transaction en temps réel
- Comparez les ventes en temps réel avec les bandes dérivées des ventes historiques et détectez les non-étagères potentielles
- Stockez le statut de chaque élément dans la base de données pour une utilisation ultérieure
Planificateur
Il est important d’informer le personnel du magasin des événements potentiels non stockés ou en rupture de stock au bon moment, afin que des mesures puissent être prises en temps opportun. Mais l’envoi de notifications à chaque fois des incidents peut facilement se transformer en spamming du personnel du magasin avec de nombreuses notifications, et il n’est pas du tout possible pour le personnel du magasin de vérifier et de réapprovisionner les étagères fréquemment.
Airflow est utilisé pour planifier des notifications pour chaque magasin. Il déclenche deux scripts Python différents à différents intervalles.
Le premier script est déclenché toutes les 15 minutes, ce qui compare le nombre de NOS avec une certaine valeur de seuil. Si le nombre d’occurrences est supérieur au seuil défini pour le magasin, il envoie immédiatement la notification à ce magasin. Le but de ce script est d’alerter le personnel du magasin si, à un moment donné, les étagères sont vides pour un grand nombre d’articles. Le tableau séparé de la base de données capture les détails si une notification ad hoc est envoyée.
Le deuxième script est déclenché toutes les 3 heures. Le but de ce script est d’envoyer des notifications au personnel du magasin toutes les 3 heures. Tout d’abord, il vérifie la table de base de données si une notification ad hoc est envoyée dans les 2 heures. Si oui, cela n’enverra aucune notification lors de cette exécution.
Surveillance du système
La surveillance de chacun des composants séparément devient délicate, en particulier lorsque plusieurs instances s’exécutent dans le back-end pour la restauration de chaque magasin. Les travaux Spark qui exécutent la fonction principale, s’exécutent en temps réel et ce sont des travaux de longue durée. Garder les travaux de longue durée en bonne santé tout le temps nécessite une surveillance détaillée qui peut alerter les développeurs pour qu’ils prennent des mesures pour éviter les longs temps d’arrêt.
Ce composant utilise Prometheus et Grafana pour collecter les journaux de chacun des autres composants de l’application et fournir un emplacement pour surveiller tous les composants en même temps, et alerter les développeurs au préalable en fonction des seuils d’erreur / d’avertissement de chaque composant.
Couche de sortie
Le but principal de cette application est d’alerter au préalable le personnel du magasin sur les occurrences de non-sur-étagère ou en rupture de stock, d’où la sortie principale est la notification par e-mail avec un rapport récapitulatif des articles identifiés.
Outre les notifications par e-mail, l’analyse peut être effectuée sur les éléments identifiés. Les tableaux de bord peuvent également fournir des informations sur l’efficacité des notifications.
