FAQ : Gestion du Changement

Une initiative avec Lokad vise à optimiser la supply chain du client grâce à une prise de décision automatisée supérieure - remplaçant généralement les tâches quotidiennes ennuyeuses telles que les commandes d’achat et les choix d’allocation de stock. Cette page aborde les questions et les préoccupations concernant le changement que cette initiative apporte, et comment le gérer efficacement. Les experts de Lokad restent, à tout moment, disponibles pour aider les clients à naviguer dans le processus.

Public cible : Les départements de la supply chain et/ou de la planification.
Dernière modification : 19 décembre 2023

Aperçu de la Gestion du Changement

La Supply Chain Quantitative (SCQ), telle que pionnière et préconisée par Lokad, diverge considérablement de la perspective traditionnelle. Les différences sont à la fois essentielles et les raisons principales pour lesquelles Lokad peut apporter des améliorations aussi drastiques à la supply chain. Cela dit, la gestion du changement associée à la mise en œuvre d’une initiative SCQ est plus facile que ce que nos clients pensent généralement.

Par exemple, Lokad élimine de nombreux points de contact et processus inutiles, plutôt que de simplement remplacer du gaspillage par un autre. Ainsi, le changement à gérer est généralement double : premièrement, s’adapter au fait que les décisions de la supply chain monotones et répétitives sont désormais automatisées ; deuxièmement, accepter que la qualité de ces décisions automatisées dépasse ce que les employés étaient capables d’atteindre avec d’autres outils (systèmes hérités, feuilles de calcul, et souvent un peu des deux).

Une initiative SCQ est dirigée par les Supply Chain Scientists de Lokad. Ces experts regroupent de nombreux rôles qui seraient normalement joués par plusieurs personnes dans des initiatives similaires avec d’autres fournisseurs de logiciels. Un Supply Chain Scientist fonctionne en tant qu’intégrateur de système, ingénieur de données, analyste commercial, data scientist, expert en supply chain et chef de projet (entre autres rôles). Les Supply Chain Scientists (SCSs) fournissent tout le coaching, la formation, l’orientation et le soutien nécessaires aux clients pour adopter l’approche de supply chain quantitative de Lokad.

Le déploiement réussi de Lokad (en production) entraîne généralement deux résultats notables : des économies substantielles grâce à de meilleures décisions de supply chain, et des économies de productivité substantielles grâce à des décisions de supply chain (largement) automatisées.

En termes de gestion du changement, les économies de la supply chain sont généralement sans problème. L’entreprise pourrait finalement décider de réinvestir le capital de travail libéré ailleurs, mais ce genre de décision dépasse normalement le cadre de l’initiative Lokad. Cependant, les économies de productivité considérables générées par Lokad sont généralement réinvesties dans d’autres tâches qui apportent beaucoup plus de valeur ajoutée pour l’entreprise cliente que le processus hérité.

En bref, avant Lokad, les activités des praticiens de la supply chain au sein de l’entreprise cliente sont presque exclusivement tournées vers l’intérieur : produire une prévision, transformer la prévision en plan, ajuster les niveaux de stock min/max sur les SKUs, composer des commandes d’achat/commandes de production/mouvements de stock, etc.

Une fois que Lokad est en production, la plupart des activités sont tournées vers l’extérieur : identifier ce que les clients perçoivent comme la qualité de service, identifier ce que les fournisseurs perçoivent comme un obstacle pour baisser davantage le prix, identifier ce que les transporteurs perçoivent comme les causes profondes de leur manque de fiabilité, etc.

Ces informations sont ensuite continuellement intégrées dans la solution de Lokad grâce au soutien continu des SCSs.

Pour les cadres de la supply chain, le plus grand changement est l’élimination (dans une large mesure) de la lutte contre les incendies. La solution de Lokad fournit des décisions automatisées conçues pour traiter les cas particuliers gênants, réduisant ainsi considérablement la bande passante que les cadres doivent consacrer à l’analyse du comportement erratique du marché. Cela libère les cadres de la supply chain pour élaborer des objectifs et des projets de supply chain, plutôt que de gérer en détail les conséquences continues de décisions suboptimales.

Foire aux questions (FAQ)

1. Mise en œuvre et gestion du projet

1.1 Offrez-vous des services de gestion de projet de mise en œuvre ?

Oui. Ces services sont assurés par les Supply Chain Scientists (SCSs) de Lokad. Ces experts non seulement gèrent la mise en œuvre, mais ils dirigent également l’initiative avec l’entreprise cliente. Cela comprend de nombreuses tâches telles que fournir une assurance quantitative à la gestion de la supply chain pour démontrer la validité des recettes numériques de Lokad avant leur déploiement. Les SCSs fournissent également des supports de formation pour soutenir l’adoption des pratiques et des processus recommandés par Lokad au sein de l’entreprise cliente.

Au-delà de cela, ces experts s’engagent à la réussite à long terme de l’initiative au-delà de la mise en œuvre initiale, en fournissant un soutien continu lorsque l’initiative passe à sa phase d’« amélioration continue ».

Consultez les conférences de Lokad sur le Supply Chain Scientist et Une journée dans la vie d’un Supply Chain Scientist pour plus d’informations sur le rôle des SCS dans le processus d’optimisation.

1.2 Quel est votre calendrier de mise en œuvre et quelles sont les étapes ou phases incluses dans ce calendrier ? Quels sont les objectifs de chaque phase (du lancement du projet de mise en œuvre à la mise en production) ?

De bout en bout, la mise en œuvre prend généralement environ 6 mois. Lokad distingue la phase d’intégration de la phase de production. L’objectif de la phase d’intégration est de mettre la recette numérique de Lokad en production. À la fin de la phase d’intégration, les décisions de la supply chain d’intérêt (telles que définies en collaboration avec le client) devraient être robotisées. Cependant, l’automatisation est généralement seulement un effet secondaire (bien que très visible) de l’intention réelle : améliorer les performances de la supply chain. L’objectif de la phase de « production » est de continuellement affiner, améliorer et réaligner les recettes numériques, celles qui permettent l’automatisation en premier lieu.

Répartition du calendrier

La phase d’intégration dure généralement 6 mois et peut être divisée en trois sous-phases de 2 mois.

• La première sous-phase est la mise en place du pipeline de données. L’objectif est de créer un pipeline entièrement automatisé pour l’extraction des données client vers Lokad. Les deux aspects les plus exigeants du pipeline de données sont l’établissement de la « sémantique » des données et la fiabilité (quasi parfaite) du processus de pipelining lui-même. Un pipeline de données, par opposition à une extraction ponctuelle de données, est fondamental pour maintenir la pertinence des recommandations de la supply chain générées par Lokad par rapport aux préoccupations commerciales actuelles du client.

• La deuxième sous-phase est la conception de la ou des recettes numériques uniques du client - les morceaux de logique logicielle qui pilotent les décisions de la supply chain. L’objectif est d’obtenir des recettes cohérentes, fiables et sans fioritures. La rédaction des recettes numériques initiales est rapide, ne durant généralement pas plus d’une semaine ou deux. Cependant, ces brouillons ne sont que des points de départ, et ils sont rapidement améliorés au fil des itérations successives par le ou les Supply Chain Scientist(s) en charge du compte respectif. Cela élimine rapidement les cas limites gênants présents dans les brouillons initiaux.

• La troisième sous-phase est le double run. La recette numérique ne produit plus de résultats absurdes, et les moteurs économiques qui orientent l’optimisation ont été convenus. Cependant, la recette n’est pas encore prête pour la production. Pour avancer, un double run est engagé. La recette numérique est exécutée côte à côte avec le processus existant. Comme la recette est automatisée, les frais généraux organisationnels sont faibles. Chaque jour, les praticiens de la supply chain peuvent comparer les décisions et voir comment les tendances (par exemple, la saisonnalité) se développent. Au cours de plusieurs semaines de double run, la confiance est acquise pour passer au déploiement en production.

À la fin de la phase d’intégration - et si toutes les étapes ont été satisfaites - le déploiement en production commence. Ce déploiement consiste à laisser l’automatisation prendre le relais du processus existant. Cette transition peut également être progressive, en fonction de la capacité du client à superviser le changement nécessaire.

Consultez l’aperçu du calendrier pour une répartition plus détaillée de chaque étape du processus d’optimisation.

1.3 Lokad documente-t-il et publie-t-il un plan de gestion de projet détaillant la portée du projet, le calendrier, les jalons critiques, les ressources, les livrables, les responsabilités, le plan de gestion des coûts, le plan de gestion de la qualité, le plan de gestion des risques et le plan de gestion et de communication des parties prenantes ?

Oui. Tous ces éléments, et plus encore, sont rassemblés dans un unique Manuel de Procédure Conjointe (JPM) pour l’initiative. Les Supply Chain Scientists (SCSs) sont chargés d’initier et de maintenir le JPM pendant toute la durée de l’initiative.

Le JPM de Lokad se concentre sur les questions du “pourquoi ?”. Les JPM sont bien rédigés et sont destinés à être largement accessibles, même pour un public moins technique et/ou non spécialisé. Le JPM capture l’essence de l’intention derrière l’initiative et consolide les connaissances fondamentales au fur et à mesure de l’avancement de l’initiative elle-même.

Lokad estime que de nombreuses initiatives d’entreprise sont entravées par la production de documents inutiles, qui sont, en pratique, impossibles à lire (c’est-à-dire qu’ils sont fastidieux ou techniquement impénétrables). De tels documents ne servent à rien d’autre qu’à cocher des cases fictives. De plus, de nombreux tiers (par exemple, les intégrateurs, les consultants et même la bureaucratie interne) ont tendance à privilégier la quantité à la qualité lorsqu’il s’agit de la documentation du projet.

En revanche, les JPM de Lokad sont destinés à être à la fois lisibles et lus. Les JPM sont des outils utilisés par les SCSs eux-mêmes pour gérer l’initiative. Bien que nous ayons des lignes directrices détaillées sur ce qui est censé être inclus dans un JPM, il revient finalement aux SCSs de prendre des décisions éclairées sur ce qui nécessite le plus d’attention et d’efforts compte tenu des spécificités de l’initiative.

Consultez la conférence Écrire pour les Supply Chains pour plus d’informations sur l’éthique de documentation de Lokad.

1.4 Lokad est-il responsable de la maintenance et de la mise en place du plan de gestion de projet, sous réserve d’approbation(s) du comité de pilotage du projet ? En cas de déviations par rapport au plan, les communiquerez-vous clairement ainsi que les options d’atténuation ?

Oui. Les responsabilités énumérées sont gérées par les Supply Chain Scientists (SCSs) de Lokad. Les détails de la gestion de la communication avec l’entreprise cliente dépendent généralement des termes contractuels propres à l’initiative elle-même.

Il arrive parfois que le nombre d’employés impliqués du côté de l’entreprise cliente soit significativement plus élevé que du côté de Lokad. Afin d’améliorer la productivité des SCSs en charge du compte, bon nombre de nos clients désignent un interlocuteur unique pour l’initiative. Cette personne - ou petite équipe - est chargée de transmettre les informations pertinentes à toutes les parties impliquées du côté de l’entreprise cliente et de solliciter leurs commentaires.

Pour une initiative particulièrement complexe, Lokad met en place un comité de pilotage dédié composé de membres clés de Lokad et de l’entreprise cliente. Bien que cette réunion serve de mécanisme pour obtenir une approbation formelle, la majeure partie du travail substantiel se fait en dehors du comité lui-même. Les SCSs interagissent généralement quotidiennement avec différentes équipes du côté de l’entreprise cliente. Ces équipes sont continuellement informées de toute déviation par rapport au plan et veillent à ce que l’ensemble de l’initiative reste sur la bonne voie. Ces interactions quotidiennes sont une manière beaucoup plus efficace de discuter et de résoudre les problèmes techniques au fur et à mesure de leur apparition, plutôt que d’essayer d’investiguer de gros lots de problèmes lors d’une session de comité de pilotage. Ainsi, le comité de pilotage agit en tant qu’organe de supervision plutôt qu’en tant que groupe de réflexion pour l’initiative.

Note: Les initiatives de supply chain quantitative sont connues pour rencontrer fréquemment des “déviations positives”. Ce sont des surprises bénéfiques dans la recette qui se révèlent pendant la maintenance continue de l’initiative. Essentiellement, ce sont des opportunités “trop bonnes pour être manquées”. En tant que tel, un avantage clé de l’approche de Lokad en matière de communication est la capacité de relayer rapidement et efficacement ces déviations positives au client “au fur et à mesure de leur apparition”, ce qui augmente considérablement l’impact et l’agilité de l’initiative.

1.5 Allez-vous documenter le plan de communication, qui comprend des réunions quotidiennes, des rapports d’état hebdomadaires du groupe de travail et des sessions de revue, ainsi que des rapports et des sessions de revue mensuels du comité de pilotage ? Allez-vous définir les critères d’escalade et garantir un accord mutuel entre l’entreprise cliente et Lokad sur ces détails ?

Oui. Les Supply Chain Scientists (SCSs) de Lokad sont responsables de ces tâches. Les détails de la gestion de la communication au sein de l’entreprise cliente dépendent généralement des termes contractuels de l’initiative elle-même.

Lokad participe volontiers aux réunions quotidiennes lorsque nous sommes sur place au siège de l’entreprise cliente. Habituellement, cependant, nos SCSs travaillent dans les bureaux de Lokad.

Nous regroupons toute la documentation de l’initiative dans un Manuel de Procédure Conjoint (JPM) qui sert efficacement de guide complet pour l’ensemble du projet. Le JPM comprend les notes de toutes les sessions de travail, y compris les rapports du comité de pilotage (le cas échéant).

Bien que Lokad clarifie les critères d’escalade et les lignes directrices, il convient de souligner qu’un Senior SCS chez Lokad est chargé de répondre à toutes les questions ou préoccupations concernant l’initiative. Ainsi, en ce qui concerne l’escalade, la résolution d’un problème préoccupant est généralement transmise d’un Junior SCS à un Senior. Cela s’est avéré suffisant historiquement, avec très peu de situations nécessitant une escalade supplémentaire.

Lokad considère tous les problèmes - aussi mineurs qu’ils puissent paraître - comme méritant une analyse approfondie. Bien que leurs effets soient faciles à résoudre, les problèmes mineurs peuvent poser des problèmes futurs si les causes profondes ne sont pas comprises et traitées. Cela empêche un problème mineur de devenir récurrent. Ainsi, Lokad préfère mettre des personnes hautement compétentes en première ligne, capables de résoudre à la fois le problème immédiat et d’identifier les causes profondes sous-jacentes. Cette approche est préférable à celle de s’appuyer sur un personnel de support non formé qui traite continuellement les mêmes problèmes - un schéma adopté trop fréquemment par de nombreux fournisseurs de logiciels d’entreprise.

Ainsi, le processus d’escalade concis de Lokad est intentionnel, garantissant des résolutions rapides et durables.

1.6 Allez-vous vous assurer que le plan de gestion de projet est approuvé par toutes les parties prenantes dans le cadre de la phase d’initiation du projet ?

Oui. Plus généralement, les Supply Chain Scientists (SCSs) de Lokad suivent le processus qui a été négocié et convenu avec chaque client - conformément aux termes contractuels formels. Ce principe reste applicable tout au long de l’initiative, du début à la conclusion. Le lancement du projet est certainement important, mais étant donné que Lokad ne nécessite pas un engagement à long terme dès le premier jour, cette question est de moindre importance - surtout par rapport à nos concurrents.

Il convient de noter que nous n’avons jamais observé de mauvaises performances d’une supply chain en raison d’un “manque” de bureaucratie et d’autres processus frivoles. Au contraire, les bureaucraties inutiles et les processus inutiles sont les problèmes les plus courants dans les supply chains modernes - présents même dans les entreprises qui semblent par ailleurs avoir des supply chains performantes.

1.7 Allez-vous déployer un chef de projet dédié de Lokad basé au siège de l’entreprise cliente, accompagné d’experts en matière de produits, d’analystes métier et d’experts en interface technique ?

Oui, si de telles dispositions font partie des termes contractuels convenus pour l’initiative. Bien que Lokad ne soit pas opposé à la mise en place d’employés sur site au siège de l’entreprise cliente, cela augmente naturellement le coût de l’initiative. La plupart de nos initiatives sont réalisées à distance et sont soutenues par des visites mensuelles ou trimestrielles en fonction de l’ampleur de l’initiative. Cette pratique est généralement perçue par toutes les parties comme plus efficace que la mise en place d’employés Lokad dans les bureaux du client tout le temps. Il convient de noter que, même si Lokad accepte de mettre en place une équipe permanente au siège de l’entreprise cliente, les employés seront remplacés au fil du temps.

De telles pratiques bénéficient à tous les acteurs, car les Supply Chain Scientists (SCSs) de Lokad sont soumis à un programme de formation continu. Ce programme est essentiel pour garantir que nos employés continuent d’acquérir de nouvelles compétences ou d’affiner les anciennes, indépendamment de leur expérience ou de leur ancienneté. Alors que nous constatons que de nombreux fournisseurs d’entreprise permettent à leurs employés de travailler pendant des mois, voire des années, sur des sites clients à distance, Lokad est convaincu que cette pratique n’est pas compatible avec la fourniture fiable et efficace de programmes de formation de haute qualité.

En particulier, l’un des plus grands atouts des SCSs de Lokad est leur ensemble de compétences exceptionnellement diversifié et étendu. Chaque SCS est formé pour agir dans une variété de rôles, tels que : expert en la matière, analyste métier, expert en interface technique, data scientist et consultant en supply chain. Ces fonctions seraient normalement remplies par plusieurs employés et entraîneraient une augmentation significative des coûts pour le client. Chez Lokad, chaque SCS fournit tous ces services.

Par conséquent, les SCSs ont tendance à être beaucoup plus productifs (moins de personnes signifie moins de friction dans la communication) et à obtenir des niveaux de performance plus élevés. En réalité, les supply chains dépendent de manière critique de la cohérence de bout en bout, ce qui est beaucoup plus facile à réaliser avec un effectif réduit.

1.8 Pendant la phase de mise en œuvre, quelle organisation proposez-vous ? Où les ressources doivent-elles être allouées ?

Pour une initiative typique chez Lokad, nous recommandons à l’entreprise cliente de désigner un praticien expérimenté de la supply chain comme coordinateur de l’initiative, et également de nommer un cadre de la supply chain comme superviseur de l’initiative. Le coordinateur sert de point de contact entre l’équipe de Supply Chain Scientists (SCSs) de Lokad et l’entreprise cliente. Le coordinateur transmettra initialement les demandes d’informations, puis transmettra les demandes de retour d’information. Parallèlement, les SCSs de Lokad travaillent avec les recettes numériques visant à produire les décisions de supply chain souhaitées.

Nous recommandons une réunion hebdomadaire pour examiner l’avancement de l’initiative jusqu’à ce que la phase d’intégration soit terminée. Cette réunion est systématiquement suivie par le coordinateur, le superviseur et le SCS principal du compte chez Lokad. D’autres participants peuvent se joindre au besoin, mais leur présence continue n’est généralement pas nécessaire tout au long de la phase de mise en œuvre/intégration.

Certaines ressources informatiques doivent être allouées à la configuration du pipeline de données dès le début de l’initiative. Lokad est plus efficace que la plupart de ses concurrents à cet égard. Par exemple, nous extrayons automatiquement et directement les données transactionnelles du client, sans aucun nettoyage ou préparation requis du côté du client. À moins que l’entreprise cliente ne soit confrontée à un verrouillage du fournisseur, cette configuration technique nécessite moins de 4 semaines de travail pour un seul contributeur - et parfois beaucoup moins lorsque le data lake est déjà en place.

Ensuite, les SCSs devront recueillir des informations qualitatives sur les processus existants, ainsi que sur les détails de toutes les priorités et contraintes de la supply chain. Une série d’entretiens, facilités par les coordinateurs, aura généralement lieu pour soutenir ce processus. Plus tard, une fois que les SCSs auront développé la ou les recettes numériques, une autre série d’entretiens aura lieu pour examiner les chiffres générés par ces recettes et permettre aux SCSs de les affiner et de les améliorer.

La contribution du superviseur est importante à la fois pour aligner Lokad sur la stratégie globale poursuivie par l’entreprise et pour éviter que l’initiative ne stagne en raison d’indécisions. Par exemple, Lokad peut proposer différentes options pour modéliser les coûts associés à la qualité de service insuffisante. Nous pouvons expliquer les avantages et les inconvénients de ces options en termes non techniques, mais en fin de compte, quelques choix stratégiques doivent être faits.

Naturellement, tout cela dépend des besoins spécifiques de l’initiative. Nous sommes ouverts à d’autres approches organisationnelles si elles conviennent mieux au contexte et aux objectifs spécifiques de l’entreprise cliente.

Pour plus d’informations, Lokad propose plusieurs conférences dédiées à l’exécution tactique et stratégique d’une optimisation réussie de la supply chain.

2. Gestion des ressources et exigences

2.1 Quels sont les besoins en main-d’œuvre pour la mise en œuvre du projet au sein de l’entreprise cliente, notamment le nombre de ressources et leur niveau d’expertise ? Pouvez-vous définir précisément le nombre de ressources pour chaque phase et sous-phase du projet ?

Une initiative typique de Lokad nécessite environ 0,5 à 2 équivalents temps plein (ETP) de ressources employées par l’entreprise cliente au cours des 6 premiers mois - également appelée phase d’intégration. Une fois que l’initiative entre en production, une estimation raisonnable est que le projet nécessitera toujours au moins 0,25 ETP. Naturellement, ces estimations varient considérablement en fonction de la taille et de la complexité de l’entreprise cliente et de ses besoins spécifiques en matière de supply chain.

En termes de ressources requises à chaque étape d’une initiative “typique”, pendant la phase d’intégration, nous avons :

• Mois 1 et 2 : La mise en place du pipeline de données nécessite 4 semaines d’effort à temps plein d’un responsable des données, généralement employé par le service informatique du client. Le responsable des données doit être assez familier avec le paysage applicatif de l’entreprise cliente. Cette exigence peut être réduite si un lac de données est déjà en place, mais elle sera augmentée si le pipeline de données doit faire face à plusieurs systèmes métier (par exemple, 1 ERP par pays). Une fois que le pipeline de données est opérationnel, sa maintenance ne devrait pas nécessiter plus de quelques heures par mois de la part du responsable des données.

• Mois 3 et 4 : La conception de la recette numérique nécessite 2 ou 3 jours par semaine du coordinateur (côté client) de l’initiative, un minimum de 10 heures par semaine de divers praticiens de la supply chain pour fournir des informations de haut niveau, et plus tard pour fournir des commentaires sur les chiffres produits par Lokad. Le coordinateur est censé être familier avec l’entreprise et sa supply chain, et à l’aise avec le travail analytique. Cependant, ce poste ne nécessite pas de compétences informatiques spécialisées ou de compétences spécifiques en science des données. L’examen hebdomadaire de l’initiative nécessite une demi-journée par semaine d’un cadre de la supply chain.

• Mois 5 et 6 : Les exigences sont essentiellement les mêmes que lors de la phase précédente, cependant, l’accent change. Le coordinateur passe maintenant la majeure partie de son temps à préparer le déploiement approprié et à communiquer avec tous les praticiens de la supply chain impactés. De même, le cadre de la supply chain supervise la gestion du changement interne liée aux nouveaux processus découlant de l’initiative de Lokad.

Voir aussi Mise en œuvre et gestion de projet 1.2.

2.2 Vous assurez-vous que des ressources adéquates sont prévues pour soutenir la transition du produit ?

Oui. En règle générale, Lokad recommande de maintenir le même nombre de ressources (par exemple, les mêmes Supply Chain Scientists) lors de la transition de la phase d’intégration à la phase de production. Le retour sur investissement potentiel d’une solution bien entretenue et continuellement améliorée est important. Il est erroné d’aborder la résolution de ces défis avec une mentalité “set-and-forget”, car toute solution technique dérivera inévitablement - et continuellement - vers l’irrélevance et l’obsolescence si elle n’est pas correctement surveillée et entretenue.

Il convient de noter que, étant donné que Lokad automatise les décisions de la supply chain, il n’y a pas d’urgence stricte à requalifier tous les praticiens de la supply chain du client avec un nouveau processus pour maintenir le bon fonctionnement de la supply chain - l’automatisation elle-même est conçue pour s’en occuper. Par conséquent, il n’est pas rare que la refonte complète de l’organisation de la supply chain du client - déclenchée par l’initiative de Lokad - soit achevée quelques mois seulement après la mise en service du projet.

Cette approche simplifiée contraste fortement avec les “forces opérationnelles” souvent coûteuses nécessaires aux fournisseurs de logiciels d’entreprise pour être opérationnels.

2.3 Pouvez-vous garantir que des ressources en personnel et en connaissances suffisantes sont disponibles sur site au siège de l’entreprise cliente pour soutenir la transition du produit ?

Oui, de telles dispositions et exigences sont couvertes par les termes contractuels spécifiques et mutuellement convenus de l’initiative.

Voir également Mise en œuvre et gestion de projet 1.7.

Voir également Gestion des ressources et exigences 2.2.

2.4 Organisez-vous des sessions d’examen des exigences avec les propriétaires de produits commerciaux pour recueillir et documenter les exigences ?

Oui. L’un des premiers objectifs du Supply Chain Scientist est d’acquérir toutes les informations nécessaires sur la supply chain du client. Ce processus est généralement réalisé par le biais d’entretiens avec les parties prenantes pertinentes, y compris les propriétaires de produits commerciaux. Nous essayons également d’examiner attentivement les documents existants (lorsqu’ils sont disponibles), afin de tirer le meilleur parti de ces entretiens.

Cependant, la principale préoccupation de Lokad est de comprendre le “problème” à l’étude, ce qui n’est pas toujours facilité par l’énumération des “exigences”. Par exemple, si un client mentionne qu’il a besoin d’un traitement spécial pour les “slow movers”, nous comprenons que le faible volume est une préoccupation à prendre en compte. Cependant, le traitement spécial de ces SKUs n’est qu’une des nombreuses options qui s’offrent à nous pour répondre à cette préoccupation.

Dans cet exemple, notre préférence serait de déterminer la véritable nature des “slow movers”. En fait, après avoir étudié les points douloureux de la supply chain du client, il se peut que les “slow movers” soient des SKUs qui ont été mal tarifés, regroupés et/ou alloués. Une fois que le problème (les “slow movers”) est mieux compris, cela change complètement la stratégie d’intervention - ce qui rend souvent plus facile à résoudre.

Ainsi, bien que Lokad recueille et documente toutes les exigences du client, notre approche met l’accent sur la découverte de la véritable nature du problème, plutôt que d’accepter sans réserve l’état actuel de la supply chain du client.

Voir Tomber amoureux du problème, pas de la solution pour en savoir plus sur la dichotomie problème-solution.

2.5 Fournissez-vous des estimations d’effort, de coûts et de délais pour les fonctionnalités nécessitant une personnalisation, y compris les interfaces système, et les partagez-vous après l’atelier d’analyse d’adéquation-processus ?

Oui. Ces estimations sont généralement incluses dans notre proposition commerciale initiale. Si un atelier est organisé pour préparer l’initiative, nous utiliserons les informations de l’atelier pour affiner davantage notre proposition.

La plateforme Lokad est programmatique. Ainsi, la mise en œuvre est destinée à être prise en charge par des scripts, écrits en Envision, notre langage de programmation spécifique au domaine dédié à l’optimisation prédictive des supply chains. Par conséquent, Lokad est particulièrement bien adapté pour fournir des fonctionnalités et des interfaces sur mesure, que ces interfaces soient destinées aux personnes ou aux systèmes métier de l’entreprise cliente.

Contrairement à la plupart des logiciels d’entreprise, la programmabilité est une fonctionnalité essentielle pour Lokad. Les scripts Envision mentionnés ci-dessus ne sont pas une « personnalisation » de la solution Lokad au sens habituel. La présence de ces scripts ne constitue pas non plus un écart par rapport à la branche de développement principale de la solution Lokad. En réalité, la programmabilité avancée de Lokad est le chemin d’implémentation prévu.

Par conséquent, nos estimations (coûts, délais, etc.) sont assorties d’un degré de certitude extrêmement élevé. La grande majorité des projets respectent les estimations/budget initial (à tous égards). Cela contraste avec plusieurs concurrents de Lokad, pour lesquels des retards coûteux et des reformulations des termes sont courants.

Voir Étude de cas sur le fiasco SAP de Lidl de 500 millions d’euros pour en savoir plus à ce sujet.

2.6 Allez-vous mettre en œuvre et maintenir une stratégie de rétention raisonnable conçue pour conserver le personnel clé effectuant les services pendant la durée de l’accord ? Allez-vous également maintenir des plans de succession actifs pour chacun des postes clés du personnel de Lokad ?

Oui. Nous conservons en moyenne nos employés pendant 3,5 ans, ce qui représente près du double de la durée d’emploi par rapport à des cohortes similaires (ingénieurs talentueux en informatique ou dans des domaines connexes) sur des marchés similaires (Amérique du Nord et Europe occidentale). Ce segment du marché du travail est extrêmement compétitif et, bien qu’il y ait toujours place à l’amélioration, cela place Lokad bien au-dessus de la plupart de nos concurrents. Par conséquent, la plupart des initiatives de Lokad bénéficient de la présence des mêmes Supply Chain Scientists (SCSs) d’une année sur l’autre.

Cette rétention est attribuable à des salaires compétitifs et à l’investissement continu de Lokad dans la formation de ses équipes. En particulier, le contenu sur la supply chain publié par Lokad sur son propre site web, en particulier notre série de conférences sur la supply chain, peut être considéré comme un sous-produit de l’accent mis par Lokad sur la formation de son propre personnel. En général, les éditeurs de logiciels d’entreprise qui n’ont pas de supports de formation publics n’ont presque jamais de supports de formation privés non plus (même s’ils prétendront invariablement le contraire).

En ce qui concerne les plans de succession, nous avons deux pratiques importantes en place. Tout d’abord, chaque initiative de Lokad est accompagnée d’un Manuel de Procédure Conjointe (JPM). Le JPM est le document principal utilisé par un nouveau SCS pour se familiariser rapidement avec toutes les informations pertinentes et les aspects techniques de l’initiative. Deuxièmement, chaque initiative dispose en permanence d’un SCS principal et d’un SCS secondaire. Même si le SCS secondaire ne contribue pas directement à l’initiative, Lokad consacre suffisamment de temps pour s’assurer que cette personne est prête à prendre en charge l’initiative si nécessaire. Cette pratique atténue largement les complications liées aux congés imprévus et aux départs.

3. Rôles, Responsabilités et Gestion des Parties Prenantes

3.1 Quel niveau de coopération avez-vous avec l’entreprise cliente ?

Le niveau de coopération que nous avons avec nos clients varie, mais dans l’ensemble, il est beaucoup plus élevé que ce qui est généralement attendu d’un fournisseur de logiciels d’entreprise. Les préoccupations liées à la supply chain ne sont pas également importantes pour toutes les entreprises, c’est pourquoi la collaboration tend à être plus forte pour les entreprises où la supply chain est l’épine dorsale (reconnue) de leurs activités.

Le terme “partenaire” a été dilué au point que même les fournisseurs de produits logiciels triviaux (comme les logiciels de suivi du temps) finissent par être appelés “partenaires”. Cependant, après un an ou deux, la plupart de nos clients considèrent leur relation avec Lokad comme un “véritable” partenariat - au sens propre du terme. Ils ont des visages familiers chez Lokad qui ont gagné leur confiance et, par conséquent, ces personnes - généralement des Supply Chain Scientists (SCS) - connaissent intimement leur entreprise. De plus, nos résultats sont souvent jugés suffisamment remarquables pour être présentés personnellement au PDG et/ou au conseil d’administration de l’entreprise, même dans les grandes entreprises.

La collaboration continue avec Lokad permet à nos clients de réorganiser positivement l’ensemble de leur pratique de la supply chain. En fin de compte, toute la chaîne est remaniée, ce qui a un impact positif tant sur les clients que sur les fournisseurs. Il convient de noter que Lokad n’a pas l’intention de remplacer l’expertise stratégique critique qui existe au sein de l’entreprise cliente. Au contraire, Lokad souhaite automatiser les aspects les plus routiniers et répétitifs des processus de prise de décision de la supply chain. Cette approche libère ensuite des ressources client significatives - et souvent rares - qui peuvent être réorientées vers de meilleures utilisations.

3.2 Quels rôles et responsabilités devez-vous mettre en place, à la fois au sein de l’entreprise cliente et de Lokad, pour maximiser l’efficacité de la solution ?

Il existe 4 rôles typiques impliqués dans les initiatives de supply chain quantitative de Lokad.

• Le Leader de la Supply Chain : Ce rôle met l’accent sur l’importance de l’implication de la direction dans l’initiative de supply chain quantitative. Sans avoir besoin de se plonger dans les détails techniques, cette personne doit comprendre et communiquer les idées stratégiques de l’initiative. Son rôle n’est pas de créer des métriques et des KPI, mais plutôt d’évaluer de manière critique et de les remettre en question, en veillant à ce qu’ils soient alignés sur la stratégie globale.

• Le Coordinateur de la Supply Chain : Essentiel pour assurer le bon fonctionnement de l’initiative, cette personne fait le lien entre les différentes équipes internes. Sa responsabilité principale est de recueillir les commentaires, de communiquer avec les parties prenantes et de confirmer/clarifier les processus et les décisions. Il veille à ce que l’initiative soit alignée sur les flux de travail existants de l’entreprise, tout en restant ouvert aux révisions éventuelles des flux de travail à l’avenir.

• L’Officier des Données : Les données sont l’épine dorsale de l’initiative de supply chain quantitative, et cette personne en assure l’accessibilité et la fiabilité. Chargée d’extraire des ensembles de données complets (comme les historiques de ventes et d’achats), elle est responsable de l’automatisation et de la planification de l’extraction des données. Bien que son rôle soit le plus intensif au début de l’initiative, sa contribution est cruciale pour son succès.

• Le Scientifique de la Supply Chain : Ce rôle fusionne les connaissances du Coordinateur de la Supply Chain avec les données de l’Officier des Données pour automatiser les processus de prise de décision. À partir de la préparation des données, le Scientifique de la Supply Chain collabore étroitement avec le Coordinateur pour clarifier les ambiguïtés des données. Ils formalisent ensuite les stratégies en décisions concrètes, telles que les quantités de réapprovisionnement, et mettent en place des tableaux de bord et des indicateurs de performance pour la transparence et le contrôle.

Voir les rôles du projet pour plus d’informations sur les différentes désignations au sein d’une initiative de supply chain quantitative.

3.3 Avez-vous un tableau RACI (Responsable / Accountable / Consulté / Informé) complet pour la phase de mise en œuvre et pour la phase de production ?

Oui. Ces informations peuvent être explicitement présentées sous la forme d’un tableau RACI si elles sont jugées importantes par l’entreprise cliente.

Plus important encore, les Scientifiques de la Supply Chain (SCSs) intègrent cette sorte de matrice afin de prendre des décisions adéquates et rapides au fur et à mesure de l’avancement de l’initiative. En ce qui concerne les problèmes liés à l’optimisation d’une supply chain, l’essentiel est de trouver la meilleure façon de formuler le problème. Ensuite, l’accent est mis sur l’identification de la personne dans l’organisation la mieux placée pour résoudre le problème. Il est essentiel que toute cette analyse soit effectuée rapidement afin de préserver l’élan de l’initiative.

Dans cette optique, les SCSs de Lokad sont désignés pour diriger l’initiative et assumer la responsabilité de la qualité des résultats générés par la recette numérique de Lokad.

En tant que tel, il s’agit d’un petit noyau de spécialistes hautement qualifiés qui sont responsables des décisions de supply chain générées par Lokad, plutôt que d’un “système” ou d’un “processus” élaboré de délégation des responsabilités entre un grand groupe d’intervenants. Lokad estime que de tels systèmes ont tendance à diluer la responsabilité, plutôt qu’à la rigidifier. Nos SCSs sont donc formés pour adopter et opérer avec cette responsabilité, ce qui inclut de s’assurer que les parties prenantes pertinentes de l’entreprise cliente sont consultées et pleinement informées de l’initiative.

3.4 Allez-vous documenter les rôles et responsabilités à l’aide d’une matrice RACI (Responsabilité, Responsable, Consulté et Informé) pour toutes les parties prenantes impliquées dans le projet ? Veillerez-vous à ce que ce document soit discuté et approuvé par toutes les parties concernées ?

Oui. Tous ces éléments (et d’autres) sont rassemblés et documentés dans le Manuel de Procédure Conjointe (JPM). Le JPM est produit par les Scientifiques de la Supply Chain (SCSs) de Lokad (avec des informations collectées directement auprès de l’entreprise cliente). Dans ce document, les paramètres du rôle et de la responsabilité de chaque personne sont détaillés.

Le JPM sert également de ressource continue pour l’initiative et est rédigé par les SCSs affectés à l’entreprise cliente. La rédaction de ce document avec leurs propres mots démontre que les SCSs ont consacré beaucoup de temps à enquêter, diagnostiquer et analyser la supply chain du client et la solution globale (sans se contenter de répéter la littérature préexistante du client).

Toutes les révisions du JPM sont partagées avec l’entreprise cliente. Le JPM lui-même est régulièrement discuté lors des sessions de travail entre Lokad et l’entreprise cliente.

À ce sujet, notre expérience indique que, en cas de désaccord, ceux-ci reflètent généralement un problème organisationnel à résoudre au sein de l’entreprise cliente. C’est pourquoi nous recommandons à l’entreprise cliente de nommer un responsable de la Supply Chain pour superviser l’initiative. L’une de leurs principales contributions est de servir d’intermédiaire dans de tels cas.

3.5 Veillerez-vous à ce que le groupe de travail du projet et les groupes de pilotage soient formés avec des ressources nommées des parties prenantes du projet ? Veillerez-vous à ce que le rythme de fonctionnement soit convenu par toutes les parties concernées ?

Oui. En principe, nous suivons tout processus jugé nécessaire par - et convenu formellement avec - l’entreprise cliente. Les éléments convenus (et les éventuelles modifications apportées au fur et à mesure de l’avancement de l’initiative) sont documentés dans le Manuel de Procédure Conjointe (JPM), qui comprend des détails concernant le groupe de travail du projet et les groupes de pilotage. Grâce aux Scientifiques de la Supply Chain (SCSs) de Lokad, nous disposons des ressources nécessaires pour mettre en place et surveiller ces processus.

De manière anecdotique, l’une des contributions les plus appréciées de Lokad est notre capacité à simplifier les processus - qu’ils soient liés à la supply chain ou de nature bureaucratique. Au fil du temps, nous travaillons activement à éliminer les couches bureaucratiques inutiles des supply chains de nos clients.

4. Transition du système et mise en production

4.1 Quelle est la durée de la transition entre le lancement et la mise en production ?

La durée typique de la phase de mise en service est de 6 mois. Cette phase commence par le lancement et se termine lorsque Lokad est “en production” - c’est-à-dire lorsque nos recommandations automatisées en matière de supply chain orientent efficacement le processus de prise de décision souhaité par le client.

Cette durée peut être réduite de 1 mois si un data lake est déjà en place - un data lake bien construit et documenté peut encore raccourcir la phase de mise en service. À l’inverse, cette phase est généralement prolongée de 1 à 3 mois lorsque le logiciel ou l’environnement système du client est excessivement complexe ou obsolète.

Fait intéressant, la complexité de la supply chain elle-même n’a pas autant d’impact qu’il n’y paraît, car Lokad s’efforce de définir un périmètre suffisamment précis pour être réalisable dans le délai prévu. Notre expérience indique que les phases de mise en service qui durent plus de 6 mois mettent l’initiative en danger de stagnation. Ainsi, nous concevons activement le périmètre pour atténuer ce risque.

Ces retards ont peu à voir avec la configuration technique de Lokad elle-même. Dans l’ensemble, le calendrier proposé sert non seulement à des fins techniques (automatisation de l’extraction des données, test des recettes numériques, etc.), mais permet également aux Supply Chain Scientists (SCSs) de Lokad de maîtriser pleinement tous les aspects spécifiques de l’entreprise cliente, et aux équipes de la supply chain d’« assimiler » l’approche de Lokad - ce qui représente généralement un changement par rapport au processus hérité de l’entreprise cliente.

4.2 Combien de visites sur site prévoyez-vous ? Combien d’ateliers sur site prévoyez-vous ?

Le nombre de visites et d’ateliers sur site est négocié dans le cadre des conditions contractuelles spécifiques avec l’entreprise cliente, bien que l’on note que les frais de déplacement peuvent affecter les honoraires facturés par Lokad. Ainsi, l’inclusion de visites sur site est en fin de compte une décision à prendre par l’entreprise cliente, et Lokad s’adaptera à la fréquence souhaitée.

Lorsque l’objectif de l’entreprise cliente est de rendre l’initiative aussi légère que possible, nous sommes à l’aise avec une initiative entièrement à distance, c’est-à-dire sans visites sur site. Nous recommandons cette approche pour les petites entreprises (chiffre d’affaires annuel inférieur à 100 millions de dollars) et les entreprises qui sont généralement à l’aise avec les contributeurs à distance (comme les grandes entreprises de commerce électronique). Environ la moitié des initiatives menées par Lokad appartiennent à cette catégorie.

Lorsque l’objectif de l’entreprise cliente est de maximiser les chances de réussir la gestion du changement, nous sommes à l’aise avec des visites mensuelles - et éventuellement plus fréquentes si nécessaire. Pour les grandes entreprises (chiffre d’affaires annuel supérieur à 1 milliard de dollars), nous recommandons au moins une visite/atelier trimestriel sur site. Cette approche contribue à développer l’alignement à l’échelle de l’entreprise, notamment lorsque des équipes importantes sont impliquées.

Pour nos clients en Europe occidentale, nous avons tendance à avoir plus de visites (généralement d’une journée) que d’ateliers lorsque nous sommes sur place. Pour nos clients en dehors de l’Europe occidentale, nous avons tendance à faire plus d’ateliers (généralement de plusieurs jours) que de visites lorsque nous sommes sur place. Cette différence est une simple question de coûts de déplacement associés et de logistique.

4.3 Quel est un équilibre idéal entre les réunions à distance et les réunions sur site ?

Pour une initiative de supply chain quantitative, la majorité des réunions doivent être à distance. La plupart des réunions sont courtes (30 minutes ou moins) et n’impliquent que deux participants : un Supply Chain Scientist de Lokad et un praticien de la supply chain de l’entreprise cliente. De plus, les réunions à distance sont bénéfiques pour des tâches techniques spécifiques, car tous les participants ont accès à leur propre configuration informatique, y compris l’accès à de grands écrans. Cela est particulièrement utile lorsque les participants doivent examiner des rapports complexes.

Cependant, Lokad ne sous-estime pas la valeur des réunions sur site avec les clients. Les réunions sur site facilitent souvent la transmission d’idées complexes, la discussion de perspectives et/ou la révision des attentes entre les parties. Ainsi, nous recommandons d’adopter un rythme régulier pour les réunions sur site (par exemple, hebdomadaire/mensuel/trimestriel…). Lokad considère de telles réunions sur site comme des événements importants, en particulier lorsque Lokad accueille le client.

Cette approche permet aux deux parties de maintenir des réunions à distance décontractées, pratiques et aussi fréquentes que nécessaire.

4.4 Est-ce que vous aidez l’entreprise cliente à effectuer une vérification de la qualité de l’environnement de production pour évaluer sa préparation à la mise en service, y compris la configuration des interfaces ?

Oui. En fait, Lokad va au-delà de simplement aider l’entreprise cliente dans son évaluation de la préparation à la mise en service. L’une des principales responsabilités des Supply Chain Scientists (SCS) de Lokad est de prendre en charge la solution livrée à l’entreprise cliente de bout en bout. En d’autres termes, bien qu’un système mécanisé (une flotte de machines) génère les résultats, c’est toujours une personne qui assume la responsabilité personnelle du système. Ils veillent à l’exactitude, à la pertinence et à l’adéquation du pipeline de traitement des données de bout en bout, en tenant également compte des préoccupations commerciales globales du client.

Étant donné leur propension aux erreurs, les interfaces logicielles méritent une attention particulière, et le SCS est bien équipé pour aider à évaluer leur intégrité. Lokad évalue cette intégrité du côté de l’entrée (lorsque Lokad reçoit des données historiques de l’entreprise cliente) et du côté de la sortie (lorsque Lokad renvoie les décisions de la supply chain à l’entreprise cliente). Pour cette tâche, Lokad utilise des méthodologies et des technologies spécifiques.

Veuillez consulter les paradigmes de programmation pour la supply chain pour mieux comprendre le type de technologies que Lokad utilise pour garantir la préparation à la mise en service.

4.5 Préparez-vous le document de stratégie de transition et de migration de la production pour gérer la transition transparente des opérations commerciales (de l’application métier existante à la nouvelle application métier) pour l’entreprise cliente ?

Oui. La transition est documentée dans notre Manuel de Procédures Conjointes (JPM). Cette documentation approfondie, produite par les Supply Chain Scientists (SCS) de Lokad, garantit que les praticiens et les dirigeants de la supply chain ont accès à des documents bien rédigés qui expliquent adéquatement le processus en termes compréhensibles. Les SCS font des efforts notables pour s’assurer que ce document est accessible à un public non technique (bien que certaines annexes puissent être assez techniques).

De plus, l’approche de double exécution de Lokad est particulièrement adaptée pour assurer une transition en douceur du processus hérité à la nouvelle solution. “Double exécution”, dans ce contexte, fait référence à la pratique où Lokad fonctionnera simultanément avec le processus de prise de décision hérité sur l’ensemble de l’initiative. Cette pratique n’est rendue possible que grâce à la nature robotisée du processus de prise de décision hérité par Lokad, ce qui garantit que les recettes numériques mises en œuvre par les SCS de Lokad fonctionnent de manière satisfaisante dans des conditions de production exactes, sur l’ensemble de l’initiative, pendant des semaines avant la mise en service réelle, où les décisions de Lokad remplacent le processus hérité.

Il convient de noter que cette double exécution n’est généralement pas possible avec les technologies et méthodologies alternatives proposées par nos concurrents. En effet, comme ils ne robotisent pas les décisions de la supply chain, les surcharges associées à une double exécution sont importantes. Par conséquent, la double exécution est, au mieux, effectuée sur une petite portée qui ne reflète pas réellement les conditions de production. En conséquence, lorsque cette approche est adoptée, l’extension tardive de la portée conduit invariablement à des incidents de production qui auraient pu être entièrement évités avec une double exécution à grande échelle.

4.6 Fournissez-vous à l’entreprise cliente la portée, les délais et les critères de réussite de l’exécution pilote à examiner et à approuver ?

Oui. La portée est toujours détaillée dans l’accord contractuel entre Lokad et l’entreprise cliente. Elle prend généralement la forme d’un type donné de décision de la supply chain (par exemple, le réapprovisionnement des stocks ou l’allocation des stocks) sur un ensemble de sites et/ou sur un ensemble de systèmes commerciaux.

Le délai est généralement inférieur à 6 mois (du lancement à la production). Bien qu’un délai projeté soit toujours inclus dans notre proposition commerciale, il peut ne pas être spécifié dans l’accord contractuel. Le délai contraignant représente un engagement mutuel, et le rythme de l’initiative Lokad dépend de l’exécution en temps voulu de certaines étapes par l’entreprise cliente, notamment la construction d’un pipeline de données vers Lokad.

En ce qui concerne les critères de réussite, la décision est toujours prise unilatéralement par l’entreprise cliente. Bien que nous puissions documenter les principes directeurs qui devraient soutenir cette décision, une décision non unilatérale serait inhabituelle. En d’autres termes, un fournisseur ne devrait pas être en mesure de décider que l’exécution pilote a été un succès si le client pense le contraire.

Voir également Mise en œuvre et gestion de projet 1.2.

Veuillez consulter Évaluer les résultats d’une initiative de Supply Chain Quantitative pour en savoir plus sur ce point nuancé.

4.7 Organiserez-vous la réalisation des exécutions pilotes pour garantir a) l’adéquation des données, b) la configuration du système et la préparation de l’application, c) la conformité des processus/systèmes, et d) l’adéquation globale ?

Oui. En règle générale, nous traitons une exécution pilote - destinée à fournir une optimisation de la supply chain - exactement comme nous traiterions une initiative “réelle” destinée à être mise en production. Pour tout ce qui concerne l’optimisation de la supply chain, une exécution pilote adéquate est indiscernable d’une configuration pré-production approuvée pour une utilisation en production.

L’équipe de Supply Chain Scientists (SCS) de Lokad est responsable de tout cela. D’après notre expérience, l’adéquation des données est rarement un problème dans les entreprises qui sont passées au numérique il y a de nombreuses années (voire des décennies). Tant qu’il existe un système commercial pour suivre ce qui est acheté, produit, stocké et vendu, l’initiative est presque garantie d’avoir des données adéquates. Le défi consiste à donner un sens aux données qui n’ont pas été initialement collectées pour soutenir l’optimisation de la supply chain.

Voir mauvaises données pour plus d’informations sur ce point.

5. Gestion du changement et des risques

5.1 Quel soutien pouvez-vous offrir à l’entreprise cliente pour l’aider à gérer la gestion du changement associée à la mise en œuvre de l’initiative ?

Tous les clients bénéficient de l’engagement total des Supply Chain Scientists (SCS) de Lokad, tous formés pour gérer les exigences techniques et non techniques d’une initiative d’optimisation de la supply chain. Les SCS aident au processus de gestion du changement de différentes manières, notamment en proposant des améliorations aux processus existants pour les praticiens de la supply chain employés par l’entreprise cliente.

• Production de supports de formation pour intégrer les membres/équipes de l’entreprise cliente.

• Assistance à la gestion de la supply chain en quantifiant en dollars ou en euros (ou dans la devise choisie par le client) l’impact des changements apportés à la supply chain.

Il convient de noter que la gestion du changement peut représenter un engagement de temps important pour un SCS. Bien que chaque SCS possède des compétences et une expérience uniques pour aider la direction de la supply chain dans la gestion du changement, cette responsabilité entre en concurrence avec toutes leurs autres responsabilités.

Ainsi, les termes contractuels négociés entre Lokad et chaque client précisent la quantité de ressources - c’est-à-dire la taille de l’équipe de SCS - qui sera disponible pour soutenir l’initiative. Nos propositions commerciales prévoient généralement que les SCS fourniront un certain soutien à la gestion du changement. Cependant, nos propositions ne reflètent généralement pas un soutien “à grande échelle” à la gestion du changement - sauf si cela est explicitement demandé par le client.

5.2 Pendant la phase de production, quelle est votre vision de la gestion du changement ? Quels sont les principaux jalons ? À quoi ressemble la nouvelle organisation après la mise en œuvre réussie de la nouvelle solution ?

Une fois que Lokad est en production, une classe entière de décisions de la supply chain est automatisée. L’objectif est alors de transformer la pratique de la supply chain en une entreprise capitaliste. Chaque heure passée par un praticien de la supply chain doit contribuer à l’amélioration continue des recettes numériques. Il s’agit d’un changement par rapport à la pratique de la supply chain “classique” où la grande majorité des efforts de chaque jour sont alloués à maintenir l’entreprise en activité pour un jour de plus. Naturellement, la transition vers cette forme de supply chain créatrice de valeur est progressive.

• Le premier jalon consiste à amener les praticiens de la supply chain à reconnaître que Lokad leur permet de se débarrasser de la plupart des processus hérités. Par exemple, il est logique de revoir les quantités de réapprovisionnement quotidiennes lorsque ces quantités sont fréquemment incorrectes. Cependant, par conception, les quantités de Lokad sont déjà fiables et n’ont pas besoin d’être examinées plus en détail. En fait, 0% d’absurdité dans les chiffres générés par Lokad est le critère principal pour une mise en production réussie. La confiance que les praticiens de la supply chain peuvent accorder aux chiffres de Lokad libère naturellement beaucoup de temps qui peut être mieux utilisé.

• Le deuxième jalon consiste à avoir quelques “premiers utilisateurs” parmi les praticiens de la supply chain. Ce sont généralement des personnes qui parviennent rapidement à se détacher du processus hérité non créateur de valeur - par exemple, l’examen manuel des chiffres - afin de se concentrer sur l’amélioration continue de la supply chain grâce à ses recettes numériques. Ils peuvent commencer à aborder de nombreuses questions importantes au-delà des simples aspects techniques mineurs (par exemple, l’entreprise cliente examine-t-elle sa qualité de service du bon point de vue ?).

• Le troisième jalon consiste à ce que la majorité des praticiens de la supply chain se tournent vers l’extérieur (clients et fournisseurs) plutôt que vers l’intérieur. En fin de compte, la supply chain doit fournir un alignement qui dépasse les limites de l’entreprise cliente. Cela élargit le pool d’informations collectées et contribue à affiner davantage les recettes numériques.

• Le premier jalon consiste à amener les praticiens de la supply chain à reconnaître que Lokad leur permet de se débarrasser de la plupart des processus hérités. Par exemple, il est logique de revoir les quantités de réapprovisionnement quotidiennes lorsque ces quantités sont fréquemment incorrectes. Cependant, par conception, les quantités de Lokad sont déjà fiables et n’ont pas besoin d’être examinées davantage. En fait, le critère principal pour une mise en production réussie est que les chiffres générés par Lokad ne contiennent aucune absurdité à 0%. La confiance que les praticiens de la supply chain peuvent accorder aux chiffres de Lokad libère naturellement beaucoup de temps qui peut être mieux utilisé.

La nouvelle organisation est beaucoup plus proche d’une entreprise de logiciels. Il y a peu de tâches répétitives de la supply chain qui sont traitées manuellement - car les tâches répétitives sont maintenant automatisées. Il y a aussi beaucoup moins d’urgences (encore une fois, grâce à l’automatisation). La réduction des tâches routinières entraîne une augmentation de la variété des tâches pour le praticien de la supply chain. En général, cela se traduit par moins de temps et d’efforts consacrés au contrôle de la supply chain, mais on attend davantage de la direction pour former les employés afin qu’ils puissent tirer parti du temps et des efforts supplémentaires disponibles.

Voir (Software) Product-oriented Delivery for Supply Chain pour en savoir plus sur cette transition.

5.3 Comment gérez-vous le changement de flux de travail pour les utilisateurs finaux ? Tout d’abord, avec l’intégration de Lokad, puis avec l’évolution de Lokad elle-même.

Par conception, les décisions de la supply chain générées par Lokad ne nécessitent pas de flux de travail. En fait, automatiser toutes les étapes de génération des décisions de la supply chain est l’arrangement souhaité.

Cependant, si le client le demande explicitement, Lokad est capable d’introduire un “flux de travail” qui reflète l’ancien processus. Il faut comprendre que cela ne vise qu’à faciliter la gestion du changement et n’est en aucun cas une exigence pour la réussite de la recette numérique. À mesure que les employés du client deviennent plus familiers avec les décisions générées par Lokad et développent une plus grande confiance en elles, le “flux de travail” peut être progressivement simplifié, jusqu’à ce qu’il soit complètement supprimé.

En ce qui concerne l’évolution de Lokad, notre plateforme est programmable et gérée par Envision (notre langage de programmation spécifique au domaine). Toutes les modifications/mises à jour d’Envision sont effectuées à l’aide de scripts automatisés, et ce processus est programmé de manière à ce que les initiatives de la supply chain hébergées par Lokad ne soient pas affectées.

5.4 Pouvez-vous tenir un registre des problèmes et des risques qui comprend un plan de mitigation, des tâches, des responsabilités, des délais et un état (non démarré, en cours, clos, en attente) ? Le chef de projet de Lokad sera-t-il responsable du suivi de tous les problèmes et risques et de la résolution en temps voulu ou de la gestion des escalades si nécessaire ?

Oui. La plateforme de Lokad est dotée de son propre gestionnaire interne de problèmes/tickets/tâches. Cette fonction offre toutes les fonctionnalités habituelles que l’on attend généralement d’un tel outil, telles que la gestion des statuts, des priorités, des affectations, des notifications, etc. De plus, nous maintenons séparément un Manuel de Procédures Conjointes (JPM) qui présente de manière exhaustive et bien organisée l’initiative avec tous les délais de haut niveau pertinents. Les Supply Chain Scientists (SCS) de Lokad sont responsables de la supervision du gestionnaire de tâches. Ils veillent à ce que les problèmes et les préoccupations soient traités rapidement.

Les escalades sont possibles mais rares. Le même SCS qui gère/examine les tâches les résoudra également. Les SCS seniors chez Lokad remplissent un large éventail de rôles : expert en supply chain, ingénieur de données, intégrateur de données, analyste commercial, data scientist, chef de projet, consultant en changement, etc.

La possibilité de contacter facilement les SCS est quelque chose que nos clients citent régulièrement comme un avantage majeur. Le client peut interagir immédiatement avec la personne dont le travail consiste à superviser la résolution satisfaisante de tous les problèmes, plutôt que de devoir naviguer à travers plusieurs niveaux de bureaucratie pour - espérons-le - parler à quelqu’un capable de les aider.

Dans le cas où un problème nécessite des compétences en dehors de l’expertise d’un SCS (par exemple, un problème technique avec l’architecture de la plateforme), ils supervisent néanmoins la résolution rapide du problème et agissent en tant que premier point de contact pour le client concerné.

5.5 Offrez-vous des services de conseil en gestion du changement organisationnel pour aborder l’introduction et la modification des processus métier, ainsi que la désactivation des processus existants ?

Oui, si l’entreprise cliente souhaite que son partenariat avec Lokad inclue des services de conseil en gestion du changement. Il convient de noter que l’expertise principale de Lokad réside dans l’optimisation prédictive de la supply chain et non dans la gestion du changement. Notre approche de la gestion du changement est également plus conventionnelle que nos pratiques en matière de supply chain. Cette approche, si elle est mise en œuvre, limiterait le nombre de tiers impliqués dans le projet.

Alternativement, si l’entreprise cliente préfère conserver les services d’un spécialiste de la gestion du changement pour compléter Lokad, nous les soutiendrons en partageant autant que l’entreprise cliente jugera prudent.

6. Personnalisation et fonctionnalités du système

6.1 Organisez-vous des sessions pour hiérarchiser les exigences de personnalisation, en veillant à comprendre les impacts commerciaux dus aux lacunes du produit et à parvenir à un accord mutuel sur la priorité de la publication des personnalisations ?

Oui. Les Supply Chain Scientists (SCS) de Lokad sont responsables de ce processus. En fait, Lokad se distingue sur deux fronts en ce qui concerne cette hiérarchisation. Premièrement, un SCS est capable de mettre en œuvre indépendamment la personnalisation et est donc capable de fournir des informations claires sur les ressources et les délais en jeu.

Cela améliore considérablement la qualité de la hiérarchisation, car l’entreprise cliente bénéficie d’un expert capable d’équilibrer facilement les avantages de tout changement de la supply chain avec les coûts associés à ce changement.

Deuxièmement, la philosophie globale de Lokad, “Supply Chain Quantitative”, met l’accent sur une perspective purement financière. Ainsi, le SCS soutient l’entreprise cliente en fournissant des estimations quantitatives (en dollars ou en euros) de l’impact d’un changement potentiel à apporter à la solution. Cette stratégie affine l’initiative en évitant le goulot d’étranglement traditionnel de la discussion sur ce qui doit être hiérarchisé. Au lieu de cela, Lokad rationalise ce processus en donnant la priorité aux problèmes qui ont le plus grand impact financier.

6.2 Pouvez-vous réaliser une étude d’adéquation des processus métier pour identifier les opportunités d’automatisation, documenter les processus futurs souhaités et déterminer les lacunes dans la fonctionnalité du produit ? Pouvez-vous suggérer des solutions de contournement acceptables lorsque des lacunes dans la fonctionnalité du produit sont identifiées ?

Oui. Les Supply Chain Scientists (SCS) de Lokad sont responsables de ce processus. Bien qu’une étude initiale soit réalisée au début de l’initiative, ce processus se poursuit tout au long de la phase de production. Il fait partie de notre approche visant à poursuivre les améliorations continues de la solution.

En ce qui concerne l’optimisation de la supply chain, les lacunes sont rarement une question de “fonctionnalité”, mais plutôt une question de “performance”. Par exemple, le défi consiste non seulement à générer des quantités de réapprovisionnement (fonctionnalité), mais également à s’assurer que les quantités générées sont les plus rentables (performance).

Ainsi, les SCS s’attachent à identifier et à résoudre les “lacunes de performance”, qui nécessitent parfois des fonctionnalités supplémentaires ou une réingénierie de la solution. Cela peut impliquer l’ajout ou la suppression de fonctionnalités pour optimiser les performances globales.

À ce sujet, la plateforme de Lokad est programmable. Ainsi, toute “lacune de fonctionnalité” perçue peut être résolue en introduisant (ou en ajustant) quelques lignes de code Envision. Cette programmabilité est précisément ce qui permet à Lokad de fournir des solutions sur mesure à chaque client.

6.3 Pouvez-vous fournir un agenda détaillé pour les ateliers d’analyse d’adéquation des processus, y compris les attentes des experts métier du côté du client, au moins une semaine avant le début des ateliers ?

Oui. Les Supply Chain Scientists (SCS) de Lokad fournissent un agenda pour chaque atelier. Nous veillons à ce que l’agenda soit communiqué au moins une semaine avant l’événement. Si des instructions explicites sont données par l’entreprise cliente, telles qu’un délai pour fournir les agendas, nous les suivrons. En l’absence d’instructions, nous structurerons les ateliers (y compris le calendrier et la communication de toutes les étapes nécessaires du côté du client) de manière intelligente et professionnelle.

6.4 Vous assurez-vous que les documents de demande de personnalisation du produit sont examinés conjointement et approuvés par l’entreprise cliente ?

Oui, ces documents seront fournis à l’entreprise cliente et seront ensuite approuvés par celle-ci.

Veuillez noter que les choix de conception de la plateforme de Lokad éliminent largement le besoin de “personnalisation” - du moins dans le sens où ce terme est généralement compris dans les cercles des logiciels d’entreprise. La plateforme de Lokad est programmable, utilisant Envision - notre langage de programmation spécifique au domaine dédié à l’optimisation prédictive de la supply chain.

Ainsi, les solutions de Lokad sont toujours “personnalisées” dans le sens où elles sont entièrement adaptées aux besoins spécifiques de l’entreprise cliente. Cependant, cette personnalisation est livrée de manière à ce que la solution fasse partie de la gamme de produits principale de Lokad. Il s’agit de l’approche préférée (et délibérément conçue) de Lokad, et ne présente aucun problème de maintenabilité.

6.5 Aidez-vous l’entreprise cliente à établir une connectivité d’interface avec des systèmes externes, ainsi qu’à tester et certifier les interfaces ?

Oui. Les Supply Chain Scientists (SCS) de Lokad apportent leur soutien pour configurer, tester, valider et documenter les interfaces entre les systèmes exploités par l’entreprise cliente et Lokad. Les SCS peuvent être complétés par des ressources informatiques internes chez Lokad pour les aspects techniques de bas niveau, tels que les protocoles de réseau ou de sécurité.

Les interfaces système ne sont généralement pas “certifiées” par un organisme de certification tiers. Les interfaces sont “formellement spécifiées” par le biais de spécifications techniques convenues conjointement entre le service informatique de l’entreprise cliente et Lokad. Ces spécifications techniques soutiennent les obligations mutuelles des entreprises : en bref, l’entreprise cliente s’engage à fournir les données requises à Lokad en temps voulu ; Lokad, à son tour, s’engage à fournir les résultats en temps voulu également.

6.6 Fournissez-vous des documents de spécification d’interface lors des ateliers, y compris des messages d’exemple ?

Oui, Lokad fournit des spécifications d’interface lors des ateliers. Des messages d’exemple peuvent être inclus si l’entreprise cliente le souhaite.

Étant donné la nature du service de Lokad, cependant, les “messages d’exemple” prendront très probablement la forme de tableaux - car cela représente plus précisément la sortie générée par Lokad pour le client. Pour référence, la grande majorité des spécifications techniques des interfaces se concentreront sur les tableaux et leurs formats, ainsi que sur les modèles d’extraction de tableaux et les calendriers de transfert.

6.7 Partagez-vous les processus de demande de modification et de gestion des versions ?

Oui. Les Supply Chain Scientists (SCS) de Lokad sont responsables de ce processus. Il est important de noter que Lokad dispose de deux niveaux de modifications et de versions, ce qui est différent des logiciels d’entreprise typiques.

Tout d’abord, les modifications spécifiquement apportées aux clients sont mises en œuvre par les SCS eux-mêmes. Ces modifications se produisent fréquemment, souvent plusieurs fois par jour, notamment pendant la phase de mise en service. Ces modifications sont une réponse directe aux besoins de l’entreprise cliente et impliquent une communication considérable entre les deux parties.

Deuxièmement, nous apportons des mises à jour à la plateforme de Lokad, généralement par le biais de mises à jour d’Envision - notre langage de programmation spécifique au domaine dédié à l’optimisation prédictive de la supply chain. Ces modifications sont conçues pour être transparentes pour les entreprises clientes. Si désiré, les détails de ces mises à jour peuvent être fournis, et une grande partie de ces informations est rendue publiquement disponible.

Voir Environnement VM Envision et Architecture Générale pour plus d’informations sur l’évolution de la plateforme de Lokad.

7. Tests d’Acceptation Utilisateur (TAU)

7.1 Aidez-vous l’entreprise cliente à configurer l’environnement de test TAU (Tests d’Acceptation Utilisateur) avec des données spécifiques au contexte et des configurations système ?

Oui. Les Supply Chain Scientists (SCS) de Lokad sont responsables de ce processus. Lokad propose des innovations méthodologiques et techniques uniques à cet égard.

En termes de méthodologie, nous privilégions la conception de listes prioritaires, où les éléments sont classés par ordre décroissant de retour sur investissement (ROI) pour l’entreprise. Cet aspect est essentiel pour garantir que le temps des utilisateurs finaux n’est pas gaspillé à examiner de grandes quantités de données largement non pertinentes.

En termes de technologie, la plateforme de Lokad a été spécifiquement conçue pour prendre en charge simultanément plusieurs environnements pour une initiative donnée. Ces environnements sont une fonctionnalité native de notre plateforme SaaS multi-locataire, et peuvent donc être introduits avec un minimum de surcharge, tant en termes de ressources de calcul que de temps d’administration système.

Voir également Tests d’Acceptation Utilisateur 7.3.

7.2 Configurez-vous les environnements de pré-production, de production et de formation des tests TAU (Tests d’Acceptation Utilisateur) conformément aux processus ToBe définis ?

Oui. Étant donné la grande programmabilité de la plateforme de Lokad, nous pouvons exercer un contrôle total sur les configurations. Cela est rendu possible grâce à Envision - notre langage de programmation spécifique au domaine dédié à l’optimisation prédictive des supply chains.

Cette approche permet à différents environnements d’utiliser la même configuration pour toutes les parties qui ne sont pas sujettes à des changements - en utilisant le même code chaque fois que possible. Cela réduit considérablement les différences accidentelles entre les environnements, ce qui peut perturber les utilisateurs et compromettre l’intégrité du processus de TAU.

De plus, faire évoluer une configuration d’une étape à une autre est simple avec notre conception. L’utilisation d’une base de code pour les modifications de configuration est plus efficace que les méthodes traditionnelles d’interface utilisateur.

7.3 Fournissez-vous des environnements distincts de tests TAU (Tests d’Acceptation Utilisateur), de migration de données, de pré-production (pre-prod), de production et de formation pour le produit (y compris les interfaces requises) à l’entreprise cliente et aux systèmes externes ?

Oui. La plateforme de Lokad a été spécifiquement conçue pour prendre en charge simultanément plusieurs environnements pour une initiative donnée. Ces environnements sont une fonctionnalité native de notre plateforme SaaS multi-locataire, et peuvent donc être introduits avec un minimum de surcharge, tant en termes de ressources de calcul que de temps d’administration système.

Avec Lokad, la duplication de l’ensemble de l’environnement de production, y compris toutes les données de production, est réalisée sans doubler l’emprise de stockage des données. En interne, les données identiques entre les deux environnements sont mutualisées. De plus, notre conception en temps constant garantit que la charge de travail d’un environnement n’affecte pas négativement les performances d’un autre environnement.

Cependant, la plupart des éditeurs de logiciels d’entreprise contournent tout le problème en se contentant de “cloner” la configuration principale. Le clonage - ou la duplication pure et simple - est facile mais gaspilleur. Le clonage signifie que la quantité de ressources (personnes et machines) augmente de manière linéaire avec le nombre d’environnements - par exemple, trois environnements triplent les coûts initiaux. Pour toute supply chain de taille importante, cela se traduit par des coûts considérables.

7.4 Garantissez-vous la résolution en temps voulu de tous les défauts afin de garantir que les tests TAU (Tests d’Acceptation Utilisateur) soient terminés dans les délais mutuellement convenus ?

Oui, à condition que des définitions nuancées de “résolution” et de “défaut” puissent être convenues. Dans l’ensemble, les Supply Chain Scientists (SCSs) de Lokad sont chargés de résoudre tous les problèmes qui compromettent l’objectif principal de l’initiative : augmenter le retour sur investissement. Dans un scénario typique, le SCS propose une action appropriée et un calendrier correspondant, que l’entreprise cliente valide ou met à jour à sa discrétion.

Il est essentiel de souligner que lorsqu’il s’agit de supply chain, il n’y a pas de “solutions parfaites”, seulement de meilleurs et de pires “compromis”. En d’autres termes, on ne peut pas vraiment résoudre un problème où deux valeurs ou plus sont en opposition complète.

Par exemple, les stocks périssables périmés sont gaspillés, mais lorsqu’il s’agit de produits périssables, un tel gaspillage ne peut pas être complètement éliminé sans créer un problème de “qualité de service” conséquent. Un équilibre doit être trouvé entre les stocks morts et les ruptures de stock. Pourtant, à la fois les “stocks morts” et les “ruptures de stock” sont des défauts en quelque sorte.

En bref, les SCS peuvent résoudre des problèmes “banals” au fur et à mesure qu’ils se présentent, comme corriger une erreur d’analyse lors de la lecture d’un fichier (un bug logiciel). Cependant, l’objectif principal d’une solution quantitative de supply chain n’est pas de “résoudre des problèmes”, mais d’augmenter le retour sur investissement (en dollars ou en euros). Lokad atteint cette forme de “résolution” grâce à une approche intelligente et financièrement motivée des compromis de la supply chain.

7.5 Est-ce que vous assistez l’entreprise cliente dans la revue des scénarios de test UAT (User Acceptance Testing), des cas de test et des données de test ?

Oui. Les Supply Chain Scientists (SCS) de Lokad sont responsables de ce processus.

Cependant, en ce qui concerne l’optimisation de la supply chain, les ensembles de données plus petits que l’ensemble de production complet ne sont généralement pas suffisants. En pratique, les scénarios, les cas de test et les données de test doivent être (presque) aussi grands que l’ensemble de production pour refléter une perspective de supply chain de bout en bout. Cette exigence n’a rien à voir avec Lokad ; c’est simplement la nature de la supply chain.

7.6 Est-ce que vous garantissez un support sur site au siège de l’entreprise cliente pendant la phase de test UAT (User Acceptance Testing) ?

Oui. Le support sur site est régi par l’accord contractuel entre Lokad et l’entreprise cliente. Cet aspect est toujours négocié au cas par cas avec chaque client.

Il convient de noter qu’une initiative de supply chain quantitative avec Lokad comprend une amélioration continue de la supply chain, il n’y a donc pas de période UAT fixe. Les tests commencent généralement à la fin du deuxième mois, atteignent leur apogée au quatrième mois, puis se stabilisent à partir du sixième mois.

En consacrant des ressources continues au perfectionnement de nos recettes numériques (algorithmes dédiés à l’optimisation de la supply chain), Lokad garantit à chaque client une initiative à jour.

Voir aussi Mise en œuvre et gestion de projet 1.7.

8. Support après la mise en œuvre et audit

8.1 Pouvez-vous vous assurer que les observations des tests pilotes sont documentées et que les actions à entreprendre sont attribuées aux parties prenantes concernées des départements technique, informatique et fournisseur de l’entreprise cliente, et également suivies jusqu’à leur résolution ?

Oui. Les Supply Chain Scientists (SCS) de Lokad créent et maintiennent un Manuel de Procédures Conjointes (JPM) pour chaque initiative. Il contient toutes les informations pertinentes pour l’initiative. Il est important de noter que le JPM est conçu pour être accessible à un public non technique (bien que certaines sections et annexes soient assez techniques).

Les actions de haut niveau sont documentées dans le JPM. Cependant, les actions mineures sont généralement gérées avec le gestionnaire de tâches sur la plateforme de Lokad. Ces actions mineures sont de courte durée et le gestionnaire de tâches facilite leur suivi et leur clôture mieux que le JPM.

8.2 Pouvez-vous vous assurer que des rapports de qualité et de conformité suffisants sont disponibles pour surveiller l’utilisation et l’adoption du système ?

Oui. Les Supply Chain Scientists (SCS) de Lokad mettent généralement en place une instrumentation dédiée à cette fin lors de la dernière étape de l’intégration, juste avant le lancement officiel.

De plus, Lokad peut suivre l’alignement entre les décisions de la supply chain qu’il génère et les décisions réelles prises dans la supply chain. Cela est fait pour identifier les sources potentielles de divergence, telles que les bugs ou les problèmes dans les systèmes du client, qui pourraient affecter la mise en œuvre des recommandations de Lokad.

8.3 Allez-vous effectuer un audit annuel de l’application et fournir des commentaires pour améliorer l’utilisation et l’adoption du système, afin de réaliser un retour sur investissement plus rapide ?

Oui, un audit annuel de l’ensemble de la solution (de bout en bout) est une procédure standard. Cela dit, les Supply Chain Scientists (SCS) de Lokad auditeront généralement l’ensemble de la solution plusieurs fois tout au long de l’année. L’audit annuel aboutit généralement à une présentation détaillée de la feuille de route pour la direction du client. Cela s’inscrit dans notre approche d’amélioration continue pour chaque initiative.

En ce qui concerne l’utilisation, dans la pratique, les SCS mettent en place de manière proactive des outils dédiés dès le début pour surveiller l’utilisation, l’adoption et la conformité aux décisions de la supply chain générées par Lokad. Bien qu’un audit annuel offre une excellente occasion de procéder aux ajustements nécessaires, nos SCS sont très proactifs en ce qui concerne l’adoption des recommandations de la supply chain de Lokad. Cette question sera discutée lors de nos sessions de travail hebdomadaires, car l’adoption des recommandations de Lokad est le principal moteur d’une augmentation du retour sur investissement dans une initiative de supply chain quantitative.

8.4 Pouvez-vous garantir que l’équipe de support produit dédiée, basée sur site au siège de l’entreprise cliente, continuera à prendre en charge le produit pendant au moins 6 mois après le lancement ?

Oui. L’équipe de Supply Chain Scientists (SCS) de Lokad s’occupe de cette tâche. Nos SCS sont amplement formés pour améliorer en continu l’initiative et fournir un soutien continu au client. La présence continue sur site des SCS sera négociée et clarifiée dans l’accord contractuel avec le client, si c’est quelque chose que le client souhaite poursuivre.

À ce sujet, Lokad recommande vivement de maintenir un engagement actif et continu envers l’amélioration de la solution, en particulier du côté du client. La suppression progressive des efforts d’amélioration continue affaiblira, selon notre expérience, la force de l’initiative. Toute modification du côté du client, y compris de légères modifications du paysage applicatif ou des contraintes, peut avoir un impact sur la qualité des décisions générées par Lokad. Par conséquent, une vigilance active et une amélioration continue sont conseillées.

Voir aussi Mise en œuvre et gestion de projet 1.7.

9. Gestion des incidents et des défauts

9.1 Pouvez-vous garantir que tous les défauts et demandes de modification indispensables (éléments critiques et prioritaires) sont pris en charge en priorité et livrés, afin d’éviter tout retard dans les délais de mise en service de l’entreprise cliente ?

Oui. Les Supply Chain Scientists (SCS) de Lokad sont responsables de ce processus. Notre plateforme est conçue de manière à leur permettre de traiter les défauts et les demandes de modification de manière rapide et autonome.

La plateforme de Lokad est programmable, ce qui est rendu possible grâce à Envision - notre langage de programmation spécifique au domaine dédié à l’optimisation prédictive des chaînes d’approvisionnement. Cette programmabilité signifie que les SCS peuvent rapidement apporter des corrections et mettre en œuvre les modifications demandées, avec un niveau de précision rarement trouvé dans les logiciels d’entreprise.

Au-delà de la technologie, les SCS de Lokad sont formés pour remplir un certain nombre de rôles clés, ce qui réduit naturellement le nombre de personnes nécessaires pour traiter les défauts et les demandes de modification. Ces rôles comprennent l’expert en chaîne d’approvisionnement, l’analyste commercial, le data scientist, l’ingénieur data et l’intégrateur système. Ils sont donc bien formés pour apporter des corrections et des mises à jour tout en gardant à l’esprit les priorités principales du client.

Voir aussi Personnalisation et fonctionnalités système 6.2.

9.2 Pouvez-vous mettre en place un mécanisme de suivi des défauts pour garantir la résolution en temps voulu de tous les défauts et problèmes d’utilisabilité ?

Oui, la plateforme Lokad est dotée de son propre système de gestion des tâches / tickets / problèmes. Ces fonctionnalités nous permettent de suivre précisément la résolution en temps voulu des problèmes. Ces résolutions sont prises en charge par les équipes de Supply Chain Scientists (SCS) employées par Lokad.

Cependant, il est important de ne pas confondre “défauts” et “problèmes d’utilisabilité”. Par exemple, une prévision de la demande inexacte est un “défaut”. Cela a un impact négatif sur la chaîne d’approvisionnement. Cependant, en fonction des conditions du marché dans lesquelles l’entreprise cliente opère, ce “défaut” peut ne jamais être corrigé, seulement atténué. En ce qui concerne l’optimisation prédictive des chaînes d’approvisionnement, les solutions sont toujours des compromis, résoudre un défaut en créant un autre défaut (espérons-le plus petit).

En revanche, les problèmes d’utilisabilité sont généralement faciles à résoudre. Ainsi, pour cette catégorie de problèmes, nous sommes prêts et engagés à assurer une résolution en temps voulu, car résoudre le problème ne crée généralement aucun autre problème.

9.3 Pouvez-vous garantir que les défauts rencontrés lors des tests de versions (avant la production) seront pris en charge et corrigés en temps voulu, afin de ne pas affecter les délais de mise en service de la version pour l’entreprise cliente ?

Oui. Si les défauts identifiés concernent le code spécifique au client (écrit en Envision), alors les défauts seront corrigés par les Supply Chain Scientists (SCS) de Lokad. Si les défauts identifiés concernent la plateforme de Lokad, alors les défauts seront corrigés par les équipes d’ingénierie logicielle de Lokad.

Dans les deux cas, le processus de mise en service de Lokad implique des tests approfondis afin de s’assurer que les défauts sont identifiés et corrigés avant la mise en service.

9.4 Comment allez-vous traiter les incidents qui peuvent être signalés par l’entreprise cliente par l’un des canaux suivants : téléphone, e-mail, messagerie de bureau et/ou saisie directe dans l’outil de gestion des incidents ?

Les Supply Chain Scientists (SCS) traitent tous les rapports d’incident - quelle que soit leur source - avec le plus grand sérieux. L’accord contractuel entre Lokad et l’entreprise cliente précisera combien de SCS seront affectés au projet, ainsi que le nombre d’heures par semaine pendant lesquelles le client peut s’attendre à bénéficier d’un support direct.

La résolution d’un incident typique commence par la création d’une nouvelle entrée dans le gestionnaire de tâches/tickets/problèmes. Cela garantit une traçabilité de l’incident.

Ensuite, le SCS diagnostiquera le problème. Si le problème nécessite une correction du côté de Lokad, le SCS mobilisera immédiatement les ressources nécessaires pour résoudre le problème - généralement le SCS lui-même.

Enfin, une fois que le problème est résolu, le SCS évaluera la véritable cause profonde du problème signalé, même si le rapport a finalement été diagnostiqué comme un non-problème. Habituellement, il y a un problème sous-jacent quelque part qui doit être résolu. En abordant la cause profonde, Lokad élimine de manière proactive des problèmes similaires à l’avenir.

9.5 Si un défaut est signalé en dehors de l’outil de gestion des incidents - par un autre canal tel que l’e-mail - allez-vous enregistrer le défaut dans l’outil dès qu’il est signalé pour un suivi et une conformité appropriés ?

Oui. Il est courant de créer une entrée correspondante au sein de la plateforme Lokad lorsque nous recevons un rapport par un canal autre que le gestionnaire de tâches/tickets/problèmes. Cette pratique facilite un suivi complet et une conformité.