FAQ: Gestion du changement

Public visé : Les départements supply chain et/ou de planification.

Dernière modification : 19 décembre 2023

Aperçu de la gestion du changement

La Supply Chain Quantitative (QSC), telle qu’elle a été initiée et défendue par Lokad, diverge de manière significative de la perspective traditionnelle. Les différences sont à la fois essentielles et constituent les raisons principales pour lesquelles Lokad peut offrir des améliorations drastiques de la supply chain. Cela dit, la gestion du changement associée à la mise en œuvre d’une initiative de la Supply Chain Quantitative 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 le gaspillage par un autre gaspillage. Ainsi, le changement à gérer se présente généralement sous deux aspects : d’une part, s’adapter au fait que les décisions supply chain banales et répétitives sont désormais automatisées ; d’autre part, accepter que la qualité de ces décisions automatisées dépasse ce que les employés pouvaient auparavant obtenir avec des outils alternatifs (systèmes legacy, tableurs, et souvent un peu des deux).

Une initiative de la Supply Chain Quantitative est pilotée par les Supply Chain Scientists de Lokad. Ces experts regroupent de nombreux rôles qui seraient habituellement assurés par plusieurs personnes dans des initiatives similaires menées par d’autres éditeurs de logiciels. Un Supply Chain Scientist assume les fonctions d’intégrateur système, d’ingénieur de données, d’analyste d’affaires, de data scientist, d’expert en supply chain et de chef de projet (parmi d’autres rôles). Les Supply Chain Scientists (SCSs) fournissent tout l’encadrement, la formation, les conseils et le support nécessaires pour que les clients adoptent l’approche quantitative de supply chain proposée par Lokad.

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

En termes de gestion du changement, les économies de supply chain ne posent généralement pas de problème. L’entreprise pourrait finalement 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. Cependant, les économies de productivité considérables générées par Lokad sont habituellement réinvesties dans d’autres tâches qui apportent une valeur ajoutée bien supérieure à celle du processus legacy.

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

Une fois Lokad en production, la plupart des activités se tournent vers l’extérieur : identifier ce que les clients perçoivent comme un taux de service satisfaisant, identifier ce que les fournisseurs considèrent comme un obstacle à une baisse de prix supplémentaire, identifier ce que les transporteurs perçoivent comme les causes profondes de leur manque de fiabilité, etc.

Ces éclairages sont ensuite continuellement intégrés à la solution de Lokad grâce au support continu des SCSs.

Pour les cadres de la supply chain, le plus grand changement est l’élimination, dans l’ensemble, des interventions répétées face aux imprévus. La solution de Lokad délivre des décisions automatisées conçues pour traiter efficacement les cas limites agaçants, réduisant ainsi considérablement la charge que les cadres doivent consacrer à analyser les comportements erratiques du marché. Cela libère les cadres de la supply chain pour élaborer des stratégies et des projets supply chain, plutôt que de microgérer les conséquences continues de décisions sous-optimales.

Questions fréquemment posées (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 assurés par les Supply Chain Scientists (SCSs) de Lokad. Ces experts ne se contentent pas de gérer la mise en œuvre, ils pilotent également l’initiative au sein de l’entreprise cliente. Cela comprend de nombreuses tâches telles que fournir une garantie 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 du matériel 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 pour le succès à long terme de l’initiative, même après la mise en œuvre initiale, en fournissant un support continu lors de la transition de l’initiative vers sa phase d’amélioration continue.

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

1.2 Quel est votre calendrier de mise en œuvre et quelles étapes ou phases comprend-il ?

De bout en bout, la mise en œuvre dure habituellement 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 cette phase, les décisions supply chain d’intérêt (telles que définies en collaboration avec le client) devraient être robotisées.

Breakdown of timeline

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

• Mois 1-2 : Configuration du Data Pipeline - La première sous-phase consiste à configurer 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 pipeline (presque) parfaitement fiable.

• Mois 3-4 : Conception de la recette numérique - 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 supply chain. L’objectif est d’obtenir des recettes cohérentes, fiables et sans fioritures. La rédaction des recettes numériques initiales est rapide, durant généralement pas plus d’une semaine ou deux.

• Mois 5-6 : Dual Run - La troisième sous-phase consiste en un dual run. La recette numérique ne produit plus d’absurdités, et les leviers économiques pilotant l’optimisation ont été validés. La recette est exécutée en parallèle avec le processus legacy. Au terme de plusieurs semaines de dual run, la confiance nécessaire 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 legacy.

1.3 Lokad documente-t-il et publie-t-il un plan de gestion de projet ?

Oui. Tous ces éléments, et plus encore, sont rassemblés dans un Joint Procedure Manual (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 tout au long de l’initiative.

Selon Lokad, de nombreuses initiatives en entreprise (voire la plupart) sont entravées par la production de documents peu utiles, qui, en pratique, sont impossibles à lire (c’est-à-dire qu’ils sont fastidieux ou d’une technicité impenetrable). Ces documents ne servent à rien d’autre qu’à cocher des cases inventées. De plus, de nombreux tiers (par exemple, les intégrateurs, les consultants, et même la bureaucratie interne) ont une forte tendance à privilégier la quantité sur la qualité en matière de documentation de 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 disposions de directives étendues sur ce qui est censé se trouver dans un JPM, il incombe finalement aux SCSs de faire des choix judicieux quant à ce qui nécessite le plus d’attention et d’effort, en tenant compte des spécificités de l’initiative.

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

1.4 Lokad est-il responsable de la maintenance et de la mise en ligne du plan de gestion de projet, sous réserve des approbations du comité de pilotage du projet ? Si des déviations par rapport au plan apparaissent, 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 concernant la gestion de la communication avec l’entreprise cliente dépendent généralement des termes contractuels de l’initiative.

Il arrive parfois qu’il y ait significativement plus d’employés du côté client du projet que du côté de Lokad, c’est pourquoi, pour améliorer la productivité des SCSs en charge 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 relayer les informations pertinentes à toutes les parties impliquées du côté client, et de recueillir leurs retours. Pour une initiative particulièrement complexe, Lokad met en place un comité de pilotage dédié composé de membres clés de Lokad et de l’entreprise cliente. Bien que cette réunion serve de mécanisme pour obtenir une approbation formelle, la majeure partie du travail substantiel s’effectue en dehors du comité lui-même. Les SCSs interagissent typiquement 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 représentent une manière bien plus efficace de discuter et de surmonter les problèmes techniques au fur et à mesure qu’ils apparaissent, plutôt que d’essayer d’examiner en bloc de nombreux problèmes lors d’une séance du comité de pilotage. Ainsi, le comité de pilotage agit en tant qu’organe de supervision plutôt qu’en tant que groupe de réflexion pour l’initiative.

Note : Les initiatives de supply chain quantitatives sont connues pour rencontrer fréquemment des “déviations positives”. Il s’agit de 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 ignorées. Ainsi, un avantage clé de l’approche de communication de Lokad est la capacité à relayer promptement et efficacement ces déviations positives au client dès qu’elles surgissent, augmentant ainsi considérablement l’impact et l’agilité de l’initiative.

1.5 Documenterez-vous le plan de communication, comprenant les réunions quotidiennes debout, les rapports d’activité hebdomadaires des groupes de travail et les sessions de revue, ainsi que les rapports et sessions de revue mensuels du comité de pilotage ? Définirez-vous les critères d’escalade et vous assurerez-vous d’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.

Lokad participe volontiers aux réunions quotidiennes debout lorsqu’il est présent sur le site du siège de l’entreprise cliente. Habituellement, cependant, nos SCSs opèrent depuis les bureaux de Lokad.

Nous regroupons l’ensemble de la documentation de l’initiative dans un Joint Procedure Manual (JPM) qui sert en effet 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 lignes directrices d’escalade, il convient de souligner qu’un Senior SCS chez Lokad est censé traiter toute question ou préoccupation relative à l’initiative. Ainsi, en matière d’escalade, la résolution d’un problème préoccupant est généralement transmise d’un Junior SCS à un Senior SCS. Cela s’est historiquement avéré suffisant, avec très peu de cas nécessitant une escalade supplémentaire.

Lokad considère que tous les problèmes - aussi mineurs soient-ils en apparence - méritent une analyse approfondie. Bien que leurs effets soient faciles à résoudre, les problèmes mineurs peuvent engendrer des difficultés futures si les 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 la mise en place de personnes hautement compétentes en première ligne capables de traiter à la fois le problème immédiat et d’identifier les causes profondes sous-jacentes. Cette approche est préférable à celle consistant à s’appuyer sur du personnel de support non formé qui s’occupe en continu des mêmes problèmes - un schéma trop fréquemment adopté par de nombreux éditeurs de logiciels d’entreprise.

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

1.6 Vous 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 formels. Ce principe demeure applicable tout au long de l’initiative, du début jusqu’à la fin. L’initiation du projet est certes importante, mais étant donné que Lokad n’exige pas un engagement à long terme dès le premier jour, cette question est d’une importance moindre – surtout en comparaison avec nos concurrents.

Il convient de noter que nous n’avons jamais observé qu’une supply chain fonctionne mal en raison d’un “manque” de bureaucratie ou d’autres processus futiles. Au contraire, des bureaucraties inutiles et des processus inopportuns sont les problèmes les plus courants que l’on retrouve 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 d’affaires et d’experts en interface technique ?

Oui, si ces dispositions font partie des termes contractuels convenus pour l’initiative. Bien que Lokad ne soit pas opposé à ce que des employés soient stationnés sur le site du siège de la société cliente, cela augmente naturellement le coût de l’initiative. La plupart de nos initiatives sont réalisé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 locaux du client. Il convient de noter que, même si Lokad accepte de stationner une équipe permanente au siège de la société cliente, les employés seront amenés à tourner avec le temps.

Ces pratiques bénéficient à tous les intervenants, car les Supply Chain Scientists (SCSs) de Lokad suivent un programme de formation continue. Ce programme est essentiel pour s’assurer que nos employés continuent d’acquérir de nouvelles compétences ou d’affiner les anciennes, quelle que soit leur expérience ou leur ancienneté. Alors que nous constatons que de nombreux fournisseurs d’entreprise autorisent leurs employés à 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’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 une variété de rôles, tels que : expert du domaine, analyste d’affaires, expert en interface technique, data scientist et consultant en supply chain. Ces fonctions seraient normalement assurées par plusieurs employés, ce qui entraînerait une augmentation significative des coûts pour le client. Chez Lokad, chaque SCS fournit l’ensemble de ces services.

De ce fait, les SCSs ont tendance à être nettement plus productifs (moins de personnes signifie généralement moins de frictions dans la communication), et à obtenir des niveaux de performance supérieurs. 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 à réaliser avec un faible effectif.

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 à la société cliente de désigner un praticien supply chain expérimenté comme coordinateur de l’initiative, et de nommer également un cadre supply chain en tant que superviseur de l’initiative. Le coordinateur sert de point de contact entre l’équipe de Supply Chain Scientists (SCSs) de Lokad et la société cliente. Le coordinateur transmettra initialement les demandes d’information, puis relayera les demandes de retour. Parallèlement, les SCSs de Lokad travaillent avec les recettes numériques visant à produire les décisions de supply chain recherchées.

Nous recommandons une réunion hebdomadaire pour passer en revue l’avancement de l’initiative jusqu’à la fin de la phase d’intégration. À cette réunion participent systématiquement le coordinateur, le superviseur et le principal SCS de Lokad en charge du compte. D’autres participants peuvent se joindre si nécessaire, mais leur présence continue n’est généralement pas indispensable pendant toute la phase de mise en œuvre/intégration.

Quelques 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 la société cliente ne soit confrontée à un verrouillage fournisseur, cette configuration technique nécessite moins de 4 semaines de travail pour un seul contributeur - et parfois bien 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 priorités et contraintes de la supply chain. Une série d’entretiens, animée par les coordinateurs, aura généralement lieu pour accompagner ce processus. Par la suite, une fois les recettes numériques développées par les SCSs, une autre série d’entretiens sera organisée afin de passer en revue les chiffres générés par ces recettes et de permettre aux SCSs de les affiner et de les améliorer.

L’apport du superviseur est important à la fois pour aligner Lokad sur la stratégie globale poursuivie par l’entreprise et pour éviter que l’initiative ne stagne en raison d’une indécision. Par exemple, Lokad peut proposer diverses options pour modéliser les coûts lié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 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 correspondent mieux au contexte et aux objectifs spécifiques de la société cliente.

Pour plus d’informations, Lokad propose plusieurs conférences dédiées à une optimisation réussie de la supply chain.

2. Gestion des ressources & Exigences

2.1 Quelles sont les exigences en matière de main-d’œuvre pour la mise en œuvre du projet chez la société cliente ?

Une initiative typique de Lokad nécessite environ 0,5 à 2 ETP (équivalent temps plein) de ressources employées de la société cliente durant les 6 premiers mois – c’est-à-dire la phase d’intégration. Une fois l’initiative passée en production, on estime raisonnablement que le projet nécessitera encore au moins 0,25 ETP.

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 data officer, généralement employé par le service informatique du client. Le data officer doit être assez familier avec le paysage applicatif de la société cliente.

• 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 la part de divers praticiens supply chain pour fournir des informations de haut niveau, puis pour donner un retour sur les chiffres produits par Lokad.

• Mois 5 et 6 : Les besoins restent essentiellement les mêmes que lors de la phase précédente, toutefois, l’accent change. Le coordinateur consacre désormais la majeure partie de son temps à préparer le déploiement approprié et à communiquer avec tous les praticiens supply chain concernés.

Voir aussi Mise en œuvre du projet & Management 1.2.

2.2 Garantissez-vous que suffisamment de main-d’œuvre est planifiée 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’intégration à la phase de production. Le retour sur investissement potentiel d’une solution bien entretenue et continuellement améliorée est considérable.

Il convient de noter que, étant donné que Lokad automatise les décisions de supply chain, il n’est pas strictement urgent de requalifier tous les praticiens supply chain du client avec un nouveau processus pour maintenir en mouvement les rouages de la supply chain - l’automatisation est conçue pour prendre en charge cela.

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 en main-d’œuvre et en produits de connaissance (KP) sont disponibles sur site au siège de la société cliente pour soutenir la transition du produit ?

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

Voir aussi Mise en œuvre du projet & Management 1.7.

Voir aussi Gestion des ressources & Exigences 2.2.

2.4 Organisez-vous des sessions de revue des exigences avec les propriétaires de produits métiers 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é par le biais d’entretiens avec les parties prenantes concernées, y compris les propriétaires de produits métiers. Nous essayons également de passer en revue 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 requiert un traitement spécial pour les « slow movers », nous comprenons que le faible volume constitue une préoccupation à résoudre. Toutefois, le traitement particulier de ces SKU n’est qu’une des nombreuses options qui s’offrent à nous pour répondre à ce problème.

Dans cet exemple, notre préférence serait de déterminer la véritable nature des « slow movers ». En fait, après avoir étudié les points de douleur de la supply chain du client, il se peut que les « slow movers » soient des SKU mal tarifés, mal groupés et/ou mal alloués. Une fois le problème (les slow movers) mieux compris, cela change 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 sur l’acceptation au premier abord de l’état actuel de la supply chain du client.

Voir Tombez 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 concernant les fonctionnalités nécessitant une personnalisation, y compris les interfaces système, et les partagez-vous après l’atelier d’analyse des écarts de 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 nous appuierons sur les informations recueillies lors de celui-ci pour affiner davantage notre proposition.

La plateforme Lokad est programmative. 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 outillé pour fournir des fonctionnalités et des interfaces sur mesure, que ces interfaces soient destinées aux utilisateurs ou aux systèmes d’information de la société cliente.

Contrairement à la plupart des logiciels d’entreprise, la programmabilité est une caractéristique essentielle de Lokad. Les scripts Envision mentionnés ci-dessus ne constituent pas une « personnalisation » de la solution Lokad au sens habituel du terme. De même, la présence de ces scripts ne représente pas un écart par rapport à la branche de développement principale de la solution Lokad. Au contraire, la riche programmabilité de Lokad est la voie de mise en œuvre prévue.

En conséquence, nos estimations (coûts, planning, etc.) bénéficient d’un degré de certitude extrêmement élevé. La grande majorité des projets restent dans les estimations/le budget initial (à tous égards). Cela contraste avec plusieurs concurrents de Lokad, pour qui des retards coûteux et des reformulations des termes sont monnaie courante.

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

2.6 Allez-vous mettre en place et maintenir une stratégie de rétention raisonnable visant à conserver les personnels clés assurant les services pendant la durée de l’accord ? Allez-vous également maintenir des plans de succession actifs pour chacun des postes clés de Lokad ?

Oui. Nous conservons nos employés en moyenne pendant 3,5 ans, soit près du 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 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. En conséquence, la plupart des initiatives de Lokad bénéficient de la présence des mêmes Supply Chain Scientists (SCSs) d’une année sur l’autre.

Cette rétention s’explique par des salaires compétitifs et l’investissement continu de Lokad dans la formation de ses équipes. En particulier, le contenu sur la supply chain publié par Lokad sur son propre site web, notamment 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 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 appliquons deux pratiques importantes. Premièrement, chaque initiative de Lokad est accompagnée d’un Manuel de Procédures Conjoint (JPM). Le JPM est le document principal utilisé par un nouveau SCS pour se familiariser rapidement avec toutes les informations pertinentes et les aspects techniques de l’initiative. Deuxièmement, chaque initiative dispose, en tout temps, d’un SCS principal et secondaire. Même si le SCS secondaire ne contribue pas directement à l’initiative, Lokad consacre suffisamment de temps pour s’assurer que cette personne soit prête à reprendre l’initiative en cas de besoin. Cette pratique atténue largement les complications liées aux absences/turnover imprévus.

3. Rôles, Responsabilités & Gestion des parties prenantes

3.1 Quel niveau de coopération entretenez-vous avec la société cliente ?

Le niveau de coopération que nous entretenons avec nos clients varie, mais globalement il est bien supérieur à ce qui est généralement attendu d’un fournisseur de logiciels d’entreprise. Les problématiques de supply chain ne revêtent pas la même importance pour toutes les entreprises, ainsi, la collaboration tend à être plus forte pour les entreprises pour lesquelles la supply chain est l’ossature (reconnue) de leurs activités.

Le terme « partenaire » a été galvaudé 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, au bout d’un an ou deux, la plupart de nos clients considèrent leur relation avec Lokad comme un véritable partenariat – au sens véritable du terme. Ils ont des visages familiers chez Lokad qui ont gagné leur confiance et, par conséquent, ces personnes – typiquement les 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 reconçue, impactant positivement tant les clients que les fournisseurs. Il convient de noter que Lokad n’a aucune intention de remplacer l’expertise stratégique critique existant dans l’entreprise cliente. Au contraire, Lokad souhaite automatiser l’aspect le plus banal et répétitif des processus de prise de décision en supply chain. Cette approche libère ensuite d’importantes ressources - souvent rares - qui peuvent être redirigées vers de meilleures utilisations.

3.2 Quels rôles et responsabilités prévoyez-vous d’instaurer, tant au sein de l’entreprise cliente que chez 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.

• Le Supply Chain Leader : Ce rôle met en avant l’importance de l’implication de la haute direction dans l’initiative de la Supply Chain Quantitative. Bien qu’il ne soit pas question d’entrer dans les détails techniques, cette personne doit comprendre et communiquer les orientations stratégiques de l’initiative. Son rôle n’est pas de créer des indicateurs et des KPI, mais plutôt de les évaluer de manière critique et de les remettre en question, afin de garantir leur alignement avec la stratégie globale.

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

• Le 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 (tels que les historiques de ventes et d’achats), il est responsable de l’automatisation et de la planification de l’extraction de 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 Supply Chain Scientist : Ce rôle combine les connaissances du Supply Chain Coordinator avec les données du Data Officer pour automatiser les processus de prise de décision. À partir de la préparation des données, le Supply Chain Scientist collabore étroitement avec le Coordinateur pour clarifier toute ambiguïté dans les données. Il formalise ensuite des stratégies en décisions concrètes, telles que les quantités de réapprovisionnement, et met en place des tableaux de bord et des KPI 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 (Responsible / 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 la forme d’un tableau RACI si cela est jugé important par l’entreprise cliente.

Plus important encore, les Supply Chain Scientists (SCSs) intègrent ce type de matrice afin de prendre des décisions adaptées et rapides au fur et à mesure de l’avancement de l’initiative. En ce qui concerne les questions liées à l’optimisation d’une supply chain, l’essentiel est de déterminer la meilleure manière de cadrer le problème. Ensuite, l’attention se porte sur l’identification de la personne la mieux placée au sein de l’organisation pour résoudre le problème. Il est essentiel que toute cette analyse soit réalisée rapidement afin de préserver l’élan de l’initiative.

Dans ce but, les 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 parties de responsabilité 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 SCSs sont donc formés pour adopter et assumer cette responsabilité, ce qui inclut s’assurer que les parties prenantes concernées de l’entreprise cliente soient consultées et pleinement informées de l’initiative.

3.4 Documenterez-vous les rôles et responsabilités en utilisant une matrice RACI (Responsibility, Accountability, Consulted, and Informed) pour toutes les parties prenantes impliquées dans le projet ? Veillerez-vous à ce que ce document soit discuté et approuvé par toutes les parties concernées ?

Oui. Tous ces éléments (et plus encore) sont rassemblés et documentés dans le Manuel de Procédures Joint (JPM). Le JPM est produit par les Supply Chain Scientists (SCSs) de Lokad (avec des informations recueillies 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 pris le temps d’investiguer, de diagnostiquer et d’analyser la supply chain du client ainsi que la solution globale (et non pas de 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 discuté lors des sessions de travail entre Lokad et l’entreprise cliente.

À noter, notre expérience indique qu’en cas de désaccords, ceux-ci reflètent généralement un problème organisationnel devant être résolu au sein de 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 contributions clés est d’agir comme intermédiaire lorsque de tels cas se présentent.

3.5 Veillerez-vous à ce que le groupe de travail du projet et les groupes directeurs soient constitués avec des ressources nommées parmi les parties prenantes du projet ? Veillerez-vous à ce 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 (et tout changement apporté au fur et à mesure de l’initiative) sont documentés dans le Manuel de Procédures Joint (JPM), qui comprend des détails concernant le groupe de travail du projet et les groupes directeurs. 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 à éliminer les couches bureaucratiques superflues des supply chains de nos clients.

4. Transition du système et mise en production

4.1 Quelle est la durée de la transition du kick-off à la mise en production ?

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 que nos recommandations automatisées en supply chain orientent effectivement le(s) processus de prise de décision désirés par le client.

Cette durée peut être réduite d’un mois si un data lake est déjà en place – un data lake bien construit et documenté peut encore raccourcir 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 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 durant plus de 6 mois mettent l’initiative en péril de stagnation. Ainsi, nous élaborons activement le périmètre pour atténuer ce risque.

De tels retards sont peu liés à l’installation technique de Lokad lui-même. Globalement, le calendrier proposé ne sert pas seulement à des fins techniques (automatisation de l’extraction des données, test des recettes numériques, etc.), mais permet aussi aux Supply Chain Scientists (SCSs) de Lokad de maîtriser pleinement toutes 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 éloignement 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 conditions contractuelles spécifiques avec l’entreprise cliente, bien qu’il faille noter que les frais de déplacement peuvent influencer les honoraires facturés par Lokad. Ainsi, l’inclusion de visites sur site est en dernière instance 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 acceptons 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 les entreprises qui sont généralement à l’aise avec des collaborateurs à distance (comme les grandes entreprises de le 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 le changement avec succès, nous sommes d’accord pour des visites chaque mois - voire plus fréquemment 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 permet de développer une harmonisation à l’échelle de l’entreprise, surtout lorsque des équipes importantes sont impliquées.

Pour nos clients en Europe de l’Ouest, nous avons tendance à réaliser davantage de visites (généralement d’une seule journée) que d’ateliers sur site. Pour nos clients hors Europe de l’Ouest, nous avons tendance à organiser plus d’ateliers (généralement sur plusieurs jours) que de visites sur site. Cette différence est simplement due aux coûts de déplacement associés et à la logistique.

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

Pour une initiative de la Supply Chain Quantitative, la majorité des réunions doivent se tenir à distance. La plupart des réunions sont courtes (30 minutes ou moins) et impliquent seulement 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 des tâches techniques spécifiques, car tous les participants ont accès à leur propre installation informatique, y compris l’accès à 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. Les réunions sur site facilitent souvent la transmission d’idées complexes, la discussion de perspectives et/ou la révision des attentes entre les parties. Ainsi, nous recommandons d’adopter un rythme régulier pour les réunions sur site (par exemple, hebdomadaire/mensuel/trimestriel…). Lokad considère ces réunions sur site comme des événements significatifs, en particulier lorsque Lokad reçoit le client.

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

4.4 Assistez-vous l’entreprise cliente dans la réalisation d’un contrôle qualité de l’environnement de production pour évaluer la préparation à la mise en production, y compris la mise en place des interfaces ?

Oui. En fait, Lokad va au-delà de la simple assistance à l’évaluation de la préparation à la mise en production de l’entreprise cliente. L’une des principales responsabilités des Supply Chain Scientists (SCSs) de Lokad est de prendre en charge la solution end-to-end livrée à l’entreprise cliente. Autrement dit, bien qu’un système mécanisé (une flotte de machines) génère les résultats, c’est toujours une personne qui assume la responsabilité personnelle du système. Elle garantit l’exactitude, la pertinence et l’adéquation de la chaîne de traitement des données end-to-end – tout en prenant en compte les préoccupations globales de l’entreprise cliente.

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

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

4.5 Préparez-vous le document de stratégie de transition et de migration de production pour gérer la transition fluide 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 Joint (JPM). Cette documentation exhaustive, produite par les Supply Chain Scientists (SCSs) de Lokad, garantit que tant les praticiens de la supply chain que les cadres de la supply chain disposent de supports bien rédigés qui expliquent adéquatement le processus de manière compréhensible. Les SCSs déploient des efforts notables pour rendre ce document 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 hérité vers la nouvelle solution. Le “dual-run”, dans ce contexte, fait référence à la pratique où Lokad fonctionne en parallèle avec le processus de prise de décision hérité sur l’ensemble du périmètre de l’initiative. Cette pratique n’est rendue possible que grâce à la robotisation 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 ont fonctionné de manière satisfaisante dans des conditions de production exactes, sur l’ensemble du périmètre, pendant des semaines avant la mise en production effective, où les décisions de Lokad supplantent le processus hérité.

Il convient de 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 en supply chain, les frais généraux associés à un dual-run sont significatifs. Par conséquent, le dual-run est, au mieux, réalisé sur un périmètre restreint qui ne reflète pas réellement les conditions de production. En conséquence, lorsque cette approche est adoptée, l’extension tardive du périmètre conduit invariablement à des incidents de production qui auraient été entièrement évitables avec un dual-run à périmètre complet.

4.6 Fournissez-vous le périmètre, les échéances et les critères de succès pour le pilote à faire réviser et valider 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 des stocks ou l’allocation de stocks) sur un ensemble de sites et/ou sur un ensemble de systèmes d’information.

L’échéancier est généralement inférieur à 6 mois (du lancement à la production). Bien qu’un échéancier prévisionnel soit toujours inclus dans notre proposition commerciale, il pourrait ne pas être précisé dans le contrat. L’échéancier 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 mise en place 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 en aucun cas se trouver en position de décider que le pilote a été un succès si l’entreprise cliente pense le contraire.

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

Veuillez consulter Évaluer le succès d’une initiative de la Supply Chain Quantitative pour plus de précisions sur ce point nuancé.

4.7 Organiserez-vous la réalisation de pilotes afin d’assurer 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 à l’usage prévu ?

Oui. En règle générale, nous traitons un pilote – destiné à apporter l’optimization de la supply chain – exactement comme nous traiterions une initiative « réelle » destinée à être mise en production. À tous égards, en ce qui concerne l’optimization de la supply chain, un pilote adéquat est indiscernable d’une configuration de préproduction approuvée 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 ont adopté le digital 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 quasiment assurée 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’optimization de la supply chain.

Voir bad data pour plus d’informations sur ce point.

5. Gestion du changement et des risques

5.1 Quel soutien pouvez-vous offrir à l’entreprise cliente pour aider à gérer la conduite 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’optimization de la supply chain. Les SCSs assistent dans le processus de gestion du changement de multiples façons, 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.
• Assister 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 temporel significatif pour un SCS. Bien que chaque SCS dispose de compétences et d’une expérience qui lui sont propres pour aider la direction de la supply chain dans la conduite du changement, cette responsabilité concurrence toutes leurs autres attributions.

Ainsi, les termes contractuels négociés entre Lokad et chaque client précisent la quantité de ressources - c’est-à-dire la taille de l’équipe de 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. Toutefois, nos propositions ne reflètent habituellement aucun type de soutien « à grande échelle » en matière de gestion du changement - sauf si le client en fait expressément la demande.

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 catégorie entière de décisions supply chain est automatisée. L’objectif est alors de transformer la pratique de la supply chain en une entreprise capitalistique. Chaque heure consacrée par un praticien de la supply chain devrait contribuer à l’amélioration continue des recettes numériques. Cela s’éloigne de la pratique « classique » de la supply chain 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 de supply chain génératrice de valeur est progressive.

• Le premier jalon consiste à amener les praticiens de la supply chain à reconnaître que Lokad leur permet de se débarrasser de la majeure partie des processus hérités. Par exemple, il est judicieux 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, 0 % d’incohérences dans les chiffres générés par Lokad est le critère principal pour une mise 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 utilisé de manière plus judicieuse.

• Le deuxième jalon consiste à avoir quelques « early adopters » parmi les praticiens de la supply chain. Il s’agit généralement de personnes qui parviennent rapidement à se détacher du processus hérité sans valeur ajoutée – 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. Elles 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 de la supply chain se tournent vers l’extérieur (clients et fournisseurs) plutôt que vers l’intérieur. En fin de compte, la supply chain doit permettre une harmonisation qui dépasse les limites de l’entreprise cliente. Cela élargit le champ des connaissances recueillies et aide à affiner davantage les recettes numériques.

La nouvelle organisation se rapproche davantage 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 – celles-ci é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 entraîne une augmentation de la diversité 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 l’on attend davantage de la direction pour requalifier les employés afin qu’ils puissent tirer parti du temps et des efforts supplémentaires disponibles.

Voir (Software) Livraison orientée produit pour la 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 de Lokad.

Par conception, les décisions supply chain générées par Lokad ne nécessitent pas de workflows. En effet, l’automatisation de 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 expressément, Lokad est capable d’introduire un « workflow » qui reproduit celui hérité. Il faut comprendre que cela a uniquement pour but de faciliter la gestion du changement et ne constitue en aucun cas une condition nécessaire au succès de la recette numérique. À mesure que les employés du client se familiarisent davantage avec – et accordent une plus grande confiance aux – décisions générées par Lokad, le « workflow » peut être progressivement simplifié, jusqu’à son élimination complète.

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

5.4 Pouvez-vous maintenir un registre des Problèmes et Risques incluant un plan d’atténuation, des tâches, des responsabilités, des timelines, et un statut (non commencé, en cours, clôturé, en attente) ? Le Chef de Projet de Lokad sera-t-il responsable du suivi de tous les Problèmes et Risques et de garantir leur résolution en temps opportun ou de gérer les escalades lorsque nécessaire ?

Oui. La plateforme de Lokad est livrée avec son propre gestionnaire interne de problèmes/tickets/tâches. Cette fonction 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 Conjoint (JPM) qui fournit une présentation complète et bien structurée de l’initiative avec toutes les timelines de haut niveau pertinentes. 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 préoccupations soient traités rapidement.

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

La facilité de contacter les SCSs est fréquemment citée par nos clients comme un atout majeur. Le client peut interagir immédiatement avec la personne chargée de veiller à la résolution satisfaisante de tout problème, plutôt que de devoir naviguer à travers plusieurs niveaux de bureaucratie pour espérer converser avec quelqu’un capable de l’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 lié à 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 pour aborder l’introduction et la modification des processus métiers, ainsi que la désaffectation 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 la principale expertise de Lokad réside dans l’optimization 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 en gestion du changement pour compléter Lokad, nous les soutiendrons en partageant autant que l’entreprise juge prudent.

6. Personnalisation et Fonctionnalités du Système

6.1 Organisez-vous des sessions pour prioriser les exigences de personnalisation, afin de garantir une compréhension des impacts métiers dus aux lacunes du produit et d’aboutir à un accord mutuel sur la priorité de déploiement des personnalisations ?

Oui. Les Supply Chain Scientists (SCSs) de Lokad sont chargés de ce processus. En fait, Lokad se démarque sur deux axes en ce qui concerne cette priorisation. Tout d’abord, un SCS est capable de mettre en œuvre la personnalisation de manière indépendante et peut ainsi fournir des éclaircissements précis sur ce qui est en jeu en termes de ressources et de timeline.

Cela améliore considérablement la qualité de la priorisation, car l’entreprise cliente bénéficie d’un expert capable d’équilibrer rapidement les avantages de tout changement dans la supply chain avec les coûts qui y sont associés.

Deuxièmement, « la Supply Chain Quantitative » – la philosophie globale de Lokad – met l’accent sur une perspective strictement financière. Ainsi, le SCS aide l’entreprise cliente à fournir 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 l’étranglement traditionnel lié aux débats sur ce qui doit être priorisé. Au lieu de cela, Lokad rationalise ce processus en priorisant les problématiques entraînant le plus grand impact financier.

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

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

En ce qui concerne l’optimization de la supply chain, les lacunes ne relèvent que 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 sont les plus rentables (performance).

Ainsi, les SCSs se préoccupent d’identifier et de combler 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 afin d’optimiser la performance globale.

Par ailleurs, la plateforme de Lokad est programmatique. Ainsi, toute « lacune fonctionnelle » perçue peut être corrigée 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 ordre du jour détaillé pour les ateliers d’analyse des écarts processus, incluant les attentes des experts métiers (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 nous assurons 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, comme un délai pour fournir l’ordre du jour, nous les suivrons. En l’absence d’instructions, nous structurerons les ateliers (y compris le planning 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 d’exigences de personnalisation du produit soient examinés et approuvés conjointement 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 tel que ce terme est couramment compris dans le domaine des logiciels d’entreprise. La plateforme de Lokad est programmatique, utilisant Envision - notre DSL (langage de programmation spécifique au domaine) dédié à l’optimization prédictive de la supply chain.

Ainsi, les solutions de Lokad sont toujours «customisées» dans le sens où elles sont entièrement adaptées aux besoins spécifiques de l’entreprise cliente. Cependant, cette customisation est délivrée de manière à ce que la solution reste intégrée à la ligne principale de produits de Lokad. C’est l’approche préférée (et délibérément conçue) de Lokad, et elle ne présente aucun problème de maintenabilité.

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

Oui. Les Supply Chain Scientists (SCSs) de Lokad fournissent un support pour mettre en place, 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 certaines ressources IT internes chez Lokad pour les aspects techniques de bas niveau, tels que les protocoles de réseau ou de sécurité.

Les interfaces système ne sont généralement pas « certifiées » par un organisme tiers de certification. Les interfaces sont « spécifiées formellement » à travers des spécifications techniques convenues conjointement entre le département IT 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, de son côté, s’engage aussi à renvoyer les résultats dans les délais.

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.

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 manière plus précise la sortie que Lokad génère pour le client. Pour information, la grande majorité des spécifications techniques pour les interfaces portera sur les tableaux et leur(s) format(s), ainsi que sur les schémas d’extraction de tableaux et les calendriers de transfert.

6.7 Partagez-vous le 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 mis en œuvre par les SCSs eux-mêmes. Ces changements surviennent fréquemment, souvent plusieurs fois par jour, particulièrement pendant la phase d’onboarding. Ces modifications 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 sur la plateforme de Lokad, généralement via des mises à jour d’Envision – notre DSL (domain-specific programming language) dédié à l’optimisation prédictive de supply chain. Ces changements sont conçus pour être transparents pour les entreprises clientes. Si souhaité, les détails concernant ces mises à jour peuvent être fournis, et une grande partie de ces informations est rendue publique.

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

7. Tests d’acceptation par l’utilisateur (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 offre des innovations méthodologiques et techniques uniques à cet effet.

En termes de méthodologie, nous privilégions la conception de listes priorisées, 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 non pertinentes.

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

Voir également User Acceptance Testing 7.3.

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

Oui. Étant donné la riche programmabilité de la plateforme de Lokad, nous pouvons exercer un contrôle complet sur les configurations. Cela est rendu possible grâce à Envision – notre DSL (domain-specific programming language) dédié à l’optimisation prédictive de 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, lesquelles peuvent déstabiliser les utilisateurs et compromettre l’intégrité du processus UAT.

De plus, faire passer une configuration d’une étape à une autre est simple grâce à notre conception. Utiliser une base de code pour les modifications de configuration est plus efficace que les méthodes traditionnelles via interface utilisateur.

7.3 Fournissez-vous des environnements séparés 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écifiquement conçue pour prendre en charge simultanément plusieurs environnements pour une initiative donnée. Ces environnements sont une fonctionnalité native de notre plateforme SaaS multi-tenant, et peuvent donc être introduits avec un minimum de frais généraux, 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. En interne, les données identiques entre les deux environnements sont mutualisées. De plus, notre conception à temps constant garantit que la charge de travail d’un environnement n’affecte pas négativement les performances d’un autre environnement.

Cependant, la plupart des fournisseurs de logiciels d’entreprise contournent le problème en « clonant » simplement la configuration principale. Le clonage – ou la duplication pure – est facile mais gaspilleur. Cloner signifie que la quantité de ressources (personnes et machines) augmente linéairement avec le nombre d’environnements — par exemple, trois environnements triplent les coûts initiaux. Pour toute supply chain d’envergure, cela se traduit par des coûts substantiels.

7.4 Garantissez-vous la résolution en temps voulu de tous les défauts pour assurer que l’UAT (User Acceptance Testing) soit complété dans les délais convenus mutuellement ?

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

Il est essentiel de souligner que, lorsqu’il s’agit de supply chain, il n’existe pas de solutions parfaites, seulement de meilleurs et de moins bons compromis. Autrement dit, il est impossible de résoudre un problème où deux ou plusieurs valeurs s’opposent complètement.

Par exemple, des stocks périssables expirés représentent un gaspillage, mais lorsqu’on gère des produits périssables, ce gaspillage ne peut être complètement éliminé sans engendrer un problème de qualité de service conséquent. Un équilibre doit être trouvé entre stock mort et ruptures de stock. Pourtant, tant le « stock mort » que les « ruptures de stock » constituent, en un sens, des défauts.

En bref, les SCSs peuvent résoudre des problèmes « banals » dès qu’ils surviennent, comme 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 atteint ce type de « résolution » grâce à une approche intelligente, financièrement orientée, des compromis en supply chain.

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

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

Cependant, en ce qui concerne l’optimisation de supply chain, des ensembles de données plus petits que l’ensemble de l’environnement de production ne sont généralement pas suffisants. En pratique, les scénarios, les cas de test et les données de test doivent être (presque) aussi volumineux que l’environnement de production pour refléter une perspective end-to-end 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 une assistance sur site au siège de l’entreprise cliente pendant la phase UAT (User Acceptance Testing) ?

Oui. L’assistance sur site est régie par l’accord contractuel entre Lokad et l’entreprise cliente. Cet aspect est toujours négocié au cas par cas.

Il convient de noter qu’une initiative de supply chain quantitative avec Lokad se caractérise par une amélioration continue de la supply chain, ce qui fait qu’il n’existe pas de période UAT fixe. Les tests commencent généralement à la fin du deuxième mois, culminent au quatrième mois, puis se stabilisent à partir du sixième mois.

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

Voir également Project Implementation & Management 1.7.

8. Support post-implémentation et audit

8.1 Pouvez-vous garantir que les observations issues des cycles pilotes soient documentées, que les actions à entreprendre soient assignées aux parties prenantes concernées dans les départements Technique, IT et Fournisseurs de l’entreprise cliente, et qu’elles soient suivies jusqu’à clôture ?

Oui. Les Supply Chain Scientists (SCSs) de Lokad créent et maintiennent un Manuel de Procédure Conjointe (JPM) pour chaque initiative. Il inclut tous les éléments pertinents de 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 via le gestionnaire de tâches sur la plateforme de Lokad. Ces actions mineures sont de courte durée, et le gestionnaire de tâches facilite leur suivi et leur clôture mieux que le JPM.

8.2 Pouvez-vous 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 implantent généralement une instrumentation dédiée à cet effet lors de la dernière phase d’onboarding, juste avant le lancement officiel.

De plus, Lokad peut suivre l’alignement entre les décisions supply chain qu’elle génère et les décisions réelles prises dans la supply chain. Ceci permet d’identifier d’éventuelles sources de divergence, telles que des bugs ou des dysfonctionnements dans les systèmes du client, qui pourraient 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 pour améliorer l’utilisation et l’adoption du système par les utilisateurs finaux, afin d’accélérer le ROI (retour sur investissement) ?

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 auditeront généralement l’ensemble de la solution à plusieurs reprises 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’aligne avec notre approche d’amélioration continue pour chaque initiative.

En pratique, les SCSs mettent en œuvre de manière proactive, dès le départ, des outils dédiés afin de surveiller l’utilisation, l’adoption et la conformité avec les décisions supply chain générées par Lokad. Bien qu’un audit annuel offre une excellente opportunité d’apporter les ajustements nécessaires, nos SCSs sont très proactifs quant à l’adoption des recommandations de Lokad. Cette question sera discutée lors de nos sessions de travail hebdomadaires, car l’adoption des recommandations de Lokad constitue le principal levier pour augmenter le ROI dans une initiative de la Supply Chain Quantitative.

8.4 Pouvez-vous garantir que l’équipe dédiée de support produit, basée sur site au siège de l’entreprise cliente, continue de supporter le produit pendant au moins 6 mois après sa mise en production ?

Oui. L’équipe des Supply Chain Scientists (SCSs) de Lokad s’occupe de cette tâche. Nos SCSs sont suffisamment formés pour à la fois améliorer continuellement l’initiative et fournir un support continu au client. La présence continue sur site des SCSs sera négociée et précisée dans l’accord contractuel avec le client, si celui-ci le souhaite.

Par ailleurs, Lokad recommande fortement de maintenir un engagement actif et continu envers l’amélioration de la solution, en particulier du côté client. Abandonner les efforts d’amélioration continue, selon notre expérience, affaiblit la force de l’initiative. Tout changement côté client, y compris des ajustements modestes 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 également Project Implementation & Management 1.7.

9. Gestion des incidents et des défauts

9.1 Pouvez-vous garantir que tous les défauts indispensables et demandes de changement (éléments critiques et à haute priorité) soient traités en priorité et livrés, afin d’éviter tout retard dans le calendrier de mise en production 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 (domain-specific programming language) dédié à l’optimisation prédictive de supply chain. Cette programmabilité signifie que les SCSs peuvent rapidement apporter des corrections et mettre en œuvre les changements demandés dans l’initiative, avec un niveau de précision rarement retrouvé 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 supply chain, business analyst, data scientist, data engineer et system integrator. Ils sont ainsi bien formés pour fournir des correctifs et des mises à jour tout en gardant en tête les priorités principales du client.

See also Customization & System Functionality 6.2.

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

Oui, la plateforme Lokad est fournie avec son propre système de gestion des tâches / tickets / problèmes. Ces capacités nous donnent la possibilité 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.

Il est toutefois 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 impacte négativement la supply chain. Cependant, selon les conditions de marché dans lesquelles l’entreprise cliente opère, ce « défaut » peut ne jamais être corrigé, seulement atténué. Lorsqu’il s’agit de l’optimisation prédictive des supply chains, les solutions impliquent toujours un compromis : résoudre un défaut peut en créer un autre (espérons-le de moindre ampleur).

En revanche, les problèmes d’utilisabilité sont généralement simples à résoudre. Ainsi, pour ce type de problèmes, nous sommes disposés et engagés à assurer une résolution rapide, car régler le problème ne génère 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, afin qu’ils n’impactent pas le calendrier de mise en production de l’entreprise cliente ?

Oui. Si les défauts identifiés concernent la base de code spécifique au client (écrite en Envision), alors les défauts seront rectifié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 rectifiés par les équipes d’ingénierie logicielle de Lokad.

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

9.4 Comment allez-vous traiter les incidents qui pourraient être signalés par l’entreprise 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 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 la création, par un Supply Chain Scientist, d’une nouvelle entrée dans le gestionnaire de tâches/tickets/problèmes. Cela garantit une traçabilité de l’incident.

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

Enfin, une fois que le problème est résolu, le Supply Chain Scientist évaluera la véritable cause fondamentale de l’incident signalé, même si le rapport a finalement été diagnostiqué comme n’étant pas un problème. Il y a généralement 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 – par un autre canal tel que l’email - allez-vous enregistrer le défaut dans l’outil dès qu’il est rapporté pour un suivi et une conformité appropriés ?

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