La Supply Chain Quantitative vs APS classique

Joannes Vermorel

Bien que les supply chains aient commencé tôt la digitalisation dans les années 80 et 90 avec la gestion électronique des stocks et l’EDI (Electronic Data Interchange), de nombreux vendeurs de logiciels - et donc la majorité de leurs clients - ont progressivement pris du retard par rapport à leur époque. Bien qu’il soit relativement simple de rafraîchir les interfaces utilisateur, par exemple en transformant des applications de bureau en applications web, il est généralement beaucoup plus difficile de revisiter les choix architecturaux de base soutenant un logiciel.

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 offrir aux supply chains via 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 tout autre bête.

Examinons de plus près les modules traditionnels que l’on trouve généralement dans les systèmes APS de premier plan, avec un intérêt particulier pour les réapprovisionnements de stocks dans un réseau à 2 niveaux - par exemple, entrepôts et magasins - et comparons ces modules avec la manière dont Lokad offre l’optimisation prédictive. Pour des raisons de concision, nous désignerons de manière interchangeable 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 l’utilisation d’un cycle fixe de commande est inévitable.

La toute idée que les praticiens de la supply chain devraient affiner leur calendrier de commande constitue une approche erronée du problème. La commande s’accompagne de multiples types de contraintes : calendrier, MOQs, budget, etc. Certaines contraintes peuvent être souples, comme « aucun calendrier, n’importe quel jour convient 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 doit rechercher – parmi toutes les options de commande réalisables – celles qui maximisent le ROI. Ce processus, « l’optimisation », doit être strictement automatisé. Il n’y a aucune raison d’affiner quoi que ce soit manuellement. Des solveurs numériques performants n’étaient pas couramment disponibles dans les années 80, mais ce n’est plus le cas de nos jours.

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 déployons les solveurs numériques adéquats pour mener à bien la tâche.

Voir aussi Les humains dans la supply chain moderne.

Module Événement

Le module événement gère les hausses et baisses de demande dues à des événements planifiés, tels que les lancements de nouveaux produits, la publicité, les promotions, les sorties de catalogue et les prospectus.

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 adoptaient des perspectives centrées sur les séries temporelles. Malheureusement, les problèmes de supply chain ne peuvent pas être facilement encadrés par les séries temporelles : les ruptures de stock, les promotions, les lancements et les retraits de produits sont autant de phénomènes qui ne rentrent 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éfaillants par conception, les APS ont recours à des « corrections » manuelles à appliquer tant aux données historiques – par exemple, pour lisser l’impact des promotions passées – qu’aux prévisions de demande, introduisant ainsi des 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 que nous savons avec certitude, ce sont les caractéristiques de la promotion – c’est-à-dire les dates de début et de fin, le mécanisme de remise, la portée, etc. – et ses ventes résultantes. Ainsi, le modèle statistique doit être conçu de manière à traiter les données historiques telles qu’elles existent, au lieu d’être « bloqué » par une perspective étroite des 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 à haute dimension, relevant typiquement du vaste ensemble des algorithmes de « machine learning ». La dernière version de notre technologie de prévision est centrée sur la programmation différentiable. Cependant, elle est encore en plein développement, car le domaine du machine learning évolue rapidement. Le besoin d’ajuster manuellement les résultats de prévision devrait être considéré comme un défaut logiciel à corriger, et non comme une opportunité de faire appel aux praticiens de la supply chain en tant que « coprocessors humains ».

En pratique, la majeure partie du défi consiste à rassembler les données pertinentes concernant à la fois les événements passés et futurs (par exemple, les promotions planifiées) – ce qui a peu à voir avec les statistiques. De plus, les systèmes analytiques, qu’il s’agisse de Lokad ou d’un APS, ne sont pas conçus pour effectuer un grand volume de saisies manuelles de données. Ces saisies relèvent du domaine transactionnel – alias l’ERP – qui collecte tous les faits¹ concernant la supply chain.

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

Un module de gestion accélérée des commandes agit comme un outil d’alerte précoce, et fournit aux acheteurs une vue actualisée quotidiennement des commandes en retard et des expéditions partielles.

Toute l’approche des exceptions et des alertes relève d’une perspective assez datée pour atténuer les problèmes au sein des systèmes complexes de l’industrie du logiciel. Cette approche a été largement adoptée par les vendeurs de logiciels dans les années 80 et 90, car les exceptions et les alertes sont simples à implémenter sur une base de données SQL. Il suffit d’une instruction SELECT avec quelques conditions WHERE. Cependant, dans l’ensemble, cette approche fait mauvais usage de la ressource précieuse que représentent les praticiens de la supply chain, car elle tend à les surcharger rapidement, au point que les alertes ne sont plus de véritables “alertes” et que le sentiment d’urgence ou d’action à entreprendre se dissipe.

Lokad privilégie et offre une priorisation stricte basée sur le ROI des « éléments » d’intérêt présentés aux praticiens de la supply chain. En règle générale, produire 1 million de chiffres par jour est facile, mais générer 10 chiffres valant la peine d’être lus par un humain chaque jour est difficile. Les commandes en retard ne sont pas toujours déterminantes : peut-être que les niveaux de stocks sont encore élevés, ou peut-être s’agit-il simplement d’un problème récurrent pour ce fournisseur de longue date. Les expéditions partielles devraient é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, il doit être actionnable, et le ROI représente le rendement estimé associé à l’action. Lokad se distingue en offrant des priorisations sur mesure parfaitement adaptées aux spécificités de la supply chain concernée.

Module de Deal/Achat à terme

Les modules de type deal/forward buy permettent à l’acheteur de saisir les données de l’offre dans le système avant la période concernée. 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 à terme et de déterminer quand les acquérir.

La plupart des APS ont été initialement conçus avec une perspective naïve selon laquelle le prix unitaire était supposé se suffire à lui-même pour calculer une quantité de commande optimisée. Cependant, la réalité présentait un niveau de détail supérieur. Les fournisseurs ont fréquemment des structures tarifaires complexes : MOQs, seuils 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 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 sur l’approvisionnement incite économiquement l’entreprise à surstocker temporairement : la quantité commandée devient le compromis numérique entre la remise supplémentaire (gains linéaires) et le risque de surstock (coûts super-linéaires). Nous fournissons la quantité de commande qui optimise directement ce compromis, en tenant compte de toutes les autres forces économiques pertinentes.

Module d’analyse des commandes

Les modules d’analyse des commandes identifient les risques de rupture de stocks potentiels. Ces modules fournissent l’information à jour nécessaire pour comprendre l’état des stocks pour des articles tels que les importations, ou ceux fabriqués sur mesure — des articles avec des délais de livraison longs pour lesquels il y a souvent deux, trois commandes ou plus en cours.

Il s’agit d’un autre cas de conception logicielle quelque peu simpliste basée sur la facilité d’implémentation. Dans les années 80, il était difficile de réaliser une analyse à l’échelle du réseau, ainsi la plupart des vendeurs de logiciels optaient par défaut pour une conception logicielle imposant une « isolation des SKU ». Chaque SKU est traité de manière isolée, et les estimateurs statistiques calculés – comme la probabilité attendue de rupture de stock pour le prochain cycle de commande – sont entièrement spécifiques au SKU en question.

Chez Lokad, nous observons que chaque SKU est en concurrence avec tous les autres SKUs pour le budget de l’entreprise. Ainsi, il importe peu que la probabilité de rupture de stock d’un SKU donné soit élevée ou faible. La seule chose qui compte, c’est que le retour sur investissement de commander davantage de ce SKU soit suffisamment important pour ne pas être battu par une option alternative – c’est-à-dire commander davantage d’un autre SKU – facilement accessible à l’entreprise. Par exemple, si le SKU est associé à un produit dont le coût est élevé, avec une marge très faible et acheté uniquement par un grand client d’entreprise qui est sur le point de partir selon l’équipe commerciale, maintenir le taux de service pour ce SKU est une recette assurée pour créer des stocks morts.

En pratique, Lokad fournit des quantités de commande priorisées 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 le surstock dans les entrepôts. Ils permettent aux acheteurs de transférer l’excès de stock d’un site vers un autre où la demande est suffisante, afin d’éviter de procéder à 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 d’un lieu A vers un lieu B. Ainsi, lorsqu’on est confronté à un réseau où le même article peut être stocké dans de nombreux emplacements, il est tout à fait naturel de considérer tout mouvement de stock entre deux emplacements comme une décision potentielle.

Ainsi, Lokad dispose de capacités intégrées pour effectuer une optimisation au niveau du réseau de ce type, en testant essentiellement toutes les options disponibles pour les mouvements de stocks. La partie la plus difficile de cette 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 prise en compte au niveau des mouvements de stock par SKU. Par exemple, les coûts de transport tendent à être très non linéaires : si un camion doit être dépêché, profitons au maximum de sa capacité disponible.

Malheureusement, le nombre d’options croît bien plus rapidement que le nombre de SKUs. Prenons l’exemple d’un réseau comprenant 2000 articles stockés dans 10 entrepôts, soit 10 x 2000 = 20 000 SKUs au total. Le nombre total de liaisons à considérer pour les mouvements de stocks est de 10 x (10 - 1) * 2000 = 180 000 liaisons, un nombre bien supérieur au nombre initial de SKUs. Pour les lecteurs familiers avec les algorithmes, il s’agit d’un cas classique de complexité quadratique.

Cependant, en tenant compte de la puissance de traitement disponible de nos jours, ce cas spécifique de complexité quadratique n’est pour la plupart pas un 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 supply chain dépassent très rarement les 10 000 emplacements, même pour les entreprises les plus gigantesques ; et quelques heuristiques peuvent être utilisées pour réduire considérablement le nombre de liaisons à explorer en pratique, car de nombreuses paires d’emplacements se révèlent être dénuées de sens, comme le rééquilibrage des stocks entre Paris et Sydney.

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

Avance rapide jusqu’à aujourd’hui, de nombreux fournisseurs ont dû introduire des modules séparés pour traiter tout problème nécessitant une optimisation à l’échelle du réseau. Il n’existe aucune véritable motivation commerciale pour disposer d’un module séparé. Cette situation reflète surtout le fait que le fournisseur d’origine a bricolé son produit logiciel pour faire face à une catégorie de problèmes en conflit avec des choix de conception qui ont été faits deux décennies auparavant.

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

Module de planification

Les modules de planification permettent aux équipes commerciales ou marketing de pré-planifier des 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. Considérons un réseau de distribution B2B. Si un client annonce le 10 février qu’il commandera 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 – généralement en la repoussant d’une semaine – ce schéma doit être pris en compte. Toutefois, cette analyse de schéma relève du domaine des prédictions.

Lokad aborde ce type de problèmes avec une technologie qui fournit des prévisions probabilistes générales et pas seulement des prévisions probabilistes de la demande. Toute affirmation concernant l’avenir, par exemple une date d’arrivée prévue, tend à être incertaine dans une certaine mesure. Les supply chain nécessitent des outils prédictifs polyvalents et de haute dimension, ce qui explique précisément pourquoi Lokad a emprunté 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. Ce n’est 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 important verrouillage accidentel par le fournisseur. En effet, dès que les entrées de données circulent dans un système de l’entreprise, ce système devient le contrôleur principal de facto de ces données.

Notre expérience chez Lokad indique que les couches analytiques obsolètes persistent fréquemment pendant une décennie supplémentaire après leur point d’obsolescence, simplement parce que des données critiques ne seraient pas perdues si ce système était éteint. Par ailleurs, le fournisseur de logiciel initial continue de percevoir des frais de maintenance, ce qui offre au fournisseur un fort incitatif à créer ce problème dès le départ.

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 nuisibles et ne peuvent plus être considérées comme une pratique saine en supply chain. Consultez le contre-modèle des prévisions nues pour plus d’informations. Cela ne signifie pas que Lokad manque de capacités de prévision, nous en avons. Cependant, nous soutenons que l’approche classique de prévision des séries temporelles est tout simplement erronée et doit cesser. Les prévisions classiques des séries temporelles peuvent fonctionner pour des produits à très fort volume et très stables, mais pour tout autre cas – et en particulier pour une demande erratique ou intermittente – la prévision probabiliste est la voie à suivre.

De plus, les modèles historiques de prévision des séries temporelles – comme Holt-Winters ou Arima – présentaient d’énormes lacunes chaque fois que l’historique du produit était trop court, trop erratique, trop atypique, ou d’un volume trop faible, … La plupart des fournisseurs de logiciels ont répondu à ces problèmes avec deux approches, également dysfonctionnelles chacune à leur manière :

• Coprocesseurs humains : comme le modèle de prévision finit fréquemment par produire des résultats insensés, des opérateurs humains – c.-à-d. des planificateurs – sont utilisés par le système comme “coprocessors” pour annuler manuellement les prévisions chaque fois que “les chiffres ne semblent pas corrects”. Malheureusement, cette tâche est interminable, les prévisions devant être rafraîchies en continu, forçant les planificateurs dans un cycle sans fin d’annulations manuelles. Une telle tâche produit également des effets secondaires indésirables, où les opérateurs humains en viennent à considérer que les prévisions sont erronées et ont tendance à les corriger même lorsqu’elles ne le sont pas, souvent sur la base d’un simple ressenti.
• Compétition de modèles : puisque chaque modèle de prévision des séries temporelles a ses propres forces et faiblesses, une compétition entre de nombreux modèles de prévision – selon la logique – devrait donner de bons résultats en laissant le système “choisir” le meilleur modèle dans chaque situation. Malheureusement, cela échoue pour deux raisons. Premièrement, tous les modèles reposent sur un cadre de séries temporelles et sont donc tous soumis aux mêmes limitations. Deuxièmement, tous les modèles sont “classiques” et ne parviennent pas à fournir les prévisions probabilistes dont la supply chain a besoin.

De plus, la prévision ne concerne pas seulement la demande. Les délais d’approvisionnement doivent également être prévus. Par ailleurs, la structure de la supply chain compte. En B2B, un flux constant 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 en surstock, voire en dead stock. Une véritable optimisation prédictive de la supply chain doit prendre ce risque en compte. La technologie de Lokad a été conçue en conséquence.

Dans l’optique spécifique du partage des prévisions avec les fournisseurs, bien qu’une meilleure coordination entre acheteurs et fournisseurs soit toujours préférable, nous avons constaté que les coordinations guidées par les prévisions réussies entre entreprises sont rares. Les fournisseurs ont de toute façon de nombreux clients². Ainsi, même si les prévisions fournies par les acheteurs locaux étaient exactes, le fournisseur n’a aucun 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é

Il est étonnant de constater que, pour certains APS, les fonctionnalités de sécurité ne sont pas toutes présentes par défaut dans le système, mais sont fournies sous forme de module séparé. Le but d’un module de sécurité est d’empêcher l’accès à certains utilisateurs. Il permet également à la direction de sécuriser les actions des composants et de restreindre les vues pour des 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 opérations et d’autres composants.

Dans le jargon du logiciel, nous parlons ici des préoccupations transversales de l’authentification et de l’autorisation.

• L’authentification garantit que les utilisateurs finaux effectuant une action dans le système sont vraiment la personne que le système croit qu’ils sont. Ici, Lokad adopte l’approche moderne selon laquelle l’authentification doit être déléguée chaque fois que cela est possible. Les utilisateurs finaux ne devraient pas avoir à gérer un mot de passe supplémentaire. Au lieu de cela, Lokad exploite SAML comme standard industriel de facto pour déléguer l’authentification à la gestion fédérée des identités (FIM).
• L’autorisation offre un contrôle granulaire sur qui peut faire quoi au sein du système. Ici, Lokad dispose d’un système ACL (Access-Control List) canonique et étendu, qui est également la pratique de facto des systèmes d’entreprise modernes. Lokad propose également certaines capacités de personnalisation, qui viennent compléter l’ACL d’un point de vue de l’expérience utilisateur.

Lokad active toutes ses fonctionnalités de sécurité par défaut, quel que soit le package initialement vendu à l’un de nos clients. Nous pensons que la sécurité optionnelle ³ est une pratique terrible de la part des fournisseurs de logiciels. Sécuriser un logiciel est déjà extrêmement difficile ; une telle pratique ne fait qu’aggraver la situation.

Pour être honnêtes, l’angle de l’ACL est probablement la préoccupation la moins difficile dans l’ensemble de la question de la sécurité logicielle. Une question plus intéressante est de savoir dans quelle mesure l’architecture même du système offre une sécurité par conception. Cependant, répondre à cette question dépasse le cadre du présent article.

Export vers Excel

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

Comme il est relativement simple de produire des feuilles Excel⁴, de nombreux fournisseurs – y compris Lokad – proposent des capacités dans ce domaine. Pourtant, un examen plus approfondi indique que la plupart des fournisseurs ne fournissent que des capacités à moitié développées. Examinons les points saillants des implémentations bien conçues d’export vers Excel :

• Historisation complète : le système doit offrir la possibilité de suivre et de retélécharger chaque feuille Excel jamais exportée. En effet, face à des chiffres incorrects dans le tableau – un problème qui arrivera (ne serait-ce que pour une faute de saisie) – ne pas disposer d’une traçabilité complète du chemin de code ayant généré ce tableau compliquera considérablement, ralentira – et parfois empêchera – toute tentative de débogage et de correction du problème.
• Exploitation maximale des capacités du tableur : les praticiens s’attendent à pouvoir générer des tableaux volumineux allant jusqu’à 1 million de lignes⁵, c’est-à-dire la limite même d’Excel. Ainsi, le système doit être capable de générer des tableaux lourds afin de ne pas gêner les praticiens qui souhaitent simplement effectuer leur propre analyse de données dans un outil familier. Inutile de dire que les praticiens attendent également que ces exportations volumineuses soient rapides.
• Protection intégrée contre les attaques par tableur : Excel est un vecteur d’attaque dangereux pour les grandes organisations. Malheureusement, sécuriser les tableaux générés par le système ne peut être une réflexion après coup, cela doit être une partie intégrante de la conception, pratiquement dès le premier jour.
• Configurabilité programmatique des exportations : avoir à 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 tableaux qui nécessitent toujours un traitement post-extraction supplémentaire pour devenir utilisables. Cela implique que tout se passe avant l’extraction, au sein de l’APS. Ainsi, l’APS a besoin de capacités programmatiques pour préparer correctement les tableaux avant l’exportation.

Lokad offre tout ce qui précède, tandis que la plupart de nos concurrents ne le font pas. Le diable est dans les détails.

Conclusion

Nous sommes convaincus que Lokad est un logiciel plus simple que la plupart des APS sur le marché. Pourtant, notre capacité à offrir une performance supply chain grâce aux technologies prédictives est supérieure. En effet, la plupart de la complexité des APS est accidentelle, résultant de choix de conception logicielle faits il y a des décennies face à des problèmes logiciels introspectifs désormais révolus. Cependant, la plupart des choix d’architecture logicielle, une fois faits, ne peuvent être démodifiés.