Par Joannes Vermorel, juin 2015« L’horreur non euclidienne a émergé des tréfonds des systèmes informatiques des entreprises. Elle peut rendre aveugle si on la fixe trop longtemps. »
Catégorie : organisation
Problème : ces dernières années, les entreprises ont mis en place différents systèmes. Elles disposent désormais d’un ERP, d’un WMS (système de gestion d’entrepôt), d’un CRM (outil de gestion de la relation client), d’un cube BI (veille économique), d'une plate-forme de commerce électronique, etc. Entre les installations de ces systèmes, des composants ont été développés en interne pour effectuer certaines tâches plus spécialisées. Ainsi, la complexité du paysage informatique a fortement augmenté depuis quelques années : chaque application supplémentaire doit communiquer avec celles déjà en place dans l’entreprise. Tous les départements sont impactés, mais la logistique, de par sa position intermédiaire entre les ventes, les achats, la finance et la production, est le département le plus touché. Les modifications sont lentes et presque toutes les initiatives logistiques ne se terminent pas dans les temps. Plus personne ne comprend réellement ce qui se passe dans les systèmes des entreprises.
Anecdote : le déplacement de produits d’un entrepôt à l’autre peut être fait en deux semaines. Cependant, dans le système informatique, la migration nécessaire à l’intégration d’un nouvel entrepôt prend plus de six mois.
Contexte : à l’origine, au sein des entreprises, chaque département a mis en place sa propre solution logicielle. Ces solutions étaient peu intégrées les unes avec les autres et un ERP a été choisi « pour les gouverner toutes ». Cet ERP a été mis en œuvre, mais n’a pas été en mesure de s’adapter assez rapidement aux évolutions informatiques. En matière de logistique, un WMS (système de gestion d’entrepôt) a été mis en place pour améliorer la productivité et la fiabilité des outils et cette initiative a été une relative réussite. D’autres départements ont fait des choix similaires et mis en place des applications spécialisées plus adaptées que l’ERP choisi initialement. Mais l’activité de l’entreprise évolue de plus en plus vite et, aujourd'hui, toutes ces applications doivent interagir en permanence pour optimiser le fonctionnement de la supply chain.
Solution envisagée : devant chaque nouveau défi, les systèmes informatiques sont modifiés a minima, juste pour atteindre le résultat visé. Dans le département logistique, une intégration ad hoc a été mise en place avec l’outil de CRM pour obtenir des données de l’équipe de vente et une autre avec le cube BI pour recevoir des chiffres cohérents avec ceux utilisés par le département financier. Les services logistiques et les fournisseurs ont également nécessité quelques intégrations. L’équipe logistique a alors appris que plus une évolution informatique est importante, plus l’initiative risque de dépasser les délais et le budget prévus. Ainsi, les évolutions limitées et incrémentales sont désormais préférées aux grands bouleversements.
Contexte du résultat : le plan du métro de Tokyo paraît simple par rapport à la représentation des différentes interactions informatiques au sein d’une entreprise. En effet, il existe des centaines de subtiles dépendances entre tous les systèmes. L’architecture informatique dans son ensemble est, au mieux, relativement floue. En matière de logistique, la difficulté consiste à accéder aux informations utiles, telles que les nouveaux produits, les promotions, les commandes d’achat « presque » finalisées, l’historique des niveaux de stock et des ruptures de stock, etc. Chaque évolution des opérations logistiques —amélioration d’un processus grâce à des informations supplémentaires — semble prendre un temps fou. Les données reçues ne sont pas cohérentes, les systèmes tombent souvent en panne et des exceptions doivent en permanence être gérées manuellement.
Forces d’attraction : les entreprises ont appris à leurs dépens que plus une évolution informatique est importante, plus l’initiative risque de dépasser les délais et le budget prévus. Les méthodes ont donc évolué petit à petit vers des initiatives plus limitées et ciblées, qui sont plus facilement mises en œuvre dans le budget et les délais prévus. Les entreprises ont ainsi réussi à mener à bien de telles initiatives à petite échelle et obtenir des résultats positifs avec des budgets restreints.
Les raisons de l’échec : chaque modification incrémentale augmente le coût et la complexité de toutes les futures évolutions. Mais, puisque les entreprises favorisent les modifications aussi petites et incrémentales que possible, la situation générale n'est pas prise en compte. D’une certaine façon, il s’agit d’un cas de la « tragédie des biens communs », dans laquelle les intérêts individuels (ici des différents départements de l’entreprise) ne sont pas en adéquation avec les intérêts de l’entreprise dans son ensemble. Le problème est d’autant plus sérieux que les conséquences négatives sont généralement observées longtemps après la modification. Même si chaque modification semble rentable, l’entreprise accumule une « dette technique » et les profits à court terme deviennent, à plus long terme, des pertes.
Modèles positifs permettant de traiter le problème : à la base, l’approche incrémentale semble raisonnable. Cependant, chaque modification devrait être effectuée de façon à rendre les suivantes plus simples et moins coûteuses ; ces deux aspects étant fortement corrélés en pratique. Par conséquent, chaque initiative doit payer la
taxe des biens communs : atteindre son objectif principal ainsi qu'un objectif secondaire, c’est-à-dire faciliter les futures modifications.
Exemple : Contoso est une des principales entreprises de e-commerce en Allemagne, sur un segment B2C spécifique. L’entreprise a débuté son activité au début des années 2000, développant sur mesure son propre système frontend, une application qui permet aux utilisateurs de faire des achats en ligne. Au cours de ses premières années, presque tous ses besoins informatiques étaient satisfaits grâce à ce frontend en constante évolution. Mais cette application n’était pas capable de gérer les fournisseurs et les commandes d’achat de l’entreprise. Contoso a donc décidé d’investir dans un ERP de milieu de gamme et de transférer ses processus administratifs vers ce système, notamment l’ensemble de ses pratiques logistiques naissantes. Les niveaux de stock ont un temps été gérés à la fois dans le frontend et dans le système ERP, mais ce fonctionnement s’avérant désordonné, Contoso a réussi à débarrasser le frontend de ses responsabilités excessives.
L’ERP remplissait son rôle, mais l’entreprise continuait à croître et, malgré les efforts de l’équipe technique responsable des développements, il ne répondait plus aux exigences de l’activité. Les rapports étaient insuffisants et le département financier a décidé de mettre en place son propre portail BI (veille économique) et la plupart des autres départements ont fait de même. La logistique a lancé plusieurs intégrations EDI destinées à transmettre les commandes d’achat aux fournisseurs, mais l’alimentation de l’ERP était de plus en plus frustrante, car celui-ci ne pouvait pas appréhender toutes les subtilités des opérations logistiques de Contoso.
Contoso, désormais leader sur le marché national, avait accès à une large gamme d’options en matière d’approvisionnement. Les distributeurs allemands locaux, qui avaient joué un rôle clé dans le succès des débuts de Contoso, s’avéraient de plus en plus chers, alors que les concurrents de Contoso tiraient les prix vers le bas. Les clients n’étaient plus prêts à payer plus cher un achat effectué en ligne. Par conséquent, Contoso a dû s'orienter vers des options d’approvisionnement alternatives, comme des fournisseurs plus éloignés et parfois étrangers. Après plusieurs mois à essayer de faire avaler la logique d’approvisionnement multiple à l’ERP, l’équipe logistique a décidé de mettre en place son propre système, indépendant de l’ERP. Elle a sélectionné une application d’approvisionnement avancée, mais la configuration a pris beaucoup plus de temps que prévu. Ce n’était pas la faute de la nouvelle solution, mais l’intégration à l’ERP s’est avérée ardue. Par exemple, trois mois après le lancement de la nouvelle solution, l’équipe logistique s’est aperçue que les délais d’expédition affichés sur le site Web des clients n’étaient pas gérés par l’ERP, mais toujours par le frontend. Les « délais d’expédition affichés » passaient du frontend à l’ERP, mais pas dans l’autre sens. Les mises à jour des délais d’expédition dans l’ERP — effectuées de façon dynamique en fonction du fournisseur sélectionné — n’avaient donc aucune conséquence sur les chiffres affichés sur le site Web. L’ERP était déjà devenu une installation relativement complexe et, comme l’équipe informatique se sentait plus à l’aise avec le frontend développé en interne, les équipes informatique et logistique ont décidé conjointement que la solution d’approvisionnement injecterait les délais d’expédition modifiés directement dans le frontend.
Cette approche s’est cependant avérée bancale et les 3 mois prévus à l’origine pour le déploiement de l’application d’approvisionnement se sont transformés en 9 mois. Pourtant, cet investissement a été bénéfique puisque, grâce à la diversification de l’approvisionnement, les prix d’achat ont pu être réduits de 15 %, un vrai coup d’accélérateur pour l’entreprise.
Avance rapide jusqu’à aujourd’hui : les acheteurs de Contoso, qui ne sont plus rattachés au département logistique, ont négocié des accords intéressants, mais malheureusement complexes, avec leurs plus gros fournisseurs. Par exemple, un fournisseur peut rendre des sommes importantes à la fin de chaque trimestre, si certains quotas combinant des volumes de vente en euros et des quantités d’unités achetées sont atteints. Il y a 12 mois, l’équipe logistique a lancé une initiative qui vise à prendre en compte ces accords lors de la sélection du fournisseur le plus rentable pour chaque commande d’achat. Cette initiative s’est cependant enlisée. Les conditions contractuelles des fournisseurs se trouvent dans le système d’achat, les éléments financiers nécessaires dans les systèmes BI, tandis que d’autres informations relatives aux fournisseurs sont toujours dans le frontend et aucune évolution interne n’a été en mesure d’assembler complétement les pièces du puzzle. La modification nécessaire n’est pas très importante, mais chaque système de l’entreprise semble concerné. Le moral est au plus bas et tout le monde se concentre sur le projet suivant, sans rien attendre de positif de celui en cours.
