FAQ: Gestion du Changement

Une initiative avec Lokad vise à optimiser la chaîne d’approvisionnement du client avec une prise de décision automatisée et supérieure - remplaçant généralement les tâches quotidiennes fastidieuses telles que les commandes d’achat et les choix d’allocation de stocks. Cette page aborde les questions et 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 chaîne d’approvisionnement et/ou de planification.
Dernière modification : 19 décembre 2023

Aperçu de la Gestion du Changement

La Supply Chain Quantitative (QSC), telle que pionnière et préconisée par Lokad, diverge significativement de la perspective traditionnelle. Les différences sont à la fois essentielles et les raisons fondamentales pour lesquelles Lokad peut apporter des améliorations si drastiques à la chaîne d’approvisionnement. Cela dit, la gestion du changement associée à la mise en œuvre d’une initiative QSC est plus facile que nos clients ne le 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 chaîne d’approvisionnement fastidieuses 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 des outils alternatifs (systèmes hérités, feuilles de calcul, et souvent un peu des deux).

Une initiative QSC est dirigée par les Supply Chain Scientists de Lokad. Ces experts consolident de nombreux rôles qui seraient généralement tenus par plusieurs personnes dans des initiatives similaires avec d’autres fournisseurs de logiciels. Un Supply Chain Scientist fonctionne en tant qu’intégrateur système, ingénieur de données, analyste commercial, data scientist, expert en chaîne d’approvisionnement 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 pour que les clients adoptent l’approche quantitative de la chaîne d’approvisionnement 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 en matière de chaîne d’approvisionnement, et des économies de productivité substantielles grâce à des décisions de chaîne d’approvisionnement (largement) automatisées.

En termes de gestion du changement, les économies de la chaîne d’approvisionnement 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 à l’entreprise cliente que le processus hérité.

En bref, avant Lokad, les activités des praticiens de la chaîne d’approvisionnement 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 stocks, 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 qualité de service, identifier ce que les fournisseurs perçoivent comme un obstacle à la baisse des 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 SCS.

Pour les cadres de la chaîne d’approvisionnement, le plus grand changement est l’élimination (dans une large mesure) des luttes constantes. La solution de Lokad fournit des décisions automatisées conçues pour traiter les cas limites 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 chaîne d’approvisionnement pour élaborer des objectifs et des projets de chaîne d’approvisionnement, plutôt que de gérer minutieusement les conséquences continues de décisions sous-optimales.

Foire aux questions (FAQ)

1. Implémentation de projet et gestion

1.1 Offrez-vous des services de gestion de projet d’implémentation ?

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

Au-delà de cela, ces experts restent engagés dans le succès à long terme de l’initiative au-delà de la mise en œuvre initiale, en fournissant un soutien continu à mesure que l’initiative passe à sa phase de « 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 d’implémentation et les étapes ou phases incluses dans ce calendrier ? Quels sont les objectifs de chaque phase (du lancement du projet d’implémentation à la mise en service) ?

De bout en bout, l’implémentation 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 chaîne d’approvisionnement 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 qu’un effet très visible) de l’intention réelle : améliorer la performance de la chaîne d’approvisionnement. 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.

Détail 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 consiste à mettre en place le 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 d’établir la “sémantique” des données et de rendre le processus de mise en pipeline lui-même (quasiment) parfaitement fiable. Un pipeline de données, par opposition à une extraction de données ponctuelle, est fondamental pour maintenir les recommandations de la chaîne d’approvisionnement générées par Lokad pertinentes par rapport aux préoccupations commerciales actuelles du client.

• La deuxième sous-phase consiste à concevoir la ou les recettes numériques uniques du client - les morceaux de logique logicielle qui pilotent les décisions de la chaîne d’approvisionnement. L’objectif est d’obtenir des recettes cohérentes, fiables et pragmatiques. 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 non-sens, et les moteurs économiques pilotant 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 hérité. Comme la recette est automatisée, les frais généraux organisationnels sont faibles. Chaque jour, les praticiens de la chaîne d’approvisionnement peuvent comparer les décisions et voir comment les tendances (par exemple, la saisonnalité) se déroulent. Après plusieurs semaines de double run, la confiance est acquise pour procéder 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 hérité. Cette prise de contrôle peut également être progressive, en fonction de la capacité du client à superviser le changement nécessaire en matière de gestion.

Voir aperçu du calendrier pour un détail plus approfondi de chaque étape impliquée dans le 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 regroupés dans un Manuel de Procédure Conjoint (JPM) unique pour l’initiative. Les Supply Chain Scientists (SCSs) sont chargés d’initier et de maintenir le JPM pour 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 à des publics moins techniques et/ou non spécialisés. Le JPM capture l’essence de l’intention derrière l’initiative, et consolide les idées fondamentales au fur et à mesure de l’avancement de l’initiative elle-même.

Lokad estime que de nombreuses (si ce n’est la plupart) des 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). Ces 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 une tendance sévère à privilégier la quantité à la qualité lorsqu’il s’agit de documenter le projet.

En revanche, les JPM de Lokad sont conçus pour ê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 directives détaillées sur ce qui est censé être trouvé dans un JPM, il revient finalement aux SCSs de prendre des décisions judicieuses sur ce qui nécessite le plus d’attention et d’efforts compte tenu des spécificités de l’initiative.

Voir 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 maintenir et de baseliner le 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 de l’initiative elle-même.

Il arrive parfois qu’il y ait significativement plus d’employés impliqués du côté du client que du côté de Lokad, donc pour améliorer la productivité des SCSs chargés du compte, bon nombre de nos clients désignent un point de contact unique pour l’initiative. Cette personne - ou petite équipe - est chargée de transmettre les informations pertinentes à - et de solliciter les retours pertinents de - toutes les parties impliquées du côté du client dans le projet.

Pour une initiative particulièrement complexe, Lokad met en place un comité de pilotage dédié composé de membres clés à la fois de Lokad et de l’entreprise cliente. Bien que cette réunion serve de mécanisme pour obtenir une approbation formelle, la plupart du travail substantiel se fait en dehors du comité lui-même. Les SCSs interagissent généralement quotidiennement avec diverses équipes du côté du client. Ces équipes sont continuellement informées de toute déviation par rapport au plan, et veillent à ce que toute l’initiative reste sur la bonne voie. Ces interactions quotidiennes sont une manière beaucoup plus efficace de discuter et de surmonter les problèmes techniques au fur et à mesure qu’ils surviennent, 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, en tant que tel, agit comme un organe de supervision plutôt que comme un groupe de réflexion pour l’initiative.

Note : Les initiatives quantitatives de la supply chain 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 au cours de 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 communication de Lokad est la capacité de relayer rapidement et efficacement ces déviations positives au client au fur et à mesure de leur apparition, augmentant ainsi significativement l’impact et l’agilité de l’initiative.

1.5 Allez-vous documenter le plan de communication, qui comprend des réunions debout 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 debout quotidiennes lorsqu’elle est sur site au siège de l’entreprise cliente. Cependant, nos SCSs opèrent généralement dans les bureaux de Lokad.

Nous consolidons toute la documentation de l’initiative dans un Manuel de Procédures Conjointes (JPM) qui sert efficacement de guide complet pour l’ensemble du projet. Le JPM inclut 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 censé gérer toute question ou préoccupation concernant l’initiative. Ainsi, en ce qui concerne l’escalade, la résolution d’un problème préoccupant est généralement escaladée d’un Junior SCS à un Senior. Cela s’est avéré historiquement suffisant, avec très peu de situations nécessitant une escalade supplémentaire.

Lokad considère tous les problèmes - aussi mineurs soient-ils en apparence - 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 privilégie de mettre des personnes très capables 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 qui consiste à s’appuyer sur du 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 validé 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 accepté avec chaque client - selon les 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, bien que Lokad ne nécessite pas un engagement à long terme dès le premier jour, cette question est donc de moindre importance - surtout en comparaison avec nos concurrents.

Il convient de noter que nous n’avons jamais observé une supply chain se comporter de manière médiocre 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 que l’on trouve dans les supply chains modernes - présents même dans des entreprises qui semblent par ailleurs avoir des supply chains performantes.

1.7 Allez-vous déployer un chef de projet dédié de Lokad pour être basé au siège social de l’entreprise cliente, accompagné d’experts en la matière, 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 stationnement d’employés sur site au siège social de l’entreprise cliente, cela augmente naturellement le coût de l’initiative. La plupart de nos initiatives sont mené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 de stationner en permanence des employés de Lokad au bureau du client. Il convient de noter que, même si Lokad accepte de stationner une équipe permanente au siège social de l’entreprise cliente, les employés seront remplacés au fil du temps.

Ces pratiques bénéficient à tous, 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 de perfectionner les anciennes, quel que soit leur expérience ou leur ancienneté. Alors que nous observons que de nombreux fournisseurs d’entreprise permettent à leurs employés d’opérer pendant des mois, voire des années, sur des sites clients distants, 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), ainsi qu’à 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 faible effectif.

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

Pour une initiative typique chez Lokad, nous recommandons que l’entreprise cliente désigne un praticien expérimenté de la supply chain comme coordinateur de l’initiative, et qu’elle nomme également 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. En parallèle, les SCSs de Lokad travaillent avec les recettes numériques visant à produire les décisions de la supply chain qui les intéressent.

Nous recommandons une réunion hebdomadaire pour examiner les progrès 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 de 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 par un fournisseur, cette configuration technique nécessite moins de 4 semaines de travail pour un seul contributeur - et parfois beaucoup moins lorsque un 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.

L’avis du superviseur est important à la fois pour aligner Lokad avec la stratégie de haut niveau 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 au manque de qualité de service. 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 ce qui précède dépend des besoins spécifiques de l’initiative. Nous sommes ouverts à d’autres approches organisationnelles si elles conviennent mieux au contexte spécifique et aux objectifs 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, en particulier 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 humaines de l’entreprise cliente au cours des 6 premiers mois - alias la 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 inversement, elle sera augmentée si le pipeline de données doit gérer plusieurs systèmes métier (par exemple, 1 ERP par pays). Une fois le pipeline de données opérationnel, sa maintenance ne devrait pas nécessiter plus que quelques heures par mois 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 donner un retour 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. La revue 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 désormais la plupart de son temps à préparer le déploiement adéquat 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 substantiel. Il est une erreur d’aborder la résolution de tels défis avec une mentalité de configuration et d’oubli, 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 à re-former tous les praticiens de la supply chain du client avec un nouveau processus pour maintenir les rouages de la supply chain en mouvement - l’automatisation elle-même est conçue pour s’occuper de cela. 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 le lancement du projet.

Cette approche rationalisée contraste fortement avec les “forces de travail” importantes - et coûteuses - souvent nécessaires par les fournisseurs de logiciels d’entreprise pour être opérationnels.

2.3 Pouvez-vous garantir que des ressources humaines et des ressources en connaissances produit (KP) suffisantes sont disponibles sur site au siège social 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 aussi Mise en œuvre et gestion de projet 1.7.

Voir aussi Gestion des ressources et exigences 2.2.

2.4 Organisez-vous des sessions de revue 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 mené à bien à travers des 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’ en cours d’investigation, ce qui n’est pas toujours facilité par la simple énumération des ’exigences’. Par exemple, si un client mentionne qu’il a besoin d’un traitement spécial pour les ‘mouvements lents’, nous comprenons que le faible volume est une préoccupation à prendre en compte. Cependant, traiter ces SKUs de manière spéciale 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 ‘mouvements lents’. En fait, après avoir examiné les points de douleur de la supply chain du client, il se peut que les ‘mouvements lents’ soient des SKUs qui ont été mal tarifés, regroupés et/ou alloués. Une fois que le problème (les mouvements lents) est mieux compris, cela modifie entièrement la stratégie d’intervention - rendant 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 calendriers 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 des 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 censée être soutenue par des scripts, écrits en Envision, notre DSL (langage de programmation spécifique au domaine) dédié à l’optimisation prédictive des supply chains. En conséquence, 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 commerciaux de l’entreprise cliente.

Contrairement à la plupart des logiciels d’entreprise, la programmabilité est une fonctionnalité essentielle pour Lokad. Les scripts Envision susmentionnés ne sont pas une ‘personnalisation’ de la solution Lokad au sens habituel. La présence de ces scripts n’est pas non plus un écart par rapport à la branche de développement principale de la solution Lokad. Au contraire, la grande programmabilité de Lokad est le chemin d’implémentation prévu.

En conséquence, nos estimations (coûts, calendrier, etc.) sont accompagnées d’un degré de certitude extrêmement élevé. La grande majorité des projets restent dans les estimations/budget initial (dans tous les sens). Cela contraste avec plusieurs des concurrents de Lokad, pour lesquels des retards coûteux et des reformulations des termes sont courants.

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

2.6 Allez-vous mettre en place et maintenir une stratégie de rétention raisonnable conçue pour conserver le personnel clé exécutant les services pour 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 les employés pendant 3,5 ans, ce qui est presque le double de la durée d’emploi par rapport à des cohortes similaires (ingénieurs talentueux en informatique, ou domaines adjacents à l’informatique) 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. En conséquence, la plupart des initiatives de Lokad bénéficient d’avoir les mêmes Supply Chain Scientists (SCSs) d’une année à 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 de 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 fournisseurs 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 jeu. Tout d’abord, chaque initiative de Lokad est accompagnée d’un Manuel de Procédures Conjointes (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 a - à tout moment - à la fois un SCS principal et un SCS secondaire. Même si le SCS secondaire ne contribue pas directement à l’initiative, Lokad alloue suffisamment de temps pour s’assurer que cette personne est prête à prendre en charge l’initiative si jamais le besoin se présente. Cette pratique atténue largement les complications liées aux congés/turnover non planifiés.

3. Rôles, Responsabilités & 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 bien plus élevé que ce qui est généralement attendu d’un fournisseur de logiciels d’entreprise. Les préoccupations de la supply chain ne sont pas également importantes pour toutes les entreprises, donc 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 qualifient leur relation avec Lokad de “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 (SCSs) - sont intimement familières avec 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 revue, impactant positivement à la fois les clients et 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 l’aspect le plus banal et répétitif 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 redirigées vers de meilleures utilisations.

3.2 Quels rôles et responsabilités prévoyez-vous d’avoir 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’implication de la haute direction dans l’initiative de supply chain quantitative. Sans être censée plonger dans les détails techniques, cette personne doit comprendre et communiquer les insights 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 des retours, 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 de l’entreprise existants, tout en gardant l’esprit ouvert à d’éventuelles révisions 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 garantit leur accessibilité et leur fiabilité. Chargée d’extraire des ensembles de données complets (comme les historiques des ventes et des 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 Scientist de la Supply Chain : Ce rôle fusionne les insights 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 Scientist de la Supply Chain collabore étroitement avec le Coordinateur pour clarifier toute ambiguïté des données. Ils formalisent ensuite les stratégies en décisions actionnables, telles que les quantités de réapprovisionnement, et mettent en place des tableaux de bord et des KPI 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 complet (Responsable / Accountable / Consulté / Informé) pour la phase de mise en œuvre et pour la phase de production ?

Oui. Ces informations peuvent être présentées de manière explicite sous forme de tableau RACI si cela est jugé important par l’entreprise cliente.

Plus important encore, les Scientists de la Supply Chain (SCSs) internalisent ce type de matrice afin de prendre des décisions adéquates et rapides à mesure que l’initiative progresse. 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. De manière critique, toute cette analyse doit être effectuée rapidement pour préserver l’élan de l’initiative.

À cette fin, les SCSs de Lokad sont désignés pour mener l’initiative et prendre en charge la qualité des résultats générés par la recette numérique de Lokad.

Ainsi, 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 qu’un système ou un processus élaboré de délégation de 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 s’assurer que les intervenants pertinents de l’entreprise cliente sont consultés et pleinement informés de l’initiative.

3.4 Allez-vous documenter les rôles et responsabilités en utilisant une matrice RACI (Responsabilité, Accountability, 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 impliquées ?

Oui. Tous ces éléments (et plus encore) sont rassemblés et documentés dans le Manuel de Procédures Conjointes (JPM). Le JPM est produit par les Scientists de la Supply Chain de Lokad (avec des insights collectés 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 assignés à l’entreprise cliente. Le fait de produire ce document avec leurs propres mots démontre que les SCSs ont pris un temps considérable pour enquêter, diagnostiquer et analyser la supply chain du client et la solution globale (sans simplement régurgiter 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ésaccords, ils 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 Executive de la Supply Chain pour superviser l’initiative. Une de leurs contributions clés est d’agir en tant qu’intermédiaire lorsque de tels cas se présentent.

3.5 Assurerez-vous que le groupe de travail du projet et les groupes de pilotage sont formés avec des ressources nommées des parties prenantes du projet? Assurerez-vous que le rythme opérationnel est convenu par toutes les parties impliquées?

Oui. En principe général, nous suivons tout processus jugé nécessaire par - et formellement convenu avec - l’entreprise cliente. Les éléments convenus (et tout changement apporté à mesure que l’initiative progresse) sont documentés dans le Manuel de Procédure Conjoint (JPM), qui comprend des détails concernant le groupe de travail du projet et les groupes de pilotage. Grâce aux Supply Chain Scientists (SCSs) de Lokad, nous disposons des ressources nécessaires pour installer et surveiller ces processus.

Anecdotiquement, l’une des contributions les plus appréciées de Lokad est notre capacité à simplifier les processus - qu’ils soient de nature supply chain ou bureaucratique. Au fil du temps, nous travaillons activement à supprimer les couches bureaucratiques inutiles des supply chains de nos clients.

4. Transition du Système & Mise en Service

4.1 Quelle est la durée de la transition du lancement à la mise en service?

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

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

De manière intéressante, 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 d’intégration 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.

De tels retards ont peu à voir avec la configuration technique de Lokad elle-même. Dans l’ensemble, le calendrier suggéré sert non seulement à des fins techniques (automatisation de l’extraction de données, test de recettes numériques, etc.), mais il permet également aux Supply Chain Scientists (SCSs) de Lokad de devenir pleinement compétents avec tous les spécificités de l’entreprise cliente, et aux équipes supply chain de “digérer” l’approche de Lokad - ce qui représente généralement un changement par rapport au processus hérité du client.

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 termes contractuels spécifiques avec l’entreprise cliente, bien que l’on doive noter que les coûts de déplacement peuvent affecter les frais facturés par Lokad. Ainsi, l’inclusion de visites sur site est finalement 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 maintenir l’initiative aussi efficace 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 (revenu annuel inférieur à 100M USD) 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 gérer efficacement le changement, nous sommes à l’aise avec des visites chaque mois - et éventuellement plus fréquemment si nécessaire. Pour les grandes entreprises (revenu annuel supérieur à 1 milliard USD), nous recommandons au moins une visite/atelier trimestriel sur site. Cette approche aide à développer un alignement à l’échelle de l’entreprise, en particulier 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 simplement une question de coûts de déplacement associés et de logistique.

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

Pour une initiative de supply chain quantitative, la majorité des réunions devraient ê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 des 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 des 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 les réunions à distance décontractées, pratiques et aussi fréquentes que nécessaire.

4.4 Aidez-vous l’entreprise cliente à effectuer un contrôle qualité de l’environnement de production pour évaluer la préparation au lancement, y compris la mise en place des interfaces?

Oui. En fait, Lokad va au-delà de simplement aider l’entreprise cliente dans son évaluation de la préparation au lancement. L’une des principales responsabilités des Supply Chain Scientists (SCSs) de Lokad est de prendre en charge la solution de bout en bout livrée à l’entreprise cliente. 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 prend 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.

En raison de leur nature sujette 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é d’entrée (lorsque Lokad reçoit des données historiques de l’entreprise cliente) et du côté de 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 au lancement.

4.5 Préparez-vous le document de stratégie de transition et de migration de production pour gérer la transition sans heurts des opérations commerciales (de l’application commerciale existante à la nouvelle application commerciale) 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 (SCSs) de Lokad, garantit que les praticiens de la supply chain et les cadres de la supply chain ont accès à des documents bien rédigés qui expliquent adéquatement le processus en termes compréhensibles. Les SCSs 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 garantir une transition en douceur du processus hérité à la nouvelle solution. La “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, garantissant que les recettes numériques mises en œuvre par les SCSs de Lokad fonctionnent de manière satisfaisante dans des conditions de production exactes, sur l’ensemble de la portée, pendant des semaines avant le lancement effectif, où les décisions de Lokad remplacent le processus hérité.

Il convient de noter qu’une telle 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 surcoûts associés à une double exécution sont importants. Par conséquent, la double exécution est, au mieux, effectuée sur une petite portée qui ne reflète pas véritablement les conditions de production. Par conséquent, 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 évitables avec une double exécution sur l’ensemble de la portée.

4.6 Fournissez-vous la portée, les délais et les critères de succès pour que le pilote soit examiné et validé par l’entreprise cliente?

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, réapprovisionnement des stocks ou 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 calendrier 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 termes de critères de succès, 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 le pilote a été un succès si le client pense le contraire.

Voir aussi Implémentation de Projet & Gestion 1.2.

Veuillez consulter Évaluation du Succès d’une Initiative de Supply Chain Quantitative pour en savoir plus sur ce point nuancé.

4.7 Organiserez-vous la conduite des 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é du processus/système, et d) l’adéquation globale?

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

L’équipe de Supply Chain Scientists (SCSs) de Lokad est responsable de tout ce qui précède. Dans 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 & des Risques

5.1 Quel soutien pouvez-vous offrir à l’entreprise cliente pour 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 (SCSs) de Lokad, tous formés pour gérer les exigences techniques et non techniques d’une initiative d’optimisation de la supply chain. Les SCSs aident dans le processus de gestion du changement de nombreuses manières, notamment:

• Proposer des améliorations aux processus existants pour les praticiens de la supply chain employés par l’entreprise cliente.

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

• Aider 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 significatif en temps pour un SCS. Bien que chaque SCS ait des compétences et une expérience uniques pour aider le leadership de la supply chain dans la gestion du changement, cette tâche est en concurrence avec toutes leurs autres tâches.

Ainsi, les termes contractuels négociés entre Lokad et chaque client spécifient la quantité de ressources - c’est-à-dire la taille de l’équipe de SCSs - qui sera disponible pour soutenir l’initiative. Nos propositions commerciales prévoient généralement que les SCSs fourniront un certain soutien à la gestion du changement. Cependant, nos propositions ne reflètent généralement pas de soutien “à grande échelle” pour 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 devrait 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 d’une journée donnée 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 est d’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 revues. En fait, 0% d’absurdité dans les chiffres générés par Lokad est le critère principal pour un déploiement en production. 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 adoptants” parmi les praticiens de la supply chain. Ce sont généralement des personnes qui parviennent rapidement à se séparer du processus hérité non créateur de valeur - par exemple, la révision manuelle des chiffres - afin de se concentrer sur l’amélioration continue de la supply chain à travers 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 est d’amener la majorité des praticiens de la supply chain à regarder vers l’extérieur (clients et fournisseurs) plutôt que vers l’intérieur. En fin de compte, la supply chain doit offrir un alignement qui va au-delà des frontières de l’entreprise cliente. Cela élargit le pool d’informations collectées et contribue à affiner davantage les recettes numériques.

La nouvelle organisation se rapproche beaucoup d’une entreprise de logiciels. Il y a peu de tâches répétitives de la supply chain qui sont gérées manuellement - car les tâches répétitives sont désormais automatisées. Il y a également 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 (Livraison orientée produit pour la 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 propre à Lokad.

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 impliquées dans la génération des décisions de la supply chain est l’arrangement souhaité.

Cependant, si explicitement demandé par le client, Lokad est capable d’introduire un “flux de travail” qui reflète l’ancien. Il faut comprendre que cela est purement pour faciliter la gestion du changement, et n’est en aucun cas une exigence pour le succès de la recette numérique. Au fur et à mesure que les employés du client deviennent plus familiers - et développent une plus grande confiance - dans les décisions générées par Lokad, 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 programmatique 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 restent intactes.

5.4 Pouvez-vous maintenir un registre des problèmes et des risques qui inclut un plan d’atténuation, des tâches, des responsabilités, des échéances et des statuts (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 veillera-t-il à des résolutions rapides ou à la gestion des escalades si nécessaire ?

Oui. La plateforme de Lokad est livrée avec son propre gestionnaire interne des problèmes/tickets/tâches. Cette fonctionnalité offre toutes les capacité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 fournit une présentation complète et bien organisée de l’initiative avec tous les délais de haut niveau pertinents. Les Supply Chain Scientists (SCSs) 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 capacité de contacter facilement les SCS est quelque chose que nos clients citent régulièrement comme un grand avantage. Le client peut immédiatement interagir avec la personne dont le travail est de superviser la résolution satisfaisante de tout problème, plutôt que de devoir naviguer à travers plusieurs niveaux de bureaucratie pour - espérons-le - parler à quelqu’un capable de les aider.

En cas de problème nécessitant 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 toujours la résolution rapide du problème et agissent comme premier point de contact pour le client concerné.

5.5 Offrez-vous des services de consultation 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 consultation 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 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 juge prudent.

6. Personnalisation & Fonctionnalités du Système

6.1 Organisez-vous des sessions pour prioriser les exigences de personnalisation, en garantissant une compréhension des impacts commerciaux dus aux lacunes du produit et en parvenant à un accord mutuel sur la priorité de la publication des personnalisations?

Oui. Les Supply Chain Scientists (SCSs) de Lokad sont chargés de ce processus. En fait, Lokad se distingue sur deux fronts en ce qui concerne cette priorisation. 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 le calendrier en jeu.

Cela améliore grandement la qualité de la priorisation, car l’entreprise cliente bénéficie d’un expert capable de trouver un équilibre entre les avantages de tout changement de supply chain donné et les coûts associés à ce changement.

Deuxièmement, la ‘Supply Chain Quantitative’ - philosophie globale de Lokad - 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 débattre de ce qui devrait être priorisé. Au lieu de cela, Lokad rationalise ce processus en priorisant les 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 (SCSs) de Lokad sont chargés de ce processus. Alors qu’une étude initiale sera mené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 n’est pas seulement de générer des quantités de réapprovisionnement (fonctionnalité) mais de s’assurer que les quantités générées sont les plus rentables (performance).

Ainsi, les SCSs sont chargés d’identifier et de résoudre les ’lacunes de performance’, qui nécessitent parfois une fonctionnalité supplémentaire ou une réingénierie de la solution. Cela peut impliquer d’ajouter ou de supprimer des fonctionnalités pour optimiser les performances globales.

À ce titre, la plateforme de Lokad est programmatique. 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 (SCSs) 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, alors 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 spécification des exigences de personnalisation du produit sont examinés conjointement et approuvés par l’entreprise cliente?

Oui, ces documents seront fournis à - et ultérieurement approuvés par - l’entreprise cliente.

Veuillez noter que les choix de conception de la plateforme de Lokad éliminent largement le besoin de ‘personnalisation’ - du moins telle que ce terme est communément compris dans les cercles des logiciels d’entreprise. La plateforme de Lokad est programmatique, utilisant Envision - notre DSL (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’ au 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 à maintenir la solution dans la ligne 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 pose aucun problème de maintenabilité.

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

Oui. Les Supply Chain Scientists (SCSs) 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 SCSs peuvent être complétés par des ressources informatiques internes chez Lokad pour les aspects techniques très bas niveau, tels que le réseau ou les protocoles 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’ à travers des 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 s’engage à son tour à 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 pour les 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 changement et de gestion des versions?

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

Tout d’abord, les changements spécifiquement réalisés pour les clients sont mis en œuvre par les SCSs eux-mêmes. Ces changements se produisent fréquemment, souvent plusieurs fois par jour, en particulier pendant la phase de mise en service. Ces changements 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 DSL (langage de programmation spécifique au domaine) dédié à l’optimisation prédictive de la supply chain. Ces changements sont conçus pour être transparents pour les entreprises clientes. Si désiré, les détails sur 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 (UAT)

7.1 Aidez-vous l’entreprise cliente à mettre en place l’environnement de test UAT (User Acceptance Testing) avec des données spécifiques au contexte et des configurations système?

Oui. Les Supply Chain Scientists (SCSs) de Lokad sont responsables de ce processus. Lokad propose des innovations méthodologiques et techniques uniques pour soutenir cela.

En termes de méthodologie, nous privilégions la conception de listes prioritaires, où les éléments sont classés par retour sur investissement décroissant (ROI) pour l’entreprise. Cet aspect est crucial 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 toute 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 aussi Tests d’Acceptation Utilisateur 7.3.

7.2 Configurez-vous les environnements de test UAT (User Acceptance Testing) de pré-production, production et formation selon les processus ToBe définis?

Oui. Compte tenu de 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 DSL (langage de programmation spécifique au domaine) dédié à l’optimisation prédictive des chaînes d’approvisionnement.

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 partout où c’est 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 UAT.

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

7.3 Fournissez-vous des environnements distincts de test UAT (User Acceptance Testing), de migration des données, de pré-production, 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 toute 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, se fait sans doubler l’empreinte 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’a pas d’impact négatif sur 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 directe - est facile mais gaspilleur. Le clonage signifie que la quantité de ressources (humaines et matérielles) augmente de manière linéaire avec le nombre d’environnements - par exemple, trois environnements triplent les coûts initiaux. Pour toute chaîne d’approvisionnement de taille significative, cela se traduit par des coûts importants.

7.4 Garantissez-vous la résolution en temps voulu de tous les défauts pour garantir que les tests UAT (User Acceptance Testing) sont terminés dans les délais convenus mutuellement?

Oui, à condition que des définitions nuancées de “résolution” et “défaut” puissent être convenues. Dans l’ensemble, les Supply Chain Scientists (SCS) 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 la supply chain, il n’y a pas de solutions parfaites, seulement des compromis meilleurs ou pires. 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 lors de la manipulation 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 “mondains” au fur et à mesure qu’ils surviennent, 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 la 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 orientée des compromis de la supply chain.

7.5 Aidez-vous l’entreprise cliente à examiner les scénarios, cas de test et données de test des tests UAT (User Acceptance Testing)?

Oui. Les Supply Chain Scientists (SCS) de Lokad sont chargés 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, cas de test et données de test doivent être (presque) aussi grands que l’ensemble de production pour refléter une perspective de bout en bout de la supply chain. Cette exigence n’a rien à voir avec Lokad ; c’est simplement la nature de la supply chain.

7.6 Garantissez-vous un support sur site au siège de l’entreprise cliente pendant la phase de tests 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 quantitative de la supply chain avec Lokad présente 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 pic 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 et audit après la mise en œuvre

8.1 Pouvez-vous garantir que les observations des tests pilotes sont documentées, que des actions sont attribuées aux parties prenantes concernées des départements technique, informatique et des fournisseurs de l’entreprise cliente, et qu’elles sont également suivies jusqu’à leur clôture?

Oui. Les Supply Chain Scientists (SCSs) 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. Importamment, 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 éléments mineurs 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 garantir 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 (SCSs) 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éellement prises dans la supply chain. Cela est fait pour identifier les sources potentielles de divergence, telles que des bugs ou des problèmes dans les systèmes du client, qui pourraient affecter la mise en œuvre des recommandations de Lokad.

8.3 Effectuerez-vous un audit annuel de l’application et fournirez-vous des retours sur l’amélioration de l’utilisation et de l’adoption du système par les utilisateurs finaux, afin de réaliser un ROI (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 (SCSs) de Lokad auditent généralement l’ensemble de la solution plusieurs fois au cours de l’année. L’audit annuel conduit 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 SCSs 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 présente une excellente opportunité pour apporter les ajustements nécessaires, nos SCSs 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’augmentation du ROI dans une initiative quantitative de la supply chain.

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, continue de soutenir le produit pendant au moins 6 mois après le lancement?

Oui. L’équipe de Supply Chain Scientists (SCSs) de Lokad s’occupe de cette tâche. Nos SCSs sont amplement formés pour à la fois améliorer continuellement l’initiative et fournir un soutien continu au client. La présence continue sur site des SCSs 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 à l’amélioration de la solution, en particulier du côté du client. Mettre fin aux 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 modestes ajustements dans le paysage applicatif ou les contraintes, peut avoir un impact sur la qualité des décisions générées par Lokad, d’où la vigilance active et l’amélioration continue sont conseillées.

Voir aussi Implémentation de Projet & Gestion 1.7.

9. Gestion des Incidents & Défauts

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

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

La plateforme de Lokad est programmatique, ce qui est rendu possible grâce à Envision - notre DSL (langage de programmation spécifique au domaine) dédié à l’optimisation prédictive des supply chains. Cette programmabilité signifie que les SCSs peuvent rapidement apporter des correctifs et mettre en œuvre les changements demandés à l’initiative, et à un niveau de précision rarement trouvé dans les logiciels d’entreprise.

Au-delà de la technologie, les SCSs 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 changement. Ces rôles comprennent expert en supply chain, analyste commercial, data scientist, ingénieur data et intégrateur système. Ils sont donc bien formés pour apporter des correctifs et des mises à jour tout en gardant à l’esprit les principales priorités du client.

Voir aussi Personnalisation & Fonctionnalité Système 6.2.

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

Oui, la plateforme Lokad est livrée avec son propre système de gestion des tâches / tickets / problèmes. Ces capacité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 (SCSs) employées par Lokad.

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

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

9.3 Pouvez-vous garantir que les défauts rencontrés lors des tests des versions (avant la production) seront pris en charge et corrigés en temps voulu, de manière à ne pas affecter le calendrier 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 (SCSs) 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 via l’un des canaux suivants : téléphone, e-mail, communicateur de bureau et/ou saisie directe dans l’outil de gestion des incidents?

Les Supply Chain Scientists (SCSs) 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 SCSs 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 un SCS créant une nouvelle entrée dans le gestionnaire de tâches/tickets/problèmes. Cela garantit une traçabilité pour 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 le problème résolu, le SCS évaluera la véritable cause du problème signalé, même si le rapport a finalement été diagnostiqué comme non pertinent. En général, il y a un problème sous-jacent quelque part qui doit être traité. En s’attaquant à 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 - via un autre canal tel que l’e-mail - enregistrerez-vous le défaut dans l’outil dès qu’il sera signalé pour un suivi et une conformité appropriés?

Oui. Il est de pratique courante 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 approfondi et la conformité.