Un jour, un marchand de machinerie agricole a dit à mon père que son plus gros travail, lorsqu’il voulait faire la promotion d’un nouveau modèle de tracteur, c’était d’en vendre 1 exemplaire dans chaque village. Tous les voisins des acheteurs voulaient alors acheter le même…
More...
On peut juger ce comportement de bien des façons. Je vais me contenter de le trouver illogique du point de vue affaires.
Malheureusement on retrouve le même comportement en lien avec les technologies de l’information.
Transcription du vidéo :
Un jour, un marchand de machinerie agricole a dit à mon père que son plus gros travail, lorsqu’il voulait faire la promotion d’un nouveau modèle de tracteur, c’était d’en vendre 1 exemplaire dans chaque village. Tous les voisins des acheteurs voulaient alors acheter le même…
On peut juger ce comportement de bien des façons. Je vais me contenter de le trouver illogique du point de vue affaires.
Malheureusement on retrouve le même comportement en lien avec les technologies de l’information.
On voit parfois des chefs entreprises qui ont choisi d’acheter tel logiciel parce qu’un compétiteur ou un voisin possède ce logiciel, ou encore parce que quelqu’un – genre le beau-frère « ti-jos-connaissant » – leur en a parlé.
Ces personnes auraient pu prendre une plus mauvaise décision encore… Mais il faut vraiment se donner du mal pour y arriver.
Parce que ce qui va se produire, si vous achetez un logiciel avant d’avoir vérifié s’il peut répondre à vos besoins, c’est que précisément, il ne pourra peut-être pas y répondre. Ou alors au prix de très gros efforts de personnalisation et/ou de développement qui vont éventuellement coûter très cher et retarder le projet.
Ou peut-être, que vous allez devoir changer vos processus d’entreprise pour pouvoir coller aux capacités du logiciel. Vous allez peut-être devoir les alourdir pour y arriver. C’est un impact énorme sur votre entreprise de tout chambouler ainsi.
C’est comme si vous achetiez une Ferrari pour livrer des patates, et que vous vous rendiez compte ensuite que vous allez devoir faire 100 voyages au lieu d’un seul si vous aviez acheté un camion. Vous allez rouler plus vite avec votre bolide, mais vous ne serez jamais rentable.
Le Standish Group (qui produit des statistiques annuelles sur le succès de projets TI dans le monde) a identifié ce problème-là comme étant le 4ème facteur d’échec des projet TI. Il s’agit des attentes irréalistes de la part des parties prenantes au projet.
Voici un cas réel qui va illustrer à quel point une décision basée sur des attentes irréalistes peut avoir des conséquences importantes :
En 1996 Hershey’s a décidé de remplacer tous ses vieux systèmes par un ERP et un CRM à la fine pointe.
Le calendrier de projet recommandé était de 48 mois.
Pour pouvoir fermer leurs vieux systèmes avant le bogue l’an 2000, ils ont insisté pour que tout soit complété en 30 mois.
Pour respecter la date voulue (juillet 1999), il a fallu couper les coins ronds, en particulier pendant les tests. Évidemment, le système avait des problèmes qui n'ont pas été détectés.
Or, en juillet, commence leur période de forte activité où ils reçoivent le plus gros des commandes pour l’Halloween et Noël.
Résultat? ils ont été incapables de livrer pour 100 millions US de commandes, ce qui a retranché près de 20% des profits trimestriels.
S’imposer un tel calendrier était donc irréaliste. Une compagnie moins riche aurait peut-être disparu.
Lorsque vous engagez un consultant comme moi, notre rôle est celui de conseiller du Roi. Nous vous prodiguons nos conseils dans votre meilleur intérêt. Mais vous êtes celui ou celle qui « call les shots », à vos risques et périls…
Si vous vous lanciez dans un projet TI aujourd’hui, quelles seraient vos attentes?