Accueil
 > Rapports de TEC > Blogue de TEC > Un autre échec d’implémentation, une autre occasion d’app...

Un autre échec d’implémentation, une autre occasion d’apprentissage ratée

Écrit par : Gabriel Gheorghiu
Date de publication : août 1 2011

Au cours des derniers articles, nous avons appris que les échecs d’implémentation de logiciels d’entreprise sévissent et que le blâme est attribué entièrement à l’éditeur. Bien que des clients mécontents entament des poursuites contre les éditeurs de logiciels, peu d’hypothèses sont offertes pour expliquer l’échec de l’implémentation.

Il y a donc peu d’information fournissant une perspective claire sur les leçons que devraient tirer le client et l’éditeur de cette difficile expérience.

Dans le billet du blogue intitulé 13 Things a Customer Can Do to Avoid an ERP Implementation Failure (en anglais), j’ai expliqué le rôle que jouent tous les partis dans la réussite ou l’échec de l’implémentation d’un logiciel. Par conséquent, ils ont tous quelque chose à apprendre d’un échec d’implémentation, et cette leçon peut être aussi importante qu’un client récupérant son investissement financier ou qu’un éditeur préservant sa réputation.

Que devraient faire les clients et les éditeurs pour apprendre d’un échec d’implémentation?

Les erreurs et les échecs sont une bonne occasion d’apprendre, mais essayer de vendre cette idée au directeur financier ou au chef de la direction qui ont dépensé des centaines de milliers de dollars, et peut-être plus, sur une solution logicielle qui ne répond pas aux besoins de la compagnie. La réaction immédiate peut être de décrocher le téléphone et d’obtenir de l’aide juridique afin de récupérer certains des coûts engendrés.

La deuxième réaction pourrait être de reconnaître que le client a peut-être quelque chose à voir avec l’échec de l’implémentation. Et le problème, s’il n’est pas résolu, persistera durant la sélection et implémentation du prochain logiciel avec un autre éditeur. Donc, tandis que les avocats sont occupés à recueillir des faits pour leur poursuite, les décideurs devraient mener leur propre enquête afin de s’assurer que ces erreurs ne se répètent pas.

Bien qu’une première réaction parfaitement naturelle de la part de l’éditeur est de prouver son innocence ou en venir à un règlement, cet échec devrait être suivi d’une analyse de la situation afin de découvrir ce qui a mal tourné lors de l’implémentation.

La plupart des éditeurs ont une forme de processus pour recueillir les commentaires ou un audit post implémentation en place, et les clients ont besoin de quelque chose de similaire. Malheureusement, la plupart du temps, ce processus est incomplet ou trop formel pour mettre en évidence les réels problèmes qui ont causé l’échec de l’implémentation.

Ce que l’on doit chercher

Le plus grand défi pour déterminer ce qui a mal tourné est de poser les bonnes questions aux bonnes personnes. Les questions qui sont trop générales n’obtiennent que des réponses floues, et les questions qui sont trop détaillées risquent de se perdre en formalités, ce qui peut rendre le processus encore plus difficile.

Tant les clients que les éditeurs devraient jeter un coup d’œil sur la méthode employée pour déterminer les exigences, sur la manière dont ils ont couvert ces exigences durant chaque étape importante de la sélection et de l’implémentation (et même de la post implémentation). Les clients doivent porter une part de responsabilité lorsque la compréhension de l’éditeur n’est pas conforme à celle du client, comme le doivent les éditeurs lorsque les clients commencent à utiliser un système sans être complètement prêts à le faire.

Les partis devraient mettre l’accent sur l’évaluation des règles d’intervention par palier qui ont été définies afin de garantir que la sélection et l’implémentation se poursuivent seulement lorsque les conditions de base sont respectées. Il est beaucoup moins coûteux du point de vue financier et des ressources de retarder le déploiement que de prendre le risque de subir un échec. Si vous avez ces règles, assurez-vous de bien comprendre ce qui n’a pas fonctionné et pour quelles raisons; si vous n’avez pas établi ces règles, assurez-vous de les avoir pour le prochain projet de sélection et d’implémentation.

Quoi ne pas faire

Il est plus important que les clients et les éditeurs tirent une leçon de l’échec de l’implémentation que de partir à la recherche d’un bouc émissaire, ce qui peut empirer les choses, puisque les gens sont déjà découragés par cet échec. Vous devez aussi vous assurer que le tout ne devienne pas une chasse aux sorcières internes, et que votre enquête ne cible pas ces individus qui avaient des perspectives différentes ou des objections face à la stratégie et à la méthodologie adoptée pour la sélection et l’implémentation. Ce sont ces personnes qui vont probablement vous fournir les réponses dont vous avez besoin pour comprendre ce qui a mal tourné avec l’implémentation et comment prévenir un nouvel échec.

 
comments powered by Disqus

Recherches récentes :
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z Others

©2014 Technology Evaluation Centers Inc. All rights reserved.