Le vrai coût de forcer un système à faire ce pour quoi il n'a pas été conçu

Chaque organisation en a un. Un système conçu pour une fin et discrètement enrôlé pour en faire une autre. Un CRM reconverti en outil de suivi de projets. Une plateforme comptable qui sert aussi de système d'inventaire. Un outil de planification qui détient des données qu'il n'a jamais été censé contenir.

Ça commence habituellement par de bonnes intentions et une justification qui sonne raisonnable : on a déjà cet outil, on paie déjà pour lui, il peut probablement gérer ça si on le configure comme il faut. Évitons le coût d'acheter quelque chose de neuf.

Ce qui s'ensuit est l'une des décisions les plus fiablement coûteuses en technologie d'entreprise.

Le coût visible et le vrai coût

Quand une organisation déforme un système, le coût visible est nul. Aucune nouvelle licence. Aucun nouveau fournisseur. Aucune dépense en capital à justifier au directeur financier. Sur papier, ça ressemble au choix efficace.

Le vrai coût apparaît ailleurs — à des endroits qui n'ont pas de poste dans le budget technologique.

Il apparaît dans les heures de personnel. Quand un système ne fait pas ce dont les gens ont besoin, les gens compensent. Ils bâtissent des contournements. Ils exportent les données vers des feuilles de calcul et les manipulent à la main. Ils développent un savoir institutionnel sur les caprices du système — un savoir qui vit dans la tête des gens, pas dans la documentation, et qui s'en va par la porte quand ces gens partent.

Il apparaît dans les erreurs. Les systèmes qui font des choses pour lesquelles ils n'ont pas été conçus ont tendance à défaillir de façons difficiles à prévoir et encore plus difficiles à déboguer. Une plateforme de commerce électronique incapable de suivre l'inventaire en temps réel ne tombe pas en panne bruyamment avec un message d'erreur. Elle défaille en silence, en laissant des clients acheter des produits qui ne sont pas en stock, ce qui génère une cascade de problèmes en aval, coûteux à corriger et corrosifs pour la confiance.

Il apparaît dans le coût d'opportunité. Une équipe qui consacre 30 % de sa capacité à gérer les contournements d'un système mal adapté est une équipe qui ne construit pas, n'améliore pas et ne grandit pas.

Un exemple concret

Au Muttart Conservatory pendant la COVID-19, le coût de transformer un CRM en plateforme de commerce électronique n'avait rien d'abstrait. C'était du personnel en temps supplémentaire chaque jour pour rapprocher manuellement les commandes en ligne et l'inventaire physique — parce que le système n'avait aucun mécanisme pour le faire automatiquement. C'était des clients qui recevaient des courriels de confirmation pour des plantes déjà vendues. C'était un fardeau de service à la clientèle qui grossissait à chaque transaction.

Aucun de ces coûts n'apparaissait sur une facture technologique. Ils apparaissaient sur la paie. Ils apparaissaient dans les plaintes des clients. Ils apparaissaient dans l'épuisement d'une équipe à qui on demandait de compenser, par du travail humain, un système tout simplement inadapté à la tâche.

Quand j'ai remplacé le contournement du CRM par Shopify — une plateforme conçue spécifiquement pour le commerce électronique — le temps supplémentaire a cessé immédiatement. Pas parce que Shopify est magique, mais parce qu'utiliser un outil pour ce pour quoi il a été conçu signifie que c'est l'outil qui fait le travail, pas les gens.

Comment lire le vrai coût avant de vous engager

Le moment pour repérer une mauvaise adéquation de système, c'est avant que le projet commence, pas après. Voici les questions que je pose :

Que fera ce système qu'il n'a pas été conçu pour faire à l'origine ? Soyez précis. Dressez la liste de chaque fonction que vous demandez au système d'accomplir et qui sort de sa conception d'origine. Pour chacune, demandez : comment le système gérera-t-il cela nativement, et que se passera-t-il quand il ne le pourra pas ?

Quels processus manuels cela créera-t-il ? Chaque écart entre ce que le système fait et ce dont vous avez besoin sera comblé par une personne. Cartographiez ces écarts avant de commencer. Estimez honnêtement le coût en temps.

Que se passe-t-il quand ça brise ? Les systèmes qui font des choses pour lesquelles ils n'ont pas été bâtis ont tendance à briser de manières inattendues. Qui va le déboguer ? Combien de temps ça prendra ? Quel est l'impact sur les opérations pendant la panne ?

Quel est le coût de sortie ? Si vous constatez dans six mois que ça ne fonctionne pas, à quel point est-il difficile de migrer vers une meilleure solution ? Les données qui vivent dans un système non conçu pour elles ont tendance à être désordonnées, mal structurées et difficiles à extraire proprement.

Combien coûterait réellement une solution conçue à cette fin ? Obtenez le vrai chiffre — licences, implantation, formation. Comparez-le honnêtement au coût complet du contournement, incluant le temps du personnel, les taux d'erreur et le coût d'opportunité. Vous pourriez découvrir que l'option « gratuite » est la plus chère.

Le biais organisationnel pour le familier

L'une des raisons pour lesquelles cela arrive si souvent, c'est que les organisations ont un fort penchant pour les outils qu'elles possèdent et comprennent déjà. Il y a un confort dans le familier, même quand le familier est inadapté à la tâche. Il y a aussi une friction organisationnelle rattachée à l'achat de quelque chose de neuf — processus d'approvisionnement, approbations budgétaires, gestion du changement.

Ce sont de vraies contraintes. Mais ce sont des coûts de bien faire les choses, pas des arguments pour les faire mal. La friction de l'approvisionnement est un coût unique. La friction d'un système mal adapté est un coût récurrent qui s'accumule avec le temps.

Mon travail, quand j'accompagne un client, c'est de mettre les deux chiffres sur la table — honnêtement — et de l'aider à prendre la bonne décision. Parfois, ça veut dire recommander un nouvel outil. Parfois, ça veut dire trouver une façon de faire fonctionner l'outil existant sans le pousser au-delà de ses limites. Et parfois, ça veut dire construire quelque chose de sur mesure, parce que rien de ce qui existe ne répond au besoin.

Mais ça commence toujours par une évaluation honnête de ce que le système peut réellement faire — pas de ce qu'on espère pouvoir lui faire faire.

C'est la conversation qui fait économiser de l'argent aux organisations. C'est aussi celle qu'on saute le plus souvent.