SCM Quantitative vs APS Classique

Joannes Vermorel

Alors que les supply chains ont commencé leur digitalisation dès les années 80 et 90 avec la gestion électronique des stocks et l’EDI (Échange de Données Informatisé), de nombreux éditeurs de logiciels - et donc la plupart de leurs clients - ont progressivement pris du retard au cours des deux décennies qui ont suivi. Alors qu’il est relativement simple de rafraîchir les interfaces utilisateur, par exemple en transformant les applications de bureau en applications web, il est généralement beaucoup plus difficile de revoir les choix de conception architecturale fondamentaux qui soutiennent un logiciel. La plupart de ces solutions n’avaient jamais été conçues pour le cloud computing, l’apprentissage automatique ou une expérience utilisateur axée sur le mobile, pour n’en citer que quelques-uns.

Lokad préconise des processus et des technologies qui tirent le meilleur parti de ce que la puissance de calcul en réseau moderne peut apporter aux supply chains grâce à de meilleures optimisations prédictives. Nous appelons cette approche la perspective de la Supply Chain Quantitative. Cependant, pour les praticiens de la supply chain, ce message peut être quelque peu déroutant, car la Supply Chain Quantitative n’est pas une variation des anciennes méthodes d’optimisation de la supply chain, c’est une bête totalement différente.

Ainsi, examinons de plus près les modules traditionnels que l’on trouve généralement dans les principaux¹ systèmes APS (Advanced Planning and Scheduling), en mettant l’accent sur les réapprovisionnements de stocks dans un réseau à deux échelons - par exemple, les entrepôts et les magasins - et comparons ces modules avec la manière dont Lokad fournit une optimisation prédictive. Pour des raisons de concision, dans la suite, nous utilisons indifféremment les termes supply chain quantitative (la vision) ou Lokad (l’implémentation logicielle).

Module Calendrier

Un module calendrier fournit des mécanismes pour affiner les situations de commande, c’est-à-dire décider quand acheter, lorsque le cycle d’achat à commande fixe est inévitable.

L’idée même selon laquelle les praticiens de la supply chain devraient affiner leur calendrier de commande est la mauvaise façon de voir les choses. La commande est soumise à plusieurs types de contraintes : calendrier, quantités minimales de commande (MOQ), budget, etc. Certaines contraintes peuvent être souples, comme “pas de calendrier, n’importe quel jour sauf le 4 juillet et le 25 décembre”, ou strictes, comme “le conteneur doit être exactement plein”. Dans tous les cas, le système devrait rechercher - parmi toutes les options de commande réalisables - celles qui maximisent le retour sur investissement (ROI). Ce processus, l’optimisation, doit être strictement automatisé. Il n’y a aucune raison d’affiner manuellement quoi que ce soit. Les solveurs numériques performants n’étaient pas couramment disponibles dans les années 80, mais de nos jours, ce n’est plus le cas.

Ainsi, chez Lokad, nous rassemblons toutes les contraintes pertinentes, qui sont elles-mêmes traitées comme des données, c’est-à-dire la “base de données” des calendriers de commande autorisés, puis nous déployons les solveurs numériques adéquats pour accomplir la tâche.

Voir aussi Les humains dans les chaînes d’approvisionnement modernes.

Module Événement

Le module événement gère les pics et les creux de la demande dus à des événements planifiés, tels que les nouveaux produits, les publicités, les promotions, les lancements de catalogues et les dépliants.

Les premiers modèles de prévision (par exemple, Holt-Winters), découverts dans les années 50 et 60, étaient tous centrés sur les séries temporelles. Ainsi, la plupart des APS ont adopté une perspective centrée sur les séries temporelles. Malheureusement, les problèmes de chaîne d’approvisionnement ne peuvent pas être facilement encadrés dans les séries temporelles : les ruptures de stock, les promotions, les lancements et les arrêts sont autant de phénomènes qui ne s’inscrivent pas dans le cadre mathématique traditionnel associé aux séries temporelles. Ainsi, pour faire face aux modèles de prévision des séries temporelles défectueux, les APS recourent à des “corrections” manuelles à appliquer à la fois aux données historiques - par exemple, lissage de l’augmentation des promotions passées - et aux prévisions de la demande - introduction de biais dans les estimations futures.

Chez Lokad, notre approche consiste à traiter ces “perturbations” comme de simples données historiques. Nous ne saurons jamais avec certitude ce qui se serait passé si une promotion passée n’avait pas été déclenchée. La seule chose dont nous sommes sûrs, c’est la caractéristique de la promotion - c’est-à-dire les dates de début et de fin, le mécanisme de réduction, la portée, etc. - et ses ventes résultantes. Ainsi, le modèle statistique doit être conçu frontalement pour traiter les données historiques telles qu’elles existent, au lieu d’être “bloqué” dans une perspective étroite de séries temporelles.

Lokad rassemble les événements pertinents et traite toutes ces données avec des modèles statistiques adaptés aux problèmes de grande dimension, relevant généralement de la catégorie générique des algorithmes d’apprentissage automatique. La dernière version de notre technologie de prévision est centrée sur la programmation différentiable. Cependant, il s’agit encore d’un travail en cours, car le domaine de l’apprentissage automatique lui-même évolue rapidement. Le besoin d’ajuster manuellement les résultats de prévision doit être considéré comme un défaut logiciel à corriger, et non comme une opportunité d’utiliser les praticiens de la chaîne d’approvisionnement comme “coprocesseurs humains”.

En pratique, la majeure partie du défi consiste à rassembler les données pertinentes sur les événements passés et futurs (par exemple, les promotions planifiées) - ce qui n’a que peu à voir avec les statistiques. De plus, les systèmes analytiques, qu’il s’agisse de Lokad ou d’un APS, ne sont pas le lieu pour effectuer de grandes quantités de saisies de données manuelles. Ces saisies de données relèvent du domaine transactionnel - alias le ERP - qui collecte tous les faits² sur la chaîne d’approvisionnement.

Module de gestion des commandes accélérées

Un module de gestion des commandes accélérées agit comme un outil d’alerte précoce et fournit aux acheteurs une vue actualisée quotidiennement des commandes en retard et des livraisons incomplètes.

L’approche globale des exceptions et des alertes est une perspective plutôt dépassée pour atténuer les problèmes au sein de systèmes complexes dans l’industrie du logiciel. Cette approche a été largement adoptée par les éditeurs de logiciels dans les années 80 et 90, car les exceptions et les alertes sont faciles à mettre en œuvre sur une base de données SQL. Il suffit d’une instruction SELECT avec quelques conditions WHERE. Cependant, dans l’ensemble, cette approche fait un mauvais usage de la ressource rare que représentent les praticiens de la chaîne d’approvisionnement, car elle a tendance à les surcharger rapidement, au point que les alertes ne sont plus vraiment des “alertes” et que le sentiment d’urgence ou d’action à entreprendre se perd.

Lokad privilégie et propose une priorisation stricte basée sur le retour sur investissement (ROI) des “éléments” d’intérêt présentés aux praticiens de la chaîne d’approvisionnement. En règle générale, produire 1 million de chiffres par jour est facile, produire 10 chiffres dignes d’être lus par un être humain chaque jour est difficile. Les commandes en retard ne sont pas toujours importantes : peut-être que les niveaux de stock sont toujours élevés, ou peut-être que c’est simplement un problème récurrent pour ce fournisseur qui dure depuis toujours. Les livraisons incomplètes doivent également être traitées automatiquement afin de corriger les paiements aux fournisseurs en conséquence, mais elles ne nécessitent pas toujours une réponse immédiate. Pour qu’un “élément” ait un ROI, l’“élément” doit être actionnable, et le ROI représente le ROI estimé associé à l’action. Lokad brille en fournissant des priorisations sur mesure qui sont exactement adaptées aux spécificités de la chaîne d’approvisionnement concernée.

Module d’achat anticipé

Les types de modules d’achat anticipé permettent à l’acheteur de saisir les données de l’offre dans le système avant la période de l’offre. Cela permet au système d’acheter des stocks de réapprovisionnement correspondant à la fenêtre de l’offre, de calculer les quantités d’achat anticipé et de déterminer quand acheter ces quantités.

La plupart des APS ont été initialement mis en œuvre avec une perspective naïve où le prix unitaire était supposé être suffisant en lui-même - du point de vue du prix - pour calculer une quantité de commande optimisée. Cependant, la réalité était plus détaillée. Les fournisseurs ont souvent des structures de tarification complexes : quantités minimales de commande, paliers de prix, remises sur les quotas trimestriels, offres temporaires, etc.

Lokad considère tous ces éléments comme des données d’entrée et des contraintes d’entrée et exploite une résolution numérique directe d’un problème contraint pour fournir une quantité de commande optimisée. Par exemple, une remise temporaire du fournisseur donne un incitatif économique à l’entreprise pour surstocker temporairement : la quantité de commande devient le compromis numérique entre la remise supplémentaire (gains linéaires) et le risque de surstockage (coûts superlinéaires). Nous fournissons la quantité de commande qui optimise directement ce compromis, en plus de toutes les autres forces économiques pertinentes.

Module d’analyse des commandes

Les modules d’analyse des commandes permettent d’identifier les ruptures de stock potentielles. Ces modules fournissent les informations à jour nécessaires pour comprendre l’état des stocks pour des articles tels que les importations ou ceux fabriqués sur mesure - des articles à long délai de livraison pour lesquels il y a souvent deux, trois ou plusieurs commandes en attente.

Il s’agit d’un autre cas de conception logicielle quelque peu simpliste “facilité de mise en œuvre”. Dans les années 80, il était difficile d’effectuer des analyses à l’échelle du réseau, c’est pourquoi la plupart des éditeurs de logiciels ont adopté une conception logicielle imposant une “isolation SKU”. Chaque SKU est traité de manière isolée, et les estimateurs statistiques calculés - tels que la probabilité de rupture de stock attendue pour le prochain cycle de commande - sont entièrement spécifiques au SKU concerné.

Chez Lokad, nous observons que chaque SKU est en concurrence avec tous les autres SKUs pour le budget de l’entreprise. Ainsi, il n’est pas vraiment important que la probabilité de rupture de stock d’un SKU donné soit élevée ou faible. La seule chose qui importe, c’est de savoir si le retour sur investissement pour commander plus de ce SKU est suffisamment élevé pour ne pas être surpassé par une autre option - c’est-à-dire commander plus d’un autre SKU - facilement disponible pour l’entreprise. Par exemple, si le SKU est associé à un produit qui a un coût élevé, une marge très faible et est acheté uniquement par un seul grand client d’entreprise, qui s’apprête à partir selon l’équipe commerciale, maintenir le taux de service pour ce SKU est une recette sûre pour créer un stock mort.

En pratique, Lokad fournit des quantités de commande prioritaires qui reflètent directement l’économie de bout en bout de la supply chain.

Module de transfert de surstock

Les modules de transfert de surstock aident les acheteurs à gérer les surstocks dans les entrepôts. Ils permettent aux acheteurs de transférer les stocks excédentaires d’un endroit à un autre qui a une demande suffisante, afin d’éviter de faire des achats supplémentaires auprès du fournisseur.

Dans la supply chain, il est presque toujours possible - mais généralement pas rentable - de déplacer quelque chose de l’emplacement A à l’emplacement B. Ainsi, lorsqu’on est confronté à un réseau où le même article peut être stocké dans de nombreux endroits, il est naturel de considérer tout mouvement de stock entre deux endroits comme une décision potentielle.

Ainsi, Lokad dispose de capacités intégrées pour effectuer une optimisation à l’échelle du réseau de cette nature, en testant toutes les options disponibles pour les mouvements de stock. La partie la plus difficile de l’entreprise est de refléter correctement la friction économique associée au déplacement du stock. En effet, la friction n’est généralement pas correctement reflétée par les mouvements de stock au niveau du SKU. Par exemple, les coûts de transport ont tendance à être fortement non linéaires : si un camion doit être envoyé, profitons au maximum de sa capacité disponible.

Malheureusement, le nombre d’options augmente beaucoup plus rapidement que le nombre de SKUs. Prenons par exemple un réseau qui comprend 2000 articles stockés dans 10 entrepôts, ce qui donne un total de 10 x 2000 = 20 000 SKUs. Le nombre total d’arêtes à prendre en compte pour les mouvements de stock est de 10 x (10 - 1) * 2000 = 180 000 arêtes, un nombre beaucoup plus élevé que le nombre initial de SKUs. Pour les lecteurs qui sont familiers avec les algorithmes, il s’agit d’un cas simple de complexité quadratique.

Pourtant, lorsque l’on considère la puissance de traitement disponible de nos jours, ce cas spécifique de complexité quadratique est principalement sans problème - à condition que le logiciel sous-jacent ait été correctement conçu pour ce type d’exploration numérique. En effet, les réseaux de la chaîne d’approvisionnement dépassent très rarement les 10 000 emplacements, même en examinant les entreprises les plus gigantesques ; et quelques heuristiques peuvent être utilisées pour réduire considérablement le nombre d’arêtes à explorer en pratique, car de nombreux paires d’emplacements sont susceptibles d’être non sensées, comme rééquilibrer les stocks entre Paris et Sydney.

Cependant, dans les années 80 et 90, en raison du matériel informatique disponible à l’époque, les APS avaient déjà du mal à faire face au nombre de SKUs. Naturellement, dans ce contexte, faire face à des problèmes de complexité quadratique était tout simplement hors de question.

En avançant rapidement jusqu’à aujourd’hui, de nombreux fournisseurs ont dû introduire des modules séparés pour traiter tout type de problème impliquant une optimisation à l’échelle du réseau. Il n’y a pas de réelle motivation commerciale pour avoir un module séparé. Cette situation reflète principalement le fait que le fournisseur d’origine a dû bricoler son produit logiciel pour faire face à une classe de problèmes qui sont en conflit avec les choix de conception qui ont été faits deux décennies auparavant.

En revanche, Lokad a décidé de s’attaquer frontalement à cette classe de problèmes qui sont des citoyens de première classe dans notre pile logicielle. Naturellement, la résolution effective du défi nécessite encore des efforts en pratique, car tous les coûts de transport et contraintes doivent être rendus explicites.

Module de planification

Les modules de planification permettent aux équipes de vente ou aux équipes marketing de prévoir les commandes pour des événements spécifiques tels que des promotions ou des commandes spéciales. Les équipes peuvent créer une commande planifiée dans le système plus d’un an avant la date prévue de la commande.

L’approche de Lokad commence par établir une séparation claire entre les faits et les prédictions. Prenons l’exemple d’un réseau de vente B2B. Si un client annonce le 10 février qu’il va commander 1000 unités, avec une date de livraison prévue le 1er mars, alors cette annonce est un fait. Si ce client a l’habitude de revoir à la dernière minute sa date de livraison prévue - en la reportant généralement d’une semaine - alors cette analyse de modèle relève du côté des prédictions du problème.

Lokad aborde cette classe de problèmes avec une technologie qui fournit des prévisions probabilistes générales et non seulement des prévisions probabilistes de la demande. Toute déclaration faite sur le futur, par exemple une date d’arrivée prévue, tend à être incertaine dans une certaine mesure. Les chaînes d’approvisionnement nécessitent des outils prédictifs polyvalents et multidimensionnels, c’est exactement pourquoi Lokad a choisi la voie de la programmation différentiable.

De plus, les faits ne doivent pas être collectés par la couche analytique, ni par Lokad ni par l’APS. Non pas parce que le logiciel ne peut pas le faire. Concevoir un logiciel pour collecter des faits est relativement simple, mais cela génère un niveau élevé de verrouillage accidentel du fournisseur. En effet, dès que les entrées de données circulent à travers un système de l’entreprise, ce système devient le contrôleur maître de facto de ces données.

Notre expérience chez Lokad indique que les couches analytiques obsolètes restent souvent en place pendant une décennie supplémentaire après avoir atteint leur point d’obsolescence, pour la simple raison que des données critiques pour la mission seraient perdues si ce système était éteint. Pendant ce temps, le fournisseur de logiciel d’origine continue de percevoir des frais de maintenance, ce qui donne au fournisseur un fort incitatif pour créer le problème en premier lieu.

Module de projections

Les modules de projections permettent aux acheteurs de créer des rapports qui projettent la demande future et les achats futurs jusqu’à un an à l’avance. Ces prévisions peuvent être partagées avec les fournisseurs, afin de leur permettre de planifier plus précisément leurs capacités d’approvisionnement respectives.

Les prévisions nues sont préjudiciables et ne peuvent plus être considérées comme une pratique saine de la chaîne d’approvisionnement. Consultez le contre-modèle des prévisions nues pour plus d’informations. Cela ne signifie pas que Lokad n’a pas de capacités de prévision, nous en avons. Cependant, nous maintenons que l’approche classique de prévision des séries temporelles est tout simplement erronée et doit prendre fin. Les séries temporelles classiques peuvent fonctionner pour des produits à très fort volume et très stables, mais pour tout le reste - et en particulier pour une demande erratique ou intermittente - la prévision probabiliste est la voie à suivre.

De plus, les modèles de prévision historiques basés sur les séries temporelles - par exemple, Holt-Winters ou Arima - présentaient de graves lacunes lorsque l’historique du produit était trop court, trop erratique, trop atypique, de trop faible volume, … La plupart des éditeurs de logiciels ont répondu à ces problèmes avec deux approches, également dysfonctionnelles à leur manière :

• Coprocesseurs humains : comme le modèle de prévision finit souvent par produire des résultats non sensés, les opérateurs humains - c’est-à-dire les planificateurs - sont utilisés par le système en tant que “coprocesseurs” pour remplacer manuellement les prévisions chaque fois que les “chiffres ne semblent pas corrects”. Malheureusement, la tâche est sans fin car les prévisions doivent être continuellement actualisées, obligeant les planificateurs à entrer dans un cycle sans fin de remplacements manuels. Une telle tâche produit également des effets secondaires indésirables, où les opérateurs humains sont habitués à considérer que les prévisions sont fausses et ont tendance à les corriger même lorsqu’elles ne le sont pas, souvent basées sur un simple sentiment intuitif.
• Compétition de modèles : comme chaque modèle de prévision basé sur les séries temporelles a ses propres forces et faiblesses, une compétition de nombreux modèles de prévision - selon le raisonnement - devrait donner de bons résultats en permettant au système de “choisir” le meilleur modèle dans chaque situation. Malheureusement, cela échoue pour deux raisons. Premièrement, tous les modèles se basent sur un cadre séries temporelles, et donc, sont tous soumis aux mêmes limitations. Deuxièmement, tous les modèles sont “classiques” et ne parviennent pas à fournir les prévisions probabilistes requises par la supply chain.

De plus, la prévision ne concerne pas seulement la demande. Les délais d’approvisionnement doivent également être prévus. De plus, la structure de la supply chain est importante. Dans le B2B, un flux régulier de ventes peut masquer le fait que toutes les commandes proviennent du même client. Si ce client est perdu, de nombreux articles deviennent instantanément surstockés, voire obsolètes. Une optimisation prédictive appropriée de la supply chain doit prendre en compte ce risque. La technologie de Lokad a été conçue en conséquence.

Concernant l’angle spécifique du partage des prévisions avec les fournisseurs, bien qu’une meilleure coordination entre les acheteurs et les fournisseurs soit toujours préférable, nous avons observé que les coordinations réussies basées sur les prévisions entre les entreprises ont été rares. Les fournisseurs ont de nombreux clients de leur propre côté[^fournisseur]. Ainsi, même si les prévisions fournies par les acheteurs locaux étaient précises, le fournisseur n’a pas de moyen de concilier toutes ces prévisions disparates : la somme des prévisions n’est PAS la prévision de la somme.

Module de sécurité

Étonnamment, pour certains APS, les fonctionnalités de sécurité ne sont pas toutes présentes par défaut dans le système, mais fournies sous forme de module séparé. Le but d’un module de sécurité est de restreindre l’accès à certains utilisateurs. Il permet également à la direction de sécuriser les actions des composants et de restreindre les vues pour les zones importantes du système, telles que les facteurs de contrôle de l’entreprise, la maintenance des articles, la maintenance des fournisseurs, les commandes, les transactions et autres composants.

Dans le jargon informatique, il s’agit ici des préoccupations transversales d’authentification et d’autorisation.

• L’authentification garantit que les utilisateurs finaux effectuant des actions dans le système sont réellement les personnes que le système croit qu’elles sont. Ici, Lokad adopte l’approche moderne selon laquelle l’authentification doit être déléguée chaque fois que possible. Les utilisateurs finaux ne devraient pas avoir à gérer un autre mot de passe. Au lieu de cela, Lokad exploite SAML en tant que norme de facto de l’industrie pour déléguer l’authentification à la gestion d’identité fédérée (FIM).
• L’autorisation offre un contrôle précis sur qui peut faire quoi dans le système. Ici, Lokad propose un système étendu de liste de contrôle d’accès (ACL) canonique, qui est également la pratique de facto des systèmes d’entreprise modernes. Lokad propose également certaines capacités de personnalisation, qui complètent l’ACL du point de vue de l’expérience utilisateur.

Lokad active toutes ses fonctionnalités de sécurité par défaut, quelle que soit la version initialement vendue à l’un de nos clients. Nous pensons que la sécurité facultative³ est une pratique terrible des éditeurs de logiciels. La sécurisation des logiciels est déjà extrêmement difficile ; une telle pratique ne fait qu’aggraver les choses.

Pour être honnête, l’aspect ACL est probablement la préoccupation la moins difficile de toute la question de la sécurité des logiciels. Une question plus intéressante est de savoir dans quelle mesure la sécurité par conception est intégrée à l’architecture même du système. Cependant, répondre à cette question dépasse le cadre du présent article.

Export vers Excel

Le module export vers Excel offre un moyen facile de transporter des données pour une utilisation dans d’autres systèmes ou pour une analyse.

Comme il est assez simple de produire des feuilles Excel⁴, de nombreux fournisseurs - y compris Lokad - proposent des fonctionnalités dans ce domaine. Cependant, un examen plus approfondi indique que la plupart des fournisseurs ne proposent que des fonctionnalités incomplètes. Passons en revue les points saillants des implémentations bonnes d’exportation vers Excel :

• Historisation complète : le système devrait offrir la possibilité de suivre et de re-télécharger chaque feuille Excel jamais exportée. En effet, lorsque des chiffres incorrects apparaissent dans la feuille de calcul - un problème qui se produira forcément (ne serait-ce que à cause de données incorrectes) - ne pas disposer d’une traçabilité complète sur le chemin du code qui a généré cette feuille de calcul compliquera énormément, ralentira - et parfois empêchera - toute tentative de débogage et de résolution du problème.
• Exploiter au maximum les capacités de la feuille de calcul : les praticiens s’attendent à pouvoir générer des feuilles de calcul volumineuses pouvant atteindre 1 million de lignes⁵, c’est-à-dire la limite d’Excel lui-même. Ainsi, le système doit être capable de générer des feuilles de calcul lourdes afin de ne pas gêner les praticiens qui veulent simplement effectuer leurs propres calculs de données dans un outil familier. Il va sans dire que les praticiens s’attendent également à ce que ces exports volumineux soient rapides.
• Protection intégrée contre les attaques de feuilles de calcul : Excel est un vecteur d’attaque dangereux pour les grandes organisations. Malheureusement, la sécurisation des feuilles de calcul générées par le système ne peut pas être une réflexion après coup, elle doit faire partie intégrante de la conception, dès le premier jour.
• Configurabilité programmatique des exports : Devoir gérer deux logiciels - à savoir l’APS et Excel - est déjà assez pénible pour les praticiens de la supply chain. La situation ne devrait pas être aggravée par des feuilles de calcul qui nécessitent toujours un traitement supplémentaire après l’extraction pour devenir utilisables. Cela implique que tout se passe avant l’extraction, au sein de l’APS. Ainsi, l’APS doit disposer de capacités programmatiques pour préparer correctement les feuilles de calcul avant l’exportation.

Lokad propose tout cela, tandis que la plupart de nos concurrents ne le font pas. Le diable se cache dans les détails.

Conclusion

Notre conviction est que Lokad est un logiciel plus simple que la plupart des APS sur le marché. Pourtant, notre capacité à fournir des performances de la supply chain grâce à des technologies prédictives est plus grande. En effet, la complexité de la plupart des APS est accidentelle, découlant de choix de conception logicielle faits il y a des décennies pour résoudre des problèmes logiciels tournés vers l’intérieur qui ont depuis longtemps disparu. Cependant, la plupart des choix architecturaux logiciels, une fois faits, ne peuvent pas être annulés.