FAQ: Gestion du changement

Une initiative avec Lokad vise à optimiser la supply chain du client grâce à une prise de décision automatisée et supérieure - remplaçant typiquement des tâches quotidiennes banales telles que les bons de commande et les choix d’allocation de stocks. Cette page répond aux questions et préoccupations concernant le changement qu’apporte cette initiative, et comment le gérer efficacement. Les experts de Lokad restent, en tout temps, disponibles pour aider les clients à naviguer dans le processus.

Public visé: Les départements 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 (QSC), telle qu’initiée et promue par Lokad, diverge significativement de la perspective traditionnelle. Les différences sont à la fois essentielles et constituent la raison principale pour laquelle Lokad peut apporter d’aussi drastiques améliorations à la supply chain. Cela dit, la gestion du changement associée à la mise en œuvre d’une initiative QSC est plus simple que ce que nos clients imaginent habituellement.

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

Une initiative QSC est dirigée par les Supply Chain Scientists. Ces experts consolident de nombreux rôles qui seraient généralement assurés par plusieurs personnes dans des initiatives similaires avec d’autres éditeurs de logiciels. Un Supply Chain Scientist fonctionne comme un intégrateur de systèmes, ingénieur data, analyste business, data scientist, expert supply chain, et chef de projet (parmi d’autres rôles). Les Supply Chain Scientists (SCSs) fournissent tout le coaching, la formation, les conseils et le support nécessaires pour que les clients adoptent l’approche de la Supply Chain Quantitative de Lokad.

Le déploiement réussi de Lokad (en production) aboutit généralement à deux résultats notables : des économies substantielles grâce à de meilleures décisions supply chain, et des gains de productivité importants grâce à des décisions supply chain (pour la plupart) automatisées.

En matière de gestion du changement, les économies supply chain ne posent généralement aucun problème. L’entreprise pourrait en fin de compte décider de réinvestir le fonds de roulement libéré ailleurs, mais ce type de décision dépasse normalement le cadre de l’initiative Lokad. Toutefois, les gains de productivité considérables générés par Lokad sont généralement réinvestis dans d’autres tâches apportant bien plus de valeur ajoutée à l’entreprise cliente que le processus hérité.

En bref, avant Lokad, les activités des praticiens supply chain au sein de l’entreprise cliente étaient presque exclusivement orientées vers l’interne : produire une prévision, transformer la prévision en plan, ajuster les niveaux de stocks minimum/maximum sur les SKU, composer des bons de commande/de production/des mouvements de stocks, etc.

Une fois Lokad en production, la plupart des activités sont orientées vers l’externe : identifier ce que les clients perçoivent comme qualité de service, identifier ce que les fournisseurs considèrent comme un obstacle pour réduire davantage le prix, identifier ce que les transporteurs perçoivent comme les causes profondes de leur manque de fiabilité, etc.

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

Pour les cadres supply chain, le plus grand changement est la quasi-élimination de la gestion continue des urgences. La solution de Lokad fournit des décisions automatisées conçues pour traiter des cas limites gênants, réduisant ainsi considérablement le temps que les cadres doivent consacrer à analyser un comportement de marché erratique. Cela permet aux cadres supply chain de se concentrer sur la définition stratégique des objectifs et projets supply chain, plutôt que de microgérer les conséquences permanentes des décisions sous-optimales.

Questions fréquentes (FAQ)

1. Mise en œuvre et gestion de projet

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

Oui. Ces services sont fournis par les Supply Chain Scientists (SCSs) de Lokad. Ces experts non seulement gèrent la mise en œuvre, mais dirigent également l’initiative avec l’entreprise cliente. Cela inclut 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 accompagner l’adoption des pratiques et processus recommandés par Lokad au sein de l’entreprise cliente.

De plus, ces experts restent engagés dans la réussite à long terme de l’initiative, au-delà de la mise en œuvre initiale, en fournissant un support continu lorsque l’initiative passe en phase d’amélioration continue.

Voir les conférences de Lokad sur the Supply Chain Scientist et A day in the life of a 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 (à partir du lancement de la mise en œuvre du projet jusqu’au Go-Live) ?

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 en production la recette numérique de Lokad. À la fin de la phase d’intégration, les décisions supply chain d’intérêt (telles que définies en collaboration avec le client) devraient être robotisées. Cependant, l’automatisation n’est généralement qu’un effet secondaire (bien que très visible) de l’intention réelle : améliorer la performance de la supply chain. L’objectif de la phase ‘production’ est de raffiner, améliorer et réaligner en continu les recettes numériques, celles qui permettent l’automatisation dès le départ.

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 consiste à mettre en place le data pipeline. L’objectif est de créer un pipeline entièrement automatisé pour l’extraction des données du client vers Lokad. Les deux aspects les plus exigeants du data pipeline sont d’établir la ‘sémantique’ des données et de rendre le processus de pipelining (près de) parfaitement fiable. Un data pipeline, par opposition à une extraction de données ponctuelle, est fondamental pour maintenir la pertinence des recommandations supply chain que Lokad génère en fonction des préoccupations commerciales actuelles du client.

• La deuxième sous-phase consiste en la conception de la recette numérique unique du client - les morceaux de logique logicielle qui pilotent les décisions supply chain. L’objectif est d’obtenir des recettes cohérentes, fiables et pragmatiques. La rédaction des recettes numériques initiales est rapide, durant généralement pas plus d’une à deux semaines. 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 en charge du compte concerné. Cela élimine rapidement les cas limites gênants présents dans les premières versions.

• La troisième sous-phase est le dual run. La recette numérique ne produit plus d’absurdités, et les leviers économiques guidant l’optimisation ont été validés. Toutefois, la recette n’est pas encore de niveau de production. Pour aller de l’avant, un dual run est lancé. La recette numérique est exécutée en parallèle avec le processus hérité. Comme la recette est automatisée, la charge organisationnelle est faible. Chaque jour, les praticiens supply chain peuvent comparer les décisions et observer l’évolution de certains schémas (par exemple, la saisonnalité). Au terme de plusieurs semaines de dual 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 reprendre le processus hérité. Cette reprise peut également être progressive, en fonction de la capacité du client à superviser la gestion du changement nécessaire.

Voir aperçu du calendrier pour une répartition plus détaillée 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, ainsi que le plan de gestion et de communication des parties prenantes ?

Oui. Tous ces éléments, et bien d’autres, sont rassemblés dans un Manuel de Procédures Conjoint (JPM) unique pour l’initiative. Les Supply Chain Scientists (SCSs) sont chargés de lancer 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 destinés à être largement accessibles même aux publics moins techniques et/ou non spécialistes. Le JPM capture l’essence de l’intention derrière l’initiative, et consolide les insights fondamentaux au fur et à mesure qu’ils sont acquis au cours de l’initiative.

Selon Lokad, de nombreuses initiatives d’entreprise (sinon la majorité) sont entravées par la production de documents inutiles, qui sont, en pratique, impossibles à lire (c’est-à-dire, ils sont fastidieux ou d’une technicité inabordable). Ces documents ne servent qu’à cocher des cases inventées. De plus, de nombreux tiers (par exemple, intégrateurs, consultants, et même la bureaucratie interne) ont une forte tendance à privilégier la quantité au détriment de la qualité en ce qui concerne la documentation du 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 SCS eux-mêmes pour gérer l’initiative. Bien que nous disposions de directives détaillées sur ce que l’on doit trouver dans un JPM, il incombe en fin de compte aux SCS de faire des choix judicieux quant à ce qui nécessite le plus d’attention et d’efforts compte tenu des spécificités de l’initiative.

Voir la conférence Writing for Supply Chains pour plus d’informations sur l’éthique de documentation de Lokad.

1.4 Lokad est-il responsable de la maintenance et de l’établissement de la ligne de base du plan de gestion de projet, sous réserve de l’approbation du comité de pilotage du projet ? En cas de déviations par rapport au plan, les communiquerez-vous clairement avec des 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 beaucoup plus d’employés du côté client impliqués dans le projet que du côté de Lokad ; ainsi, pour améliorer la productivité des SCS chargés du compte, bon nombre de nos clients désignent un interlocuteur unique pour l’initiative. Cette personne - ou petite équipe - est chargée de relayer les informations pertinentes à - et de solliciter des retours pertinents de - toutes les parties impliquées du côté client du projet.

Pour une initiative particulièrement complexe, Lokad met en place un comité de pilotage dédié composé de membres clés tant de Lokad que de l’entreprise cliente. Bien que cette réunion serve de mécanisme pour obtenir une approbation formelle, la majeure partie du travail de fond se réalise en dehors même du comité. Les SCS interagissent généralement quotidiennement avec diverses équipes du côté client. Ces équipes sont continuellement informées de toute déviation par rapport au plan, et elles s’assurent que l’ensemble de l’initiative reste sur la bonne voie. Ces interactions quotidiennes constituent un moyen bien plus efficace de discuter et de résoudre les problèmes techniques dès leur apparition, plutôt que d’essayer de traiter de grandes volumétries de problèmes lors d’une session du 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 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 lors de la maintenance continue de l’initiative. Essentiellement, ce sont des opportunités trop intéressantes pour être manquées. Ainsi, un avantage clé de l’approche de communication de Lokad est la capacité de transmettre rapidement et efficacement ces déviations positives au client dès qu’elles surviennent, augmentant ainsi significativement l’impact et l’agilité de l’initiative.

1.5 Documenterez-vous le plan de communication, qui comprend des réunions quotidiennes, des comptes rendus hebdomadaires des groupes de travail et des sessions de revue, ainsi que des rapports mensuels du comité de pilotage et des sessions de revue ? Décrirez-vous les critères d’escalade et assurerez-vous 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 lorsqu’il est sur site au siège de l’entreprise cliente. Habituellement, cependant, nos SCS opèrent depuis les bureaux de Lokad.

Nous consolidons l’ensemble de la documentation de l’initiative dans un Manuel de Procédures Conjoint (JPM) qui sert effectivement 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 et les directives d’escalade, il convient de souligner qu’un Senior SCS de 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 portée de l’attention d’un Junior SCS à celle d’un Senior SCS. Cela s’est historiquement avéré suffisant, avec très peu de situations nécessitant une escalade supplémentaire.

Lokad considère tous les problèmes – même ceux d’apparence mineure – comme méritant une analyse approfondie. Bien que leurs effets soient faciles à résoudre, les problèmes mineurs peuvent poser des difficultés futures si leurs causes profondes ne sont pas comprises et traitées. Cela empêche qu’un problème mineur ne devienne récurrent. Ainsi, Lokad privilégie de placer en première ligne des personnes hautement compétentes, 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 repose sur du personnel de support non formé, traitant continuellement les mêmes problématiques – un schéma trop fréquemment adopté 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 Assurerez-vous que le plan de gestion de projet soit 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 convenu avec chaque client – conformément aux termes contractuels officiels. Ce principe reste applicable tout au long de l’initiative, du début à la fin. L’initiation du projet est certes importante, mais étant donné que Lokad ne requiert pas un engagement à long terme dès le premier jour, cette question est moins préoccupante – surtout comparée à nos concurrents.

Il convient de noter que nous n’avons jamais observé qu’une supply chain performe mal en raison d’un “manque” de bureaucratie et d’autres processus futiles. Au contraire, les bureaucraties inutiles et les processus insensés 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 disposer de supply chains performantes.

1.7 Déploierez-vous un chef de projet dédié de Lokad basé au siège de l’entreprise cliente, accompagné d’experts en la matière produit, d’analystes commerciaux, et d’experts en interfaces techniques?

Oui, si de telles dispositions font partie des termes contractuels convenus pour l’initiative. Bien que Lokad ne soit pas opposé à déployer des employés sur site au siège de l’entreprise cliente, cela augmente naturellement le coût de l’initiative. La majorité de nos initiatives sont menées à distance et soutenues par des visites mensuelles ou trimestrielles selon 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 dans les bureaux du client. Il convient de noter que, même si Lokad accepte de déployer une équipe permanente au siège de l’entreprise cliente, les employés seront amenés à tourner au fil du temps.

De telles pratiques profitent à tous les intervenants, puisque les Supply Chain Scientists (SCSs) de Lokad suivent un programme de formation continue. Ce programme est crucial pour s’assurer que nos employés continuent d’acquérir de nouvelles compétences ou de perfectionner les anciennes, quel que soit leur niveau d’expérience ou leur ancienneté. Bien que nous constations que de nombreux fournisseurs de logiciels 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 efficiente de programmes de formation de haute qualité.

En particulier, l’une des plus grandes forces des SCSs de Lokad est leur ensemble de compétences exceptionnellement diversifié et étendu. Chaque SCS est formé pour intervenir dans divers rôles, tels que : expert en la matière, analyste commercial, expert en interfaces techniques, data scientist, et consultant 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 l’ensemble de ces services.

En conséquence, les SCSs tendent à être beaucoup plus productifs (un nombre réduit de personnes signifie généralement moins de frictions de communication), et à offrir des niveaux de performance plus élevés. En réalité, les supply chains dépendent de manière critique d’une cohérence de bout en bout, ce qui est beaucoup plus facile à atteindre avec un faible nombre d’employés.

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 que l’entreprise cliente désigne un praticien expérimenté en supply chain comme coordinateur de l’initiative, et qu’elle nomme également un dirigeant supply chain comme superviseur de l’initiative. Le coordinateur sert de point de contact entre l’équipe des Supply Chain Scientists (SCSs) de Lokad et l’entreprise cliente. Le coordinateur transmettra d’abord les demandes d’information, puis relayera les demandes de retour d’information. Parallèlement, les SCSs de Lokad travaillent avec les recettes numériques visant à produire les décisions supply chain d’intérêt.

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

Certaines ressources informatiques doivent être allouées à la mise en place du pipeline de données dès le début de l’initiative. Lokad est plus efficace que la plupart de ses pairs à cet égard. Par exemple, nous extrayons automatiquement et directement les données transactionnelles du client, sans qu’aucun nettoyage ou préparation côté client ne soit requis. À moins que l’entreprise cliente ne soit confrontée à un verrouillage fournisseur, cette configuration technique nécessite moins de 4 semaines de travail pour un contributeur unique – et parfois beaucoup moins lorsqu’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, animée par les coordinateurs, aura généralement lieu pour soutenir ce processus. Par la suite, une fois que les SCSs auront élaboré 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 tant pour aligner Lokad avec la stratégie globale suivie par l’entreprise que pour éviter que l’initiative ne stagne en raison d’une indécision. Par exemple, Lokad peut proposer diverses options pour modéliser les coûts associés au manque de qualité de service. Nous pouvons expliquer les avantages et inconvénients de ces options en termes non techniques, mais en fin de compte, quelques choix stratégiques doivent être effectués.

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 et aux objectifs particuliers 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 de la supply chain réussie.

2. Gestion des Ressources & Exigences

2.1 Quelles sont les ressources humaines requises 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 ETP (équivalent temps plein) de ressources employées de l’entreprise cliente durant les 6 premiers mois – c’est-à-dire la phase d’onboarding. Une fois l’initiative en production, une estimation raisonnable est que le projet nécessitera encore au moins 0,25 ETP. Naturellement, ces estimations varient considérablement en fonction de la taille et de la complexité de l’entreprise cliente ainsi que de ses besoins spécifiques en supply chain.

En ce qui concerne les ressources requises à chaque étape d’une initiative “typique”, durant la phase d’onboarding nous avons :

• Mois 1 et 2 : La mise en place du pipeline de données nécessite 4 semaines d’effort à temps plein de la part d’un data officer, généralement employé par le service IT du client. Le data officer doit être bien familiarisé avec le paysage applicatif de l’entreprise cliente. Cette exigence peut être réduite si un data lake est déjà en place, mais inversement, elle sera accrue si le pipeline de données doit gérer plusieurs systèmes d’information (par exemple, 1 ERP par pays). Une fois le pipeline opérationnel, sa maintenance ne devrait pas requérir plus de quelques heures par mois de la part du data officer.

• Mois 3 et 4 : La conception de la recette numérique nécessite 2 ou 3 jours par semaine de la part 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 analyses de haut niveau, et par la suite pour fournir un retour d’information 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. Toutefois, ce poste ne requiert pas de compétences informatiques spécialisées ni de compétences spécifiques en data science. La revue hebdomadaire de l’initiative nécessite une demi-journée par semaine de la part d’un dirigeant supply chain.

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

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

2.2 Assurez-vous que suffisamment de ressources humaines sont prévues pour soutenir la transition du produit ?

Oui. En règle générale, Lokad recommande de conserver la même quantité de ressources (par exemple, les mêmes Supply Chain Scientists) lors de la transition de la phase d’onboarding vers 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 tels défis avec une approche “installer et oublier”, car toute solution technique finira inévitablement – et continuellement – par dériver vers l’irrélevance et l’obsolescence si elle n’est pas correctement surveillée et maintenue.

Il convient de noter que, étant donné que Lokad automatise les décisions supply chain, il n’est pas urgent de reformer l’ensemble des praticiens de la supply chain du client à un nouveau processus pour maintenir le fonctionnement de la supply chain – l’automatisation est conçue pour prendre en charge cela. En conséquence, il n’est pas rare que la refonte complète de l’organisation supply chain du client – déclenchée par l’initiative de Lokad – soit achevée quelques mois à peine après le lancement du projet.

Cette approche rationalisée contraste fortement avec les grandes – et coûteuses – “task forces” souvent requises par les fournisseurs de logiciels d’entreprise pour la mise en service.

2.3 Pouvez-vous garantir que suffisamment de ressources humaines et de produits de connaissance (KP) 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 & Exigences 2.2.

2.4 Organisez-vous des sessions de revue des exigences avec les responsables produits métier afin d’extraire et de 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é par le biais d’entretiens avec les parties prenantes concernées, y compris les responsables produits métier. 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 le simple fait de lister des “exigences”. Par exemple, si un client mentionne qu’il nécessite un traitement particulier des “slow movers”, nous comprenons que le faible volume est une préoccupation à traiter. Cependant, traiter ces SKU de manière spécifique 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 examiné les points de douleur de la supply chain du client, il se peut que les ‘slow movers’ soient des SKU mal tarifées, mal groupées et/ou mal attribuées. Une fois que le problème (les slow movers) est mieux compris, cela modifie entièrement la stratégie d’intervention – rendant souvent plus aisée sa résolution.

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 pour argent comptant 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 pour l’effort, les coûts et les plannings pour les fonctionnalités nécessitant une personnalisation, y compris les interfaces système, et les partagez-vous après l’atelier d’analyse fit-gap du 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 issues 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 de la supply chain. Par conséquent, Lokad est particulièrement bien placé pour fournir des fonctionnalités et des interfaces sur mesure, que ces interfaces soient destinées aux personnes ou aux systèmes d’information de l’entreprise cliente.

Contrairement à la plupart des logiciels d’entreprise, la programmabilité est une caractéristique essentielle de Lokad. Les scripts Envision susmentionnés ne constituent pas une “personnalisation” de la solution Lokad au sens habituel. La présence de ces scripts ne représente pas non plus un départ de la branche de développement principale de la solution Lokad. Au contraire, la riche programmabilité de Lokad est le chemin de mise en œuvre prévu.

En conséquence, nos estimations (coûts, planning, etc.) présentent un degré de certitude extrêmement élevé. La grande majorité des projets restent dans les limites des estimations/budgets initiaux (à tous égards). Cela contraste avec plusieurs concurrents de Lokad, pour qui des retards coûteux et des reformulations des termes sont monnaie courante.

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

2.6 Mettrez-vous en œuvre et maintiendrez-vous une stratégie de rétention raisonnable destinée à retenir les personnels clés accomplissant les services pour la durée de l’accord ? Maintiendrez-vous également des plans de succession actifs pour chacun des postes clés de Lokad ?

Oui. Nous conservons en moyenne nos employés pendant 3,5 ans, soit près du double de la durée d’emploi comparée aux cohortes similaires (ingénieurs talentueux dans l’IT, ou domaines adjacents à l’IT) sur des marchés comparables (Amérique du Nord et Europe de l’Ouest). Ce segment du marché de l’emploi est extrêmement compétitif et, bien qu’il y ait toujours une marge d’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 du fait d’avoir les mêmes Supply Chain Scientists (SCSs) d’une année à l’autre.

Cette rétention s’explique par des salaires compétitifs et par 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, notamment notre série de conférences sur la supply chain, peut être considéré comme un sous-produit de l’attention portée par Lokad à la formation de son propre personnel. Généralement, les éditeurs de logiciels d’entreprise qui ne disposent pas de supports de formation publics n’ont presque jamais de supports de formation privés non plus (même s’ils prétendent invariablement le contraire).

En ce qui concerne les plans de succession, nous avons deux pratiques importantes en place. Premièrement, chaque initiative de Lokad est accompagnée d’un Joint Procedure Manual (JPM). Le JPM est le document principal utilisé par un nouveau Supply Chain Scientist pour se familiariser rapidement avec toutes les informations pertinentes et les subtilités techniques de l’initiative. Deuxièmement, chaque initiative dispose – en tout temps – d’un Supply Chain Scientist principal et d’un Supply Chain Scientist secondaire. Même si le Supply Chain Scientist secondaire ne contribue pas directement à l’initiative, Lokad consacre suffisamment de temps pour s’assurer que cette personne soit prête à reprendre l’initiative si le besoin se fait sentir. Cette pratique atténue largement les complications liées aux absences imprévues ou au turnover.

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

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

Le niveau de coopération que nous entretenons avec nos clients varie, mais globalement, il est bien supérieur à celui que l’on attend habituellement d’un éditeur 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 celles pour lesquelles la supply chain constitue 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 qualifiés de ‘partenaires’. Cependant, après un an ou deux, la plupart de nos clients désignent leur relation avec Lokad comme un partenariat véritable – dans le vrai sens du terme. Ils ont des interlocuteurs familiers chez Lokad qui ont gagné leur confiance et, par conséquent, ces personnes – typiquement des Supply Chain Scientists (SCSs) – connaissent intimement leur entreprise. De plus, nos résultats sont fréquemment jugés suffisamment remarquables pour être présentés personnellement au PDG et/ou au conseil d’administration, même dans les grandes entreprises.

La collaboration continue avec Lokad permet à nos clients de repenser positivement l’ensemble de leur pratique de supply chain. En fin de compte, toute la chaîne est remaniée, impactant positivement à la fois les clients et les fournisseurs. Il convient de noter que Lokad n’a aucune intention de remplacer l’expertise stratégique essentielle qui existe au sein de l’entreprise cliente. Au contraire, Lokad souhaite automatiser les aspects les plus banals et répétitifs des processus de prise de décision de la supply chain. Cette approche libère ainsi des ressources importantes – et souvent rares – du client, ressources qui peuvent être réaffectées à de meilleures utilisations.

3.2 Quels rôles et responsabilités prévoyez-vous d’instaurer, tant au sein de l’entreprise cliente qu’à Lokad, pour maximiser l’efficacité de la solution ?

Il existe 4 rôles typiques impliqués dans les initiatives de la Supply Chain Quantitative de Lokad.

• The Supply Chain Leader: Ce rôle souligne l’importance de l’implication de la direction générale dans l’initiative de la Supply Chain Quantitative. Bien qu’il ne soit pas attendu qu’il s’attarde sur les détails techniques, cette personne doit comprendre et communiquer les perspectives stratégiques de l’initiative. Son rôle n’est pas de créer des indicateurs et des KPIs, mais plutôt de les évaluer de manière critique et de les remettre en question, garantissant ainsi leur alignement avec la stratégie globale.

• The Supply Chain Coordinator: Essentiel pour assurer le bon déroulement de l’initiative, cette personne fait office de pont entre les différentes équipes internes. Sa principale responsabilité est de recueillir des retours, de communiquer avec les parties prenantes, et de confirmer/clarifier les processus et les décisions. Il s’assure que l’initiative est en adéquation avec les flux de travail existants de l’entreprise, tout en restant ouvert aux révisions potentielles de ces flux à l’avenir.

• The Data Officer: Les données constituent l’épine dorsale de l’initiative de la Supply Chain Quantitative, et cette personne en garantit l’accessibilité et la fiabilité. Chargé d’extraire des ensembles de données complets (comme les historiques de ventes et d’achats), il est responsable de l’automatisation et de la programmation 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.

• The Supply Chain Scientist: Ce rôle combine les éclairages apportés par le Supply Chain Coordinator avec les données du Data Officer afin d’automatiser les processus de prise de décision. En commençant par la préparation des données, le Supply Chain Scientist collabore étroitement avec le Coordinator pour clarifier toute ambiguïté relative aux données. Il formalise ensuite des stratégies en décisions opérationnelles, telles que les quantités de réapprovisionnement, et met en place des tableaux de bord et des KPIs pour assurer la transparence et le contrôle.

Voir project roles pour plus d’informations sur les différentes désignations au sein d’une initiative de la Supply Chain Quantitative.

3.3 Disposez-vous d’un tableau RACI complet (Responsable / Accountable / Consulted / Informed) pour la phase de mise en œuvre et pour la phase de production ?

Oui. Ces informations peuvent être présentées explicitement sous forme de tableau RACI si l’entreprise cliente le juge important.

Plus important encore, les Supply Chain Scientists (SCSs) intériorisent ce type de matrice afin de prendre des décisions appropriées et rapides au fur et à mesure que l’initiative progresse. En ce qui concerne les questions relatives à l’optimisation de la supply chain, l’essentiel réside dans la manière de cadrer le problème. Par la suite, l’accent est mis sur l’identification de la personne au sein de l’organisation la mieux placée pour y répondre. Il est crucial que toute cette analyse soit effectuée rapidement afin de préserver l’élan de l’initiative.

Dans ce but, les Supply Chain Scientists (SCSs) de Lokad sont chargés de piloter l’initiative et d’assumer la responsabilité de la qualité des résultats générés par la recette numérique de Lokad.

Ainsi, c’est un petit noyau de spécialistes hautement qualifiés qui est responsable des décisions 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 nombre de parties prenantes. La position de Lokad est que de tels systèmes tendent à diluer la responsabilité plutôt qu’à la rigidifier. Nos Supply Chain Scientists sont donc formés pour adopter et exercer cette responsabilité, ce qui inclut de s’assurer que les parties prenantes pertinentes de l’entreprise cliente soient consultées et pleinement informées de l’initiative.

3.4 Allez-vous documenter les rôles et les responsabilités à l’aide d’une matrice RACI (Responsibility, Accountability, Consulted, and Informed) pour toutes les parties prenantes impliquées dans le projet ? Allez-vous vous assurer que ce document soit discuté et approuvé par toutes les parties concernées ?

Oui. Tous ces éléments (et plus encore) sont rassemblés et documentés dans le Joint Procedure Manual (JPM). Le JPM est élaboré par les Supply Chain Scientists (SCSs) de Lokad (avec des éclairages recueillis 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. Rédiger ce document avec leurs propres mots démontre que les SCSs ont consacré un temps considérable à étudier, diagnostiquer et analyser la supply chain du client ainsi que la solution globale (sans simplement régurgiter la documentation préexistante du client).

Toute révision du JPM est partagée avec l’entreprise cliente. Le JPM lui-même est régulièrement abordé lors des sessions de travail entre Lokad et l’entreprise cliente.

Par ailleurs, notre expérience indique que lorsque des désaccords surviennent, ils reflètent habituellement un problème organisationnel à résoudre en interne dans l’entreprise cliente. C’est pourquoi nous recommandons que l’entreprise cliente nomme un Supply Chain Executive pour superviser l’initiative. L’une de ses principales contributions est d’agir en tant qu’intermédiaire lorsque de tels cas se présentent.

3.5 Allez-vous vous assurer que le groupe de travail du projet et les comités de pilotage soient constitués avec des ressources identifiées parmi les parties prenantes du projet ? Allez-vous vous assurer que le rythme opérationnel soit convenu par toutes les parties impliquées ?

Oui. En principe, nous suivons tout processus jugé nécessaire par – et formellement convenu avec – l’entreprise cliente. Les éléments convenus (ainsi que toute modification apportée au fur et à mesure de l’évolution de l’initiative) sont documentés dans le Joint Procedure Manual (JPM), qui inclut des détails relatifs au groupe de travail du projet et aux comités de pilotage. Grâce aux Supply Chain Scientists (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 œuvrons activement pour supprimer les couches bureaucratiques inutiles des supply chains de nos clients.

4. System Transition & Go-Live

4.1 Quelle est la durée de la transition du kick-off au go-live ?

La durée typique de la phase d’intégration est de 6 mois. Cette phase commence avec le kick-off et se termine lorsque Lokad est « en production » – c’est-à-dire lorsque nos recommandations automatisées de supply chain pilotent effectivement le(s) processus de prise de décision souhaité(s) par le client.

Cette durée peut être raccourcie d'1 mois si un data lake est déjà en place – un data lake bien conçu et documenté peut encore réduire la phase d’intégration. À l’inverse, cette phase est généralement prolongée de 1 à 3 mois lorsque l’environnement logiciel ou les systèmes du client sont excessivement complexes ou obsolètes.

Fait intéressant, la complexité de la supply chain elle-même n’a pas l’impact que l’on pourrait croire, car Lokad s’efforce de définir un périmètre suffisamment précis pour être réalisable dans le délai imparti. Notre expérience indique que des phases d’intégration dépassant 6 mois mettent l’initiative à risque de stagnation. Ainsi, nous concevons activement le périmètre afin d’atténuer ce risque.

De tels retards ont peu à voir avec l’installation technique de Lokad lui-même. Dans l’ensemble, le calendrier proposé ne sert pas uniquement des objectifs 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 les spécificités de l’entreprise cliente, et aux équipes de la supply chain de « digérer » l’approche de Lokad – ce qui représente généralement une rupture 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 réalisés sur site est négocié dans le cadre des termes contractuels spécifiques avec l’entreprise cliente, bien qu’il soit à noter que les frais de déplacement peuvent impacter les honoraires facturés par Lokad. Ainsi, l’inclusion de visites sur site relève en fin de compte d’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 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 à 100M USD) et pour celles qui sont généralement à l’aise avec des collaborateurs à distance (comme les grandes entreprises du e-commerce). 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 avec succès le 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 à 1B USD), nous recommandons au moins une visite/atelier sur site par trimestre. Cette approche contribue à instaurer une cohésion à l’échelle de l’entreprise, surtout lorsque des équipes importantes sont impliquées.

Pour nos clients en Europe de l’Ouest, nous avons tendance à effectuer davantage de visites (généralement d’une durée d’une journée) que d’ateliers lorsque nous sommes sur site. Pour nos clients en dehors de l’Europe de l’Ouest, nous organisons plutôt davantage d’ateliers (généralement étalés sur plusieurs jours) que de visites. Cette différence est simplement une question de coûts de déplacement et de logistique.

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

Pour une initiative de la Supply Chain Quantitative, la majorité des réunions devraient se tenir à distance. La plupart des réunions sont brèves (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 avantageuses pour certaines tâches techniques, car tous les participants ont accès à leur propre configuration informatique, y compris de grands moniteurs. 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. Ces réunions facilitent souvent la transmission d’idées complexes, la discussion de perspectives 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 ces réunions sur site comme des événements importants, notamment lorsque Lokad accueille le client.

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

4.4 Aidez-vous l’entreprise cliente à effectuer une vérification de la qualité de l’environnement de production pour évaluer sa préparation au go-live, y compris la mise en place d’interfaces ?

Oui. En fait, Lokad va au-delà de la simple assistance à l’entreprise cliente dans son évaluation de préparation au go-live. L’une des responsabilités principales des Supply Chain Scientists (SCSs) de Lokad est d’assumer la responsabilité de bout en bout de la solution 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 néanmoins une personne qui assume personnellement la responsabilité du système. Elle veille à l’exactitude, à la pertinence et à la justesse du pipeline de traitement des données de bout en bout – en tenant également compte des préoccupations globales de l’entreprise cliente.

Étant donné leur caractère sujet à 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é ingress (lorsque Lokad reçoit des données historiques de l’entreprise cliente) et du côté egress (lorsque Lokad retourne des décisions supply chain à l’entreprise cliente). Pour cette tâche, Lokad s’appuie sur des méthodologies et technologies spécifiques.

Veuillez consulter programming paradigms for supply chain pour mieux comprendre le type de technologies sur lesquelles Lokad s’appuie afin de garantir la préparation au go-live.

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 Joint Procedure Manual (JPM). Cette documentation exhaustive, produite par les Supply Chain Scientists (SCSs) de Lokad, garantit que tant les praticiens supply chain que les cadres supply chain ont accès à des documents bien rédigés qui expliquent le processus de manière compréhensible. Les SCSs font des efforts notables pour s’assurer que ce document soit accessible à un public non technique (bien que certaines annexes puissent être assez techniques).

De plus, l’approche en dual-run de Lokad est particulièrement adaptée pour assurer une transition en douceur du processus legacy vers la nouvelle solution. « Dual-run », dans ce contexte, fait référence à la pratique selon laquelle Lokad fonctionnera en parallèle avec le processus de prise de décision legacy sur l’ensemble de la portée de l’initiative. Cette pratique n’est rendue possible que grâce à la nature robotisée du processus de prise de décision legacy par Lokad, ce qui garantit que les recettes numériques implémentées par les SCSs de Lokad ont été exécutées de manière satisfaisante dans des conditions de production exactes, sur l’ensemble de la portée, pendant des semaines précédant le go-live effectif, où les décisions de Lokad supplantent le processus legacy.

Il faut noter qu’un tel dual-run 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 supply chain, les surcoûts associés à un dual-run sont importants. Par conséquent, le dual-run est, au mieux, réalisé sur une portée limitée qui ne reflète pas véritablement 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 un dual-run à pleine portée.

4.6 Fournissez-vous le périmètre, les délais et les critères de succès pour le pilote à examiner et à approuver par l’entreprise cliente ?

Oui. Le périmètre est toujours détaillé dans l’accord contractuel entre Lokad et l’entreprise cliente. Il prend généralement la forme d’un type donné de décision supply chain (par exemple, le réapprovisionnement en stocks ou l’allocation de stocks) sur un ensemble de sites et/ou sur un ensemble de systèmes d’information.

Le délai est généralement inférieur à 6 mois (du démarrage à la production). Bien qu’un délai prévisionnel soit toujours inclus dans notre proposition commerciale, il peut ne pas être précisé dans l’accord contractuel. Le délai contraignant représente un engagement mutuel, et le rythme de l’initiative Lokad dépend de la réalisation 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 position de décider que le pilote a été un succès si l’entreprise cliente pense autrement.

Voir également Project Implementation & Management 1.2.

Veuillez consulter Assessing the Success of a Quantitative Supply Chain Initiative pour en savoir plus sur ce point nuancé.

4.7 Organiserez-vous la conduite des pilotes afin de 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 aux objectifs ?

Oui. En règle générale, nous traitons un pilote – destiné à fournir l’optimisation de la supply chain – exactement de la même manière qu’une initiative « réelle » destinée à être mise en production. À toutes fins utiles, en ce qui concerne l’optimisation de la supply chain, un pilote adéquat est indiscernable d’un environnement de pré-production approuvé pour l’usage en production.

L’équipe de Supply Chain Scientists (SCSs) de Lokad est responsable de tout ce qui précède. D’après notre expérience, l’adéquation des données est rarement un problème dans les entreprises qui se sont digitalisées il y a de nombreuses années (voire des décennies). Tant qu’il existe un système d’information pour suivre ce qui est acheté, produit, stocké, et vendu, l’initiative est pratiquement garantie de disposer de 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 bad data pour plus d’informations à ce sujet.

5. Gestion du changement et des risques

5.1 Quel support proposez-vous à l’entreprise cliente pour faciliter 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, qui sont 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 plusieurs manières, notamment :

• Proposer des améliorations aux processus existants pour les praticiens 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 de choix du client) l’impact des changements apportés à la supply chain.

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

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 des SCSs - qui sera allouée pour soutenir l’initiative. Nos propositions commerciales anticipent généralement que les SCSs fourniront un certain support en gestion du changement. Cependant, nos propositions ne prévoient généralement pas de support « à grande échelle » pour la gestion du changement - à moins que le client ne le demande explicitement.

5.2 Durant la phase de production, quelle est votre vision pour 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 Lokad en production, une catégorie entière de décisions supply chain est automatisée. L’objectif est alors de transformer la pratique supply chain en une entreprise capitalistique. Chaque heure consacrée par un praticien supply chain devrait contribuer à l’amélioration continue des recettes numériques. Cela s’écarte de la pratique supply chain « classique » où la grande majorité des efforts d’une journée donnée est allouée à maintenir l’entreprise en activité pour un jour de plus. Naturellement, la transition vers cette forme à valeur ajoutée de la supply chain se fait de manière progressive.

• Le premier jalon consiste à amener les praticiens supply chain à reconnaître que Lokad leur permet d’écarter la majeure partie du processus legacy. 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 ne nécessitent pas de révision supplémentaire. En fait, l’absence totale d’incohérences dans les chiffres générés par Lokad constitue le critère principal pour un go-live en production. La confiance que les praticiens supply chain peuvent accorder aux chiffres de Lokad libère naturellement beaucoup de temps pouvant être mieux utilisé.

• Le second jalon consiste à avoir quelques « early adopters » parmi les praticiens supply chain. Il s’agit généralement de personnes qui parviennent rapidement à se détacher du processus legacy non générateur de valeur - par exemple, la révision manuelle 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 sous le bon angle ?).

• Le troisième jalon consiste à ce que la majorité des praticiens 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 permettre d’obtenir un alignement qui va au-delà des frontières de l’entreprise cliente. Cela élargit le vivier d’insights collectés et contribue à affiner davantage les recettes numériques.

La nouvelle organisation se rapproche beaucoup plus d’une entreprise de logiciels. Il y a peu de tâches répétitives en supply chain qui sont gérées manuellement - ces tâches étant 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 s’accompagne d’une augmentation de la variété des tâches pour le praticien 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 une attente accrue de la part de la direction quant au développement des compétences des employés pour qu’ils puissent capitaliser sur le temps et les efforts disponibles accrus.

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

5.3 Comment gérez-vous le changement de workflow pour les utilisateurs finaux ? D’abord, avec l’intégration de Lokad, ensuite avec l’évolution propre à Lokad.

Par conception, les décisions supply chain générées par Lokad ne nécessitent pas de workflows. En effet, automatiser toutes les étapes impliquées dans la génération des décisions supply chain est l’agencement souhaité.

Cependant, si le client le demande explicitement, Lokad est en mesure d’introduire un « workflow » qui reflète celui de legacy. Cela, il faut le comprendre, est uniquement destiné à faciliter la gestion du changement, et n’est en aucun cas une condition requise pour le succès de la recette numérique. À mesure que les employés de l’entreprise cliente se familiarisent davantage avec – et développent une plus grande confiance dans – les décisions générées par Lokad, le « workflow » peut être progressivement simplifié, jusqu’à ce qu’il soit complètement supprimé.

Concernant l’évolution de Lokad, notre plateforme est programmable et gérée par Envision (notre langage de programmation spécifique au domaine). Toute modification/mise à jour d’Envision est effectuée via des scripts automatisés, et ce processus est programmé de manière à ce que les initiatives supply chain hébergées par Lokad restent inchangées.

5.4 Pouvez-vous tenir un registre des Issues & Risks incluant un plan de mitigation, des tâches, des responsabilités, des échéances, et un statut (non commencé, en cours, fermé, en attente) ? Le Project Manager de Lokad sera-t-il responsable de suivre toutes les Issues & Risks et d’assurer des résolutions rapides ou de gérer les escalades lorsque nécessaire ?

Oui. La plateforme de Lokad est dotée de son propre gestionnaire interne d’issues/tickets/tâches. Cette fonction offre toutes les capacités habituelles que l’on attend communément 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 Joint Procedure Manual (JPM) qui offre une présentation complète et bien organisée de l’initiative avec tous les échéanciers 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 issues et les préoccupations soient traitées rapidement.

Les escalades sont possibles mais rares. Le même SCS qui gère/revoit les tâches les résoudra également. Les Senior SCSs de Lokad remplissent une large gamme de rôles : expert supply chain, data engineer, data integrator, business analyst, data scientist, project manager, change consultant, etc.

La possibilité de contacter facilement les SCSs est un point positif souvent cité par nos clients. Le client peut immédiatement interagir avec la personne chargée de veiller à la résolution satisfaisante de toute issue, plutôt que de devoir naviguer à travers plusieurs niveaux de bureaucratie pour, espérons-le, parler à quelqu’un capable de l’aider.

Dans le cas où un problème requiert des compétences en dehors de l’expertise d’un SCS (par exemple, un problème technique avec l’architecture de la plateforme), celui-ci supervise néanmoins la résolution rapide du problème et agit comme premier point de contact pour le client concerné.

5.5 Proposez-vous des services de conseil en gestion du changement organisationnel afin de prendre en charge l’introduction et la modification des processus commerciaux, ainsi que la mise hors service 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 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 en gestion du changement en complément de Lokad, nous la soutiendrons en partageant autant que l’entreprise cliente jugera prudent.

6. Personnalisation & Fonctionnalité 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 mise en production des personnalisations ?

Oui. Les Supply Chain Scientists (SCSs) de Lokad sont en charge 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 la personnalisation de manière autonome et, par conséquent, est en mesure de fournir des indications claires sur ce qui est en jeu en termes de ressources et de délais.

Cela améliore considérablement la qualité de la priorisation, car l’entreprise cliente bénéficie d’un expert capable de peser rapidement les avantages de tout changement supply chain par rapport aux coûts associés à ce changement.

Deuxièmement, ‘la Supply Chain Quantitative’ - la philosophie globale de Lokad - met l’accent sur une perspective purement financière. Dès lors, les SCS accompagnent l’entreprise cliente en fournissant des estimations quantitatives (en dollars ou en euros) de l’impact d’un éventuel changement à apporter à la solution. Cette stratégie affine l’initiative en évitant l’éventuel goulot d’étranglement traditionnel du débat sur ce qui devrait être priorisé. Au lieu de cela, Lokad rationalise ce processus en donnant la priorité aux problèmes ayant le plus grand impact financier.

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

Oui. Les Supply Chain Scientists (SCSs) de Lokad sont en charge de ce processus. Bien qu’une étude initiale soit réalisée au démarrage de l’initiative, ce processus se poursuit tout au long de la phase de production. Cela fait partie de notre démarche visant à obtenir des améliorations continues de la solution.

En ce qui concerne l’optimisation de la supply chain, les lacunes relèvent rarement de la « fonctionnalité », mais plutôt de la « 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 soient les plus rentables (performance).

Ainsi, les SCS se chargent d’identifier et de 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 d’ajouter ou de supprimer des fonctionnalités pour optimiser la performance globale.

À ce sujet, 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 Envision code. Cette programmabilité est précisément ce qui permet à Lokad de fournir des solutions sur mesure à chaque client.

6.3 Pouvez-vous fournir un ordre du jour détaillé pour les ateliers d’analyse fit-gap du processus, incluant les attentes des experts métier (SME) 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 ordre du jour pour chaque atelier. Nous veillons à ce que l’ordre du jour 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 l’ordre du jour, nous les suivrons alors. En l’absence d’instructions, nous structurerons les ateliers (y compris la chronologie et la communication de toutes les étapes nécessaires du côté du client) de manière intelligente et professionnelle.

6.4 Veillez-vous à ce que les documents relatifs aux exigences de personnalisation du produit soient examinés conjointement et approuvés par l’entreprise cliente ?

Oui, ces documents seront fournis à – et approuvés par la suite par – l’entreprise cliente.

Veuillez noter que les choix de conception de la plateforme de Lokad éliminent en grande partie le besoin de « personnalisation » – du moins dans le sens courant de ce terme 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 » dans le sens où elles sont entièrement adaptées aux besoins spécifiques de l’entreprise cliente. Toutefois, cette personnalisation est réalisée de manière à ce que la solution demeure une partie intégrante de la gamme de produits principale de Lokad. Il s’agit de l’approche privilégiée (et délibérément conçue) par Lokad, et cela ne présente aucun problème de maintenabilité.

6.5 Assistez-vous l’entreprise cliente dans la mise en place de la connectivité des interfaces avec des systèmes externes, ainsi que dans le test et la certification des interfaces ?

Oui. Les Supply Chain Scientists (SCSs) de Lokad apportent leur soutien pour mettre en place, 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 certaines ressources informatiques internes de Lokad pour les aspects techniques de bas niveau, tels que la mise en 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 conjointement approuvées 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 dans les délais ; Lokad, de son côté, s’engage à restituer les résultats dans les délais.

6.6 Fournissez-vous des documents de spécification des interfaces lors des ateliers, incluant 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.

Cependant, compte tenu de la nature du service de Lokad, les « messages d’exemple » prendront très probablement la forme de tableaux – car cela représente de façon plus précise 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 concentrera sur les tableaux et leurs formats, ainsi que sur les schémas d’extraction des tableaux et les calendriers de transfert.

6.7 Partagez-vous les processus de gestion des demandes de changement et des mises à jour ?

Oui. Les Supply Chain Scientists (SCSs) de Lokad sont en charge de ce processus. Il est important de noter que Lokad dispose de deux niveaux de changements et de mises à jour, ce qui diffère des logiciels d’entreprise typiques.

Premièrement, les changements effectués spécifiquement pour les clients sont implémentés par les SCS eux-mêmes. Ces changements surviennent fréquemment, souvent plusieurs fois par jour, notamment durant la phase d’intégration. De tels changements répondent directement aux besoins de l’entreprise cliente et impliquent une communication considérable entre les deux parties.

Deuxièmement, nous effectuons des mises à jour de la plateforme de Lokad, généralement via des mises à jour de 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 nécessaire, les détails concernant ces mises à jour peuvent être fournis, et une grande partie de ces informations est rendue accessible au public.

Voir Envision VM Environment and General Architecture pour plus d’informations sur l’évolution de la plateforme de Lokad.

7. User Acceptance Testing (UAT)

7.1 Assistez-vous l’entreprise cliente dans la mise en place de 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 en charge 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 (ROI) décroissant pour l’entreprise. Cet aspect est crucial pour s’assurer que le temps des utilisateurs finaux ne soit pas gaspillé à examiner de grandes quantités de données en grande partie sans pertinence.

Du point de vue technologique, la plateforme de Lokad a été spécialement 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 ainsi être introduits avec un coût minimal, tant en termes de ressources de calcul que de temps d’administration système.

Voir aussi User Acceptance Testing 7.3.

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

Oui. Étant donné la richesse programmative de la plateforme de Lokad, nous pouvons exercer un contrôle total sur les configurations. Ceci est rendu possible grâce à Envision – notre DSL (langage de programmation spécifique au domaine) dédié à l’optimisation prédictive de la supply chain.

Cette approche permet à différents environnements d’utiliser la même configuration pour toutes les parties qui ne sont pas sujettes à changement – en utilisant le même code autant que possible. Cela réduit considérablement les différences accidentelles entre les environnements, qui peuvent embrouiller les utilisateurs et compromettre l’intégrité du processus UAT.

De plus, faire progresser une configuration d’une étape à une autre est simple avec notre conception. Utiliser une base de code pour les modifications de configuration est plus efficace que les méthodes traditionnelles basées sur l’interface utilisateur.

7.3 Fournissez-vous des environnements distincts pour l’UAT (User Acceptance Testing), la migration de données, la phase de production (pré-prod), la production et la 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écialement 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 ainsi être introduits avec un coût minimal, tant en termes de ressources de calcul que de temps d’administration système.

Avec Lokad, dupliquer 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’affecte pas négativement la performance d’un autre environnement.

Cependant, la plupart des fournisseurs 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 peu efficace. Cloner signifie que la quantité de ressources (humaines et matérielles) augmente linéairement avec le nombre d’environnements — par exemple, trois environnements triplent les coûts initiaux. Pour une 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 l’UAT (User Acceptance Testing) soit complété dans les délais convenus mutuellement ?

Oui, à condition de se mettre d’accord sur des définitions nuancées de « résolution » et de « défaut ». Dans l’ensemble, les Supply Chain Scientists (SCSs) de Lokad sont en charge 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, en ce qui concerne la supply chain, il n’existe pas de solutions parfaites, seulement de meilleurs ou de moins bons compromis. En d’autres termes, on ne peut réellement résoudre un problème où deux ou plusieurs valeurs sont en complète opposition.

Par exemple, des stocks périssables expirés sont du gaspillage, mais lorsqu’il s’agit de produits périssables, un tel gaspillage ne peut être complètement éliminé sans créer un problème de taux de service conséquent. Il faut trouver un équilibre entre les stocks morts et les ruptures de stock. Pourtant, les « stocks morts » et les « ruptures de stock » sont, en un sens, des défauts.

En bref, les SCSs peuvent résoudre les problèmes « banals » dès leur apparition, tels que corriger une erreur d’analyse lors de la lecture d’un fichier (un bug logiciel). Cependant, l’objectif global d’une solution de la Supply Chain Quantitative n’est pas de « résoudre des problèmes » mais d’augmenter le retour sur investissement (en dollars ou en euros). Lokad parvient à cette forme de « résolution » grâce à une approche intelligente, axée sur les considérations financières, des compromis en supply chain.

7.5 Assistez-vous l’entreprise cliente dans la révision des scénarios, cas de test et données de test pour l’UAT (User Acceptance Testing) ?

Oui. Les Supply Chain Scientists (SCSs) de Lokad sont en charge de ce processus.

Cependant, en ce qui concerne l’optimisation de la supply chain, des ensembles de données plus petits que l’ensemble de la configuration de production ne sont généralement pas suffisants. En pratique, les scénarios, cas de test et données de test doivent être (pratiquement) aussi grands que la configuration de production afin de refléter une vision de la 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 Garantissez-vous un support sur site au siège de l’entreprise cliente pendant la phase d’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 est caractérisée par une amélioration continue de la supply chain, il n’existe donc pas de période UAT fixe. Les tests débutent généralement à la fin du deuxième mois, atteignent un pic au quatrième mois, puis se stabilisent à partir du sixième mois.

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

Voir aussi Project Implementation & Management 1.7.

8. Post-Implementation Support & Auditing

8.1 Pouvez-vous garantir que les observations issues des pilotes soient documentées, que toutes les actions à mener soient assignées aux parties prenantes concernées au sein des départements Technique, IT et Fournisseurs de l’entreprise cliente, et également suivies jusqu’à leur clôture ?

Oui. Les Supply Chain Scientists (SCSs) de Lokad créent et maintiennent un Manuel de Procédures Conjoint (JPM) pour chaque initiative. Il inclut toutes les informations pertinentes pour l’initiative. Il est important de noter que le JPM est conçu pour être accessible aux audiences non techniques (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 par le gestionnaire de tâches de 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 garantir que des rapports de qualité et de conformité suffisants soient disponibles pour surveiller l’utilisation et l’adoption du système ?

Oui. Les Supply Chain Scientists (SCSs) de Lokad mettent généralement en œuvre une instrumentation dédiée à cet effet lors de la dernière phase d’intégration, juste avant le démarrage officiel.

De plus, Lokad peut suivre l’alignement entre les décisions supply chain qu’elle 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 les bugs ou dysfonctionnements dans les systèmes du client, susceptibles d’affecter la mise en œuvre des recommandations de Lokad.

8.3 Réaliserez-vous un audit annuel de l’application et fournirez-vous des retours visant à améliorer l’utilisation et l’adoption par les utilisateurs finaux du système, afin de réaliser le ROI (return on investment) plus rapidement ?

Oui, un audit annuel de l’ensemble de la solution (end-to-end) est une procédure opérationnelle standard. Cela dit, les Supply Chain Scientists (SCSs) de Lokad audite généralement l’ensemble de la solution plusieurs fois au cours de l’année. L’audit annuel conduit habituellement à une présentation détaillée de la feuille de route pour la direction du client. Ceci est en accord avec notre approche d’amélioration continue pour chaque initiative.

Concernant l’utilisation, en pratique, les SCSs mettent en place de manière proactive des outils dédiés dès le départ 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 constitue une excellente opportunité pour effectuer les ajustements nécessaires, nos SCSs sont très proactifs en matière d’adoption des recommandations de supply chain de Lokad. Cette question sera discutée lors de nos sessions de travail hebdomadaires, l’adoption des recommandations de Lokad étant le principal moteur d’une augmentation du ROI dans une initiative de la Supply Chain Quantitative.

8.4 Pouvez-vous garantir que l’équipe de support produit dédiée, basée au siège social de la société cliente, continue de soutenir le produit pendant au moins 6 mois après le lancement ?

Oui. L’équipe des Supply Chain Scientists (SCSs) de Lokad prend en charge cette tâche. Nos SCSs sont amplement formés pour à la fois améliorer continuellement l’initiative et fournir un support continu au client. La présence continue des SCSs sur site sera négociée et clarifiée dans l’accord contractuel avec le client, si tel est le souhait de ce dernier.

Sur une note connexe, Lokad recommande vivement de maintenir un engagement actif et continu en faveur de l’amélioration de la solution, en particulier du côté du client. Selon notre expérience, la suppression progressive des efforts d’amélioration continue compromettra la solidité de l’initiative. Tout changement côté client, y compris de modestes ajustements dans le paysage applicatif ou des contraintes, peut impacter la qualité des décisions générées par Lokad, d’où la nécessité d’une vigilance active et d’une amélioration continue.

Voir aussi Project Implementation & Management 1.7.

9. Gestion des incidents et des défauts

9.1 Pouvez-vous garantir que tous les défauts indispensables ainsi que les demandes de modification (éléments critiques et de haute priorité) soient traités en priorité et livrés, afin d’éviter tout retard dans le calendrier de mise en production de la société cliente ?

Oui. Les Supply Chain Scientists (SCSs) de Lokad sont chargés de ce processus. Notre plateforme est conçue de manière à leur permettre de traiter les défauts et les demandes de modification de façon 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 de la supply chain. Cette programmabilité signifie que les SCSs peuvent rapidement fournir des correctifs et mettre en œuvre les changements demandés sur l’initiative, avec un niveau de précision rarement rencontré 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 modification. Ces rôles incluent expert en supply chain, analyste métier, data scientist, data engineer et intégrateur de systèmes. Ils sont ainsi bien formés pour fournir des correctifs et des mises à jour tout en gardant à l’esprit les priorités principales du client.

Voir aussi Customization & System Functionality 6.2.

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

Oui, la plateforme de Lokad est équipée de son propre système de gestion des tâches / tickets / problèmes. Ces capacités nous donnent la possibilité de suivre avec précision la résolution rapide des problèmes. Ces résolutions sont prises en charge par les équipes de Supply Chain Scientists (SCSs) employés par Lokad.

Cependant, il est important de ne pas regrouper les « défauts » et les « problèmes d’utilisabilité ». Par exemple, une prévision de la demande inexacte est un « défaut ». Elle a un impact négatif sur la supply chain. Toutefois, selon les conditions du marché dans lesquelles la société cliente opère, ce « défaut » peut ne jamais être corrigé, seulement atténué. En ce qui concerne l’optimisation prédictive de la supply chain, les solutions font toujours l’objet d’un compromis : résoudre un défaut peut en créer un autre (espérons-le, de moindre importance).

En revanche, les problèmes d’utilisabilité sont généralement simples à résoudre. Ainsi, pour cette catégorie de problèmes, nous nous engageons à assurer une résolution rapide, car leur traitement 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 utile, afin qu’ils n’impactent pas le calendrier de mise en production de la société 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 ils seront rectifiés par les équipes d’ingénierie logicielle de Lokad.

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

9.4 Comment traiterez-vous les incidents qui pourraient être signalés par la société cliente via l’un des canaux suivants : téléphone, email, office communicator et/ou saisie directe dans l’outil de gestion des incidents ?

Les Supply Chain Scientists (SCSs) traitent tous les rapports d’incidents - quelle que soit leur origine - avec la plus grande rigueur. L’accord contractuel entre Lokad et la société 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 la création par un SCS 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 celui-ci 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 lui-même/elle-même.

Enfin, une fois le problème résolu, le SCS évaluera la véritable cause profonde du problème signalé, même si le rapport a finalement été diagnostiqué comme n’étant pas un problème. Habituellement, il existe un problème sous-jacent quelque part qui doit être traité. En s’attaquant à la cause profonde, Lokad élimine de manière proactive les 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’email – l’enregistrerez-vous dans l’outil dès qu’il est remonté pour un suivi et une conformité appropriés ?

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