Skip to content
Menu

Anticiper les risques opérationnels dans la Supply Chain grâce à l’IA

Anticiper les risques opérationnels dans la Supply Chain grâce à l’IA

Temps de lecture : 5 minutes

Anticiper les risques opérationnels dans la Supply Chain grâce à l’IA

Temps de lecture : 5 minutes

Notre CEO Ider Oudad a pris la parole à l’occasion d’une conférence au salon de la Data de Nantes. Pendant 45 minutes il s’est appuyé sur le cas d’un de nos clients que nous avons traité par le passé pour expliquer comment anticiper les risques opérationnels dans la Supply Chain grâce à l’IA.

 

Un peu de contexte …

 

Notre client avait ce qu’on appelle une supply chain très étendue et des risques de défauts majeurs opérationnels. Leur supply chain est dite très étendue car elle comporte pas moins de 70 000 fournisseurs.

En effet, leurs produits sont très complexes à assembler et font intervenir plusieurs milliers de pièces. Leur chaîne d’approvisionnement est également très longue car elle fait intervenir des fournisseurs jusqu’au rang 8 (si l’on prend l’exemple de facebook, un fournisseur de rang 1 est l’équivalent de quelqu’un ami avec vous. Un fournisseur de rang 2 est l’ami de la personne amie avec vous et ainsi de suite jusqu’au rang 8). De plus, certains fournisseurs interviennent sur la fabrication de plusieurs pièces. 

À l’instar des défauts sur les crédits bancaires pour les organismes financiers, les défauts fournisseurs ont des conséquences majeures pour les supply chain. En effet, des défauts qualité sur les pièces dans la chaîne d’approvisionnement peuvent coûter des millions d’euros. En outre, ces défauts ne sont pas visibles : ce sont des faillites de processus chez les fournisseurs qui sont découverts trop tard.

Ainsi, l’objectif du projet auprès de notre client était d’anticiper les risques dans la supply chain en développant un outil de prédiction dynamique du risque de défaut qualité pour chaque fournisseur. 

 

Comment concevoir la solution ? 

 

Il y 4 dimensions à considérer pour valider la pertinence de développement d’un outil spécifique : l’architecture cible, l’approche modélisation, les données et la dimension métier. 

L’architecture cible : 

  • Identifier les caractéristiques d’architecture structurantes minimum pour l’outil
  • Formaliser l’architecture cible permettant l’intégration, le pilotage et la mise à jour des flux de données

L’approche modélisation : 

  • Concevoir une approche de modélisation en adéquation avec le problème business et les données disponibles 
  • Déterminer l’approche de suivi de la valeur ajoutée du modèle

Les données : 

  • Cartographier les données existantes
  • Valider un niveau de qualité minimum des données 

La dimension métier : 

  • Formaliser la bonne problématique
  • Définir les indicateurs de suivi de la performance 
  • Designer une solution cible 

 

Phase préparatoire de la conception 

La phase la plus importante dans la conception de la solution est celle de la préparation. Il faut absolument bien poser le problème, en formalisant une problématique, et identifier les critères de performance de la solution en définissant les indicateurs de suivi de la performance.

Si l’on reprend notre exemple, les questions à se poser pour formaliser la problématique sont nombreuses : Risque de défaut par fournisseur ou par (fournisseur; pièce) ? Quel horizon d’anticipation : 1 semaine, 1 mois, 3 mois ? Quelles actions une fois l’alerte levée et quels délais de mise en œuvre ? C’est ce type de question qu’il est primordial d’arbitrer. 

La logique est la même concernant les indicateurs et nous avons abouti à 3 indicateurs majeurs : Le coût global des défauts qualité, la fréquence d’occurrence des défauts qualité et le coût des actions correctives.

 

Design de la solution

L’étape suivante consiste à designer la solution. Le piège, ici, serait de designer un outil et non pas un processus cible dans son ensemble. Le processus cible correspond à la vision métier qu’il faut avoir de la solution : à quoi la solution va-t-elle servir et surtout comment elle sera utilisable.

Dans notre exemple, le processus de gestion des risques fournisseurs a été repensé pour passer d’un mode réactif où les incidents sont subis à un mode proactif où les incidents sont anticipés. 

 

Pour entrer dans le détail : 

process mise en d'une solution de prévision de ventes

Sécurisation de la matière première : les données

Les sources de données sont multiples, ainsi la quantité de données disponible est importante. C’est pourquoi, il faut sélectionner les données importantes et définir le niveau de qualité souhaité. En effet, certaines sources de données sont indispensables et d’autres non. Il ne faut jamais conditionner le démarrage d’un projet à un niveau de qualité sur toutes les données sinon vous n’allez jamais débuter !

Si l’on revient à notre exemple, ce travail de choix de données nous a permis de sélectionner 3 niveaux de données : 

  • Les données statiques caractérisant les fournisseurs (ex : lieu géographique, risques associés à l’usine)
  • Les données dynamiques (ex : ratio livraison en retard) 
  • Les données caractérisant les événements de non-qualité (ex : date d’occurrence, fournisseur concerné)

 

Identification des caractéristiques clés pour l’intégration de l’outil dans l’architecture du système d’information

Les points d’attention à cette étape sont au nombre de 3 : les multiples sources de données, le recueil des retours utilisateurs et le registre des modèles et expériences. 

En effet, il faut s’assurer de la connexion aux multiples sources de données internes puis externes et, à notre époque, de l’accessibilité de la solution en déplacement via une connexion internet.

Bien sûr, dans une logique d’adoption de la solution, il faut réfléchir à la récupération des retours utilisateurs sur la performance du modèle ainsi qu’à la possibilité de sauvegarde de ces retours sur la qualité des données. 

Le registre des modèles et expériences implique la construction de modèles de data science et la sauvegarde des différentes versions des modèles entraînés.

 

La construction du jeu de données pour l’apprentissage du modèle et la définition des indicateurs de performance

La phase finale de la conception de la solution consiste en la construction du jeu de données nécessaires à l’apprentissage du modèle et, bien entendu, définir les indicateurs clés de performance.

Nous allons illustrer ces deux notions avec notre exemple. Dans ce cas particulier, la construction du jeu de données implique 3 points : 

  • Une ligne du jeu de donnée représente un couple (fournisseur; mois)
  • La cible est binaire (0 ou 1) et représente l’événement {incident dans les trois prochains mois}
  • Les features construites s’appuient sur des agrégations temporelles (ex : délai de livraison moyen sur les 3 derniers mois) et des notions de proximité de graphe (ex : algorithme Page Rank)

De leur côté, les indicateurs clés de performance choisis sont au nombre de 2 : 

  • L’indicateur de performance principal retenu est la matrice de confusion : il permet de facilement communiquer avec les équipes opérationnelles. 
  • Le seuil de sensibilité de l’alerte est construit avec la notion de capacité (combien de fournisseurs puis-je traiter ce mois)

 

Le déploiement de la solution 

 

Le déploiement de cette dernière doit se faire de manière itérative pour favoriser l’adoption par les collaborateurs/utilisateurs de la solution.

Notre vision du déploiement d’une solution est guidée par 4 principes

  • Des cycles de développement pour livrer une application fonctionnelle à la fin de chaque mois
  • Partir des fonctionnalités basiques (tableau de bord fiche d’identité des fournisseurs) avant d’aller sur les fonctionnalités avancées (modèles prédictifs)
  • Construire des modèles simples et ajouter progressivement des sources de données et de nouvelles features
  • Travailler sur l’interprétabilité des modèles

Ainsi, dans le cas qui nous a servis d’exemple dans cet article, nous avons mis 8 mois de développement pour aboutir à l’ajout de l’ensemble des fonctionnalités. Mais durant ces 8 mois, la solution était utilisable et les collaborateurs/utilisateurs ont pu s’habituer et prendre en main l’outil. 

 

En conclusion, concevoir et déployer une solution Data & IA efficace c’est bien plus qu’un algorithme ou qu’un outil. Le design de la solution c’est penser aux processus, l’organisation, les outils et les compétences impliqués. Et, bien sûr, ne pas oublier la démarche d’amélioration continue, clé de voûte de tout projet Data & IA.