L'Horreur Non-Euclidienne (Antipattern de la Supply Chain)

L’horreur non-euclidienne est sortie des profondeurs des systèmes informatiques de l’entreprise. Fixer trop longtemps l’horreur non-euclidienne peut entraîner une perte permanente de la raison.

Catégorie: organisation

Problème: au fil des années, l’entreprise a mis en place de nombreux systèmes différents. Ils disposent maintenant d’un ERP, d’un WMS (système de gestion d’entrepôt), d’un CRM (gestion de la relation client), d’un cube BI (intelligence d’affaires), d’une plateforme de commerce électronique, etc. Entre les mises en œuvre de tous ces systèmes, des composants internes ont également été développés pour effectuer des tâches plus spécialisées. La complexité du paysage informatique a fortement augmenté au fil des ans, car chaque application supplémentaire doit communiquer avec toutes les autres applications déjà mises en œuvre par l’entreprise. Chaque division est impactée, mais la supply chain, située entre les ventes, les achats, la finance et la production, est la plus touchée. Les changements sont lents et presque toutes les initiatives de la supply chain ne parviennent pas à respecter leurs délais. Personne ne comprend vraiment ce qui se passe dans les systèmes de l’entreprise.

Preuve anecdotique: Physiquement, passer d’un entrepôt à un autre à proximité pourrait être fait en deux semaines. Cependant, en ce qui concerne les logiciels, la migration informatique réelle nécessaire pour intégrer le nouvel entrepôt va prendre plus de 6 mois.

Contexte: il y a longtemps, chaque division de l’entreprise avait commencé avec sa propre solution logicielle. L’intégration était médiocre, et finalement il a été décidé de mettre en place un système ERP pour “les gouverner tous”. Le système ERP a été mis en œuvre, mais il n’a pas réussi à suivre le rythme rapide des changements dans l’industrie logicielle. En ce qui concerne la supply chain, un WMS (système de gestion d’entrepôt) a été mis en place pour améliorer la productivité et la fiabilité ; et cela a plutôt bien fonctionné. Les autres divisions ont fait des mouvements similaires en mettant en place leurs propres applications spécifiques au domaine qui étaient mieux adaptées que l’ERP d’origine. Cependant, les affaires évoluent plus rapidement que jamais, et aujourd’hui, avoir des opérations de supply chain plus intelligentes implique une myriade d’interactions entre toutes ces différentes applications.

Solution supposée: Chaque fois qu’un nouveau défi se présente, les systèmes informatiques sont ajustés au minimum pour fournir les résultats attendus. À des fins de supply chain, une intégration ad hoc avec le CRM a été mise en place pour collecter les informations de l’équipe commerciale, et une autre intégration ad hoc a été mise en place avec le cube BI car c’est la seule façon d’avoir des chiffres cohérents avec ceux utilisés par la finance. Les services logistiques et les fournisseurs ont nécessité plusieurs intégrations. En conséquence, l’équipe de la supply chain a appris que plus le changement informatique est important, plus il est probable que l’initiative dépasse le budget et ne respecte pas les délais. Par conséquent, les changements incrémentaux étroits sont désormais fortement privilégiés par rapport à toute évolution substantielle.

Contexte résultant: Le plan du métro de Tokyo semble simple comparé à la représentation des différentes interactions informatiques au sein de l’entreprise. Il existe des centaines de dépendances subtiles entre tous les systèmes de l’entreprise. La vue d’ensemble du paysage informatique est très floue, pour ne pas dire inexistante. Pour la supply chain, il est difficile d’accéder à toutes les informations pertinentes telles que les nouveaux produits, les promotions, les bons de commande “presque” finalisés, l’historique des niveaux de stock et des ruptures de stock, etc. Chaque petite révision des opérations de la supply chain, où un processus doit être amélioré en tirant parti d’une information supplémentaire, semble traîner en longueur. Les entrées de données sont incohérentes, les systèmes continuent de tomber en panne et il y a des exceptions qui doivent être gérées manuellement un peu partout.

Forces séduisantes: L’entreprise a appris à ses dépens que plus l’initiative informatique est importante, plus il est probable que l’initiative échoue. Ainsi, toutes les pratiques ont progressivement évolué vers des initiatives plus petites et plus ciblées, qui sont plus faciles à déployer tout en maîtrisant le budget et les délais. L’entreprise a réussi à obtenir des succès précoces précisément grâce à de telles initiatives à petite échelle, avec des résultats positifs obtenus avec de petits budgets.

Pourquoi cela conduit à l’échec: Chaque changement incrémental augmente le coût et la complexité de tous les changements ultérieurs. Étant donné que les pratiques de l’entreprise favorisent les changements aussi petits et incrémentaux que possible, il y a un manque constant de préoccupation pour la “vue d’ensemble”. En quelque sorte, il s’agit d’un cas de “tragédie des communs”, où les intérêts individuels (les divisions séparées de l’entreprise) ne sont pas alignés sur les intérêts communs de l’entreprise dans son ensemble. Le problème est d’autant plus aigu que les effets négatifs sont généralement observés longtemps après le changement. Alors que chaque changement semble être rentable, l’entreprise accumule une “dette technique”, transformant les bénéfices à court terme en pertes au fil du temps.

Modèles positifs pour résoudre le problème: Fondamentalement, la mise en œuvre de changements incrémentaux est une approche raisonnable à adopter. Cependant, chaque changement doit être exécuté de manière à ce que chaque changement ultérieur devienne moins coûteux ou plus simple ; les deux propriétés étant fortement corrélées en pratique. Cela implique que chaque initiative doit payer la taxe des communs, où non seulement l’objectif principal de l’initiative doit être atteint, mais également l’objectif secondaire, qui consiste à faciliter les changements à venir.

Exemple: Contoso est un leader national du commerce électronique en Allemagne dans un segment B2C spécifique. L’entreprise a commencé à opérer au début des années 2000, en développant une interface personnalisée à l’époque ; l’interface étant l’application qui permet aux gens d’acheter en ligne. Au cours des premières années de l’entreprise, presque tous ses besoins informatiques ont été résolus grâce à une interface en constante évolution. Cependant, la gestion des fournisseurs et des commandes d’achat était tout simplement trop pour cette application personnalisée. Par conséquent, Contoso a décidé d’investir dans un ERP de milieu de gamme et de décharger tous les processus de back-office vers ce système ERP, y compris la majeure partie des pratiques naissantes de la supply chain. Pendant un certain temps, les niveaux de stock étaient gérés à la fois dans l’interface et dans l’ERP, mais comme cela s’est avéré être un désordre, Contoso a finalement réussi à décharger l’interface de ses responsabilités excessives.

L’ERP a rempli sa fonction initialement, mais à mesure que l’entreprise continuait de croître, et malgré les meilleurs efforts de l’équipe technique chargée du développement de l’ERP, l’ERP ne parvenait pas à répondre à toutes les exigences de l’entreprise. Les rapports étaient insuffisants et la finance a décidé de mettre en place son propre portail BI (Business Intelligence), avec la plupart des autres divisions déployant des applications similaires. La supply chain a lancé une série d’intégrations EDI pour envoyer leurs commandes d’achat à leurs fournisseurs, mais tout acheminer vers l’ERP devenait de plus en plus frustrant car l’ERP ne pouvait tout simplement pas capturer toutes les subtilités des opérations de la supply chain de Contoso.

Comme Contoso est devenu un leader national, il avait désormais accès à une large gamme d’options d’approvisionnement. Les distributeurs locaux allemands qui avaient initialement joué un rôle clé dans le succès initial de Contoso se révélaient désormais de plus en plus coûteux alors que les concurrents de Contoso faisaient baisser les prix. Les jours où les clients étaient prêts à payer “plus” pour des achats en ligne étaient révolus. Par conséquent, Contoso a dû intégrer progressivement des options d’approvisionnement alternatives dans son flux de travail, en utilisant généralement les services de fournisseurs plus éloignés, parfois étrangers. Après quelques mois de lutte infructueuse pour intégrer la logique de multi-approvisionnement dans leur ERP, l’équipe de la supply chain a décidé qu’il était temps de mettre en place son propre système, séparé de l’ERP. L’équipe de la supply chain a choisi d’opter pour une application d’approvisionnement avancée, mais la mise en place a pris beaucoup plus de temps que prévu. La nouvelle solution n’était pas en cause, c’était l’intégration avec l’ERP qui a entraîné une série de difficultés inattendues. Par exemple, trois mois après le lancement de la nouvelle solution, les équipes de la supply chain ont réalisé que les retards d’expédition affichés sur le site web du client n’étaient pas gérés par l’ERP mais toujours par le front-end. Par conséquent, ces “retards d’expédition affichés” circulaient du front-end vers l’ERP, mais rien n’avait été fait pour soutenir l’inverse. En conséquence, l’injection de retards d’expédition révisés - mis à jour dynamiquement en fonction du fournisseur sélectionné pour fournir le produit - dans l’ERP n’avait aucun impact sur les chiffres affichés sur le site web. L’ERP était déjà devenu un ensemble assez complexe, et comme l’équipe informatique de Contoso se sentait beaucoup plus à l’aise avec le front-end qui avait été développé en interne, la supply chain et les équipes informatiques ont conjointement décidé que la solution d’approvisionnement injecterait les retards d’expédition révisés directement dans le front-end.

L’approche s’est avérée quelque peu chaotique, et bien qu’il était initialement prévu de déployer l’application d’approvisionnement dans les 3 mois, il a fallu 9 mois entiers pour la mettre en service. Pourtant, cela en valait la peine, car le multi-approvisionnement a permis de réduire les prix d’achat moyens de 15%, ce qui a été un coup de pouce considérable pour l’entreprise.

Avançons rapidement jusqu’à aujourd’hui. L’équipe d’achat de Contoso, désormais séparée de la division de la supply chain, a négocié des accords favorables, mais malheureusement complexes, avec ses plus grands fournisseurs. Par exemple, le fournisseur peut retourner des sommes importantes à la fin de chaque trimestre si certains quotas sont atteints, impliquant généralement une combinaison de volumes de ventes en euros et de quantités d’unités achetées. Il y a 12 mois, l’équipe de la supply chain a lancé une initiative pour prendre en compte de tels accords lors de la sélection du fournisseur le plus rentable pour chaque commande d’achat. Cependant, l’initiative est largement bloquée. Les conditions contractuelles du fournisseur se trouvent dans le système d’achat, les éléments financiers ne se trouvent que dans les systèmes BI, tandis que d’autres informations liées au fournisseur restent dans le front-end, et aucune mise à niveau interne n’a jamais été réalisée pour assembler les différentes parties de ce puzzle. La quantité de changement réellement nécessaire est faible, mais il semble que chaque système de l’entreprise soit impliqué. Le moral est bas et les gens se concentrent de plus en plus sur leur prochaine mission, car aucun résultat positif n’est en vue.