L'horreur non-euclidienne (Antipatterns de la supply chain)

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

Catégorie : organisation

Problème : Au fil des années, l’entreprise a mis en place de nombreux systèmes différents. Ils disposent désormais d’un ERP, d’un WMS (warehouse management system), d’un CRM (customer relationship management), d’un cube BI (business intelligence), d’une plateforme de e-commerce, etc. Entre la mise en œuvre de tous ces systèmes, des composants internes ont également été développés pour réaliser des tâches plus spécialisées. La complexité du paysage informatique a considérablement augmenté au fil des ans, car chaque application supplémentaire doit communiquer avec chacune des autres déjà mises en place 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 affectée. Les changements sont lents, et presque toutes les initiatives supply chain ne respectent pas leurs délais. Personne ne comprend vraiment ce qui se passe au sein des systèmes informatiques de l’entreprise.

Preuves anecdotiques : Le déménagement physique d’un warehouse à un autre à proximité pouvait se faire en deux semaines. En revanche, en ce qui concerne le logiciel, la migration informatique réelle nécessaire pour intégrer le nouveau warehouse prendra plus de 6 mois.

Contexte : Il y a bien longtemps, chaque division de l’entreprise avait démarré avec sa propre solution logicielle. L’intégration était médiocre, et il fut finalement décidé de mettre en place un système ERP pour « tous les régir ». Le système ERP a été implémenté, mais il n’a pas réussi à suivre le rythme effréné de l’évolution du secteur logiciel. Pour la supply chain, un WMS (warehouse management system) a été mis en place pour améliorer la productivité et la fiabilité ; et cela a plutôt bien fonctionné. D’autres divisions ont suivi des démarches similaires en déployant leurs propres applications spécifiques à leur domaine, qui correspondaient mieux que l’ERP d’origine. Cependant, le monde des affaires évolue plus rapidement que jamais, et aujourd’hui, disposer d’opérations supply chain plus intelligentes telles que opérations supply chain implique une myriade d’interactions entre toutes ces applications différentes.

Solution supposée : Chaque fois qu’un nouveau défi se présente, les systèmes informatiques sont ajustés à un niveau minimal pour fournir les résultats attendus. Pour les besoins de la supply chain, une intégration ad hoc avec le CRM a été mise en place pour recueillir les données de l’équipe commerciale, et une autre intégration ad hoc a été réalisée avec le cube BI car c’est la seule manière d’obtenir des chiffres compatibles avec ceux utilisés par la finance. Les services logistiques et les fournisseurs ont exigé plusieurs intégrations de leur côté. En conséquence, l’équipe 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. Ainsi, des changements incrémentaux restreints 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, au mieux, très floue. Pour la supply chain, c’est une lutte constante pour accéder à toutes les informations pertinentes telles que nouveaux produits, promotions, des bons de commande « presque » finalisés, l’historique des niveaux de stocks et des ruptures de stock, etc. Chaque petite révision des opérations supply chain, où un processus doit être amélioré en tirant parti d’une information supplémentaire, semble s’éterniser. Les données d’entrée sont incohérentes, les systèmes continuent d’échouer et il y a des exceptions qui doivent être gérées manuellement partout.

Forces séduisantes : L’entreprise a appris à ses dépens que plus l’initiative informatique est importante, plus il est probable qu’elle é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 maintenant le budget et les échéances sous contrôle. L’entreprise a réussi à obtenir des succès précoces précisément grâce à ces initiatives de petite envergure, avec des résultats positifs obtenus avec des budgets réduits.

Pourquoi cela conduit à l’échec : Chaque changement incrémental augmente le coût et la complexité de tous les changements ultérieurs. Puisque les pratiques de l’entreprise privilégient les changements aussi petits et incrémentaux que possible, il y a un manque constant de considération pour la « vue d’ensemble ». D’une certaine manière, il s’agit d’une forme de « tragédie des biens communs », où les intérêts individuels (les différentes divisions de l’entreprise) ne sont pas alignés avec les intérêts communs de l’entreprise dans son ensemble. Le problème se trouve accentué par le fait que les effets négatifs ne se manifestent généralement qu’un long moment après le changement. Si chaque changement semble rentable, l’entreprise continue d’accumuler une « dette technique », transformant les profits à court terme en pertes au fil du temps.

Schémas positifs pour remédier au problème : Fondamentalement, mettre en œuvre des changements incrémentaux est une approche raisonnable. Toutefois, chaque changement devrait être exécuté de manière à ce que chaque changement ultérieur devienne moins coûteux ou plus simple ; ces deux propriétés étant fortement corrélées en pratique. Cela implique que chaque initiative doit payer la taxe des biens communs, non seulement en atteignant l’objectif principal de l’initiative, mais aussi l’objectif secondaire, qui consiste à faciliter les changements futurs.

Exemple : Contoso est un leader national du e-commerce en Allemagne dans un segment B2C spécifique. L’entreprise a commencé à opérer au début des années 2000, en développant à l’époque un front-end sur mesure ; le front-end étant l’« application » qui permettait aux gens d’acheter en ligne. Dans les premières années de l’entreprise, presque tous ses besoins informatiques étaient satisfaits par un front-end en constante évolution. Cependant, la gestion des fournisseurs et des bons de commande était tout simplement trop complexe pour cette application sur mesure. Par conséquent, Contoso a décidé d’investir dans un ERP de taille moyenne et de déléguer tous les processus back-office à ce système ERP, y compris l’essentiel des pratiques naissantes de la supply chain. Pendant un certain temps, les niveaux de stocks étaient gérés à la fois au sein du front-end et de l’ERP, mais comme cela s’est avéré chaotique, Contoso a finalement réussi à décharger le front-end de ses responsabilités excessives.

L’ERP a initialement rempli sa fonction, mais à mesure que l’entreprise continuait de croître, et malgré les meilleurs efforts de l’équipe technique en charge du développement de l’ERP, celui-ci n’arrivait pas à suivre toutes les exigences du business. Les rapports étaient insuffisants, et la finance a décidé de mettre en place son propre portail BI (Business Intelligence), tandis que la plupart des autres divisions déployaient des applications similaires. La supply chain a lancé une série d’intégrations EDI pour envoyer ses bons de commande à ses fournisseurs, mais canaliser tout vers l’ERP devenait de plus en plus frustrant car l’ERP ne pouvait tout simplement pas saisir toutes les subtilités des opérations supply chain de Contoso.

Alors que Contoso était devenu un leader national, il avait désormais accès à une large gamme d’options de sourcing. 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, les concurrents de Contoso faisant baisser les prix. Les jours où les clients étaient prêts à payer « un supplément » pour les achats en ligne étaient depuis longtemps révolus. En conséquence, Contoso a dû intégrer progressivement des options de sourcing alternatives dans son flux de travail, utilisant typiquement les services de fournisseurs plus éloignés, parfois étrangers. Après quelques mois de lutte infructueuse pour intégrer la logique multi-sourcing dans leur ERP, l’équipe supply chain a estimé qu’il était temps de mettre en place leur propre système, distinct de l’ERP. L’équipe supply chain a choisi d’opter pour une application de sourcing 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’est l’intégration avec l’ERP qui a conduit à une série de difficultés inattendues. Par exemple, trois mois après le lancement de la nouvelle solution, les équipes supply chain se sont rendu compte que les retards d’expédition affichés sur le site 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 » coulaient 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 IT de Contoso se sentait bien plus à l’aise avec le front-end qui avait été développé en interne, les équipes supply chain et IT ont conjointement décidé que la solution de sourcing injecterait directement les retards d’expédition révisés dans le front-end.

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

Avance rapide jusqu’à aujourd’hui. L’équipe achats de Contoso, désormais séparée de la division supply chain, a négocié des accords favorables mais malheureusement complexes avec ses plus grands fournisseurs. Par exemple, le fournisseur pourrait restituer 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 supply chain a lancé une initiative pour prendre en compte ces accords lors de la sélection du fournisseur le plus rentable pour chaque bon de commande. Cependant, l’initiative est largement au point mort. Les termes contractuels du fournisseur se trouvent dans le système d’achats, les éléments financiers ne sont disponibles que dans les systèmes BI, tandis que d’autres informations liées aux fournisseurs restent dans le front-end, et aucune mise à niveau interne n’a jamais été achevée pour assembler les différentes parties de ce casse-tête. Le changement réellement nécessaire est minime, 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.